Pertanyaan
Pada PostgreSQL 18 di lingkungan produksi, kueri pelaporan, bitmap heap scan, dan vacuum dibatasi oleh latensi penyimpanan. Rancang rencana untuk mengevaluasi dan meluncurkan asynchronous I/O (AIO) secara aman: pilih io_method, sesuaikan konkurensi, verifikasi pg_stat_io dan pg_aios, pisahkan bottleneck CPU, cache, dan penyimpanan, serta lakukan rollback ketika latensi memburuk.
Apa yang sedang diuji oleh pewawancara
Ini menguji kemampuan eksperimen performa database dan kedisiplinan dalam melakukan perubahan produksi. AIO dapat mengeksekusi beberapa pembacaan secara bersamaan, tetapi tidak membuat semua beban kerja menjadi lebih cepat. Jawaban yang kuat menjelaskan worker, io_uring, dan sync, menggunakan beban kerja dan statistik yang dapat diulang, serta menentukan batas (threshold) rollback alih-alih memaksimalkan setiap parameter.
Pertanyaan klarifikasi
- Apakah jalur yang dominan adalah sequential scan, bitmap heap scan, vacuum, atau random point lookup?
- Apakah penyimpanannya berupa NVMe lokal, network block storage, atau volume kontainer, dan apakah kernel mendukung
io_uring? - Apakah tujuannya adalah throughput, latensi P95, waktu penyelesaian vacuum, atau penggunaan CPU yang lebih rendah?
- Bisakah read replica atau instans bayangan (shadow instance) menjalankan pengujian, dan apakah perubahan parameter startup memerlukan restart?
Kerangka kerja 30 detik
Bangun baseline untuk latensi, throughput, CPU, I/O wait, dan durasi vacuum di bawah kondisi data dan cache yang tetap. Kemudian cakup pemilihan metode (worker/io_uring/sync), kontrol konkurensi (effective_io_concurrency, io_max_concurrency, io_workers), serta observabilitas/rollback (pg_stat_io, pg_aios, dan gerbang SLO). Ambil keputusan berdasarkan eksperimen bertahap, bukan hanya dari satu kali pengujian cepat.
Desain langkah demi langkah
1. Menetapkan baseline yang dapat dibandingkan
Tetapkan versi minor PostgreSQL 18, data, indeks, statistik, dan konkurensi klien yang tetap. Ukur cold cache dan warm cache secara terpisah, catat EXPLAIN (ANALYZE, BUFFERS, WAL), pg_stat_io, latensi disk, dan CPU. Pisahkan sequential scan, bitmap heap scan, dan vacuum agar regresi performa tidak hilang dalam nilai rata-rata.
2. Memilih metode I/O
io_method=worker menggunakan pekerja I/O (I/O workers) PostgreSQL dan merupakan baseline kompatibilitas yang konservatif. io_method=io_uring memerlukan build liburing dan dukungan kernel. io_method=sync adalah jalur kontrol dan rollback. Verifikasi build serta izin, lalu jalankan setiap metode untuk beberapa putaran pada beban kerja yang sama.
3. Mengontrol konkurensi
effective_io_concurrency dan maintenance_io_concurrency menyediakan petunjuk konkurensi untuk sesi dan pemeliharaan. io_max_concurrency membatasi operasi simultan per proses, sedangkan io_workers berlaku untuk metode worker. Tingkatkan secara bertahap dan pantau antrean penyimpanan, P95, dan CPU; jangan pernah menyetel setiap nilai ke batas maksimumnya secara default.
4. Menginterpretasikan sinyal
Gunakan pg_stat_io untuk membandingkan pembacaan, penulisan, dan waktu tunggu berdasarkan backend, objek, dan operasi. Gunakan pg_aios untuk memeriksa handle yang sedang disiapkan, dieksekusi, atau diselesaikan. Jika kueri menjadi lebih cepat sementara antrean penyimpanan dan tail latency meningkat, throughput telah dikorbankan untuk terjadinya kontensi. Jika view tidak berubah, beban kerja mungkin tidak menggunakan jalur yang didukung atau didominasi oleh cache hit.
5. Merancang eksperimen dan kapasitas
Pada replika atau instans bayangan, tingkatkan konkurensi klien secara bertahap dan bandingkan throughput, P95/P99, CPU, kedalaman I/O, dan backlog vacuum. Sertakan batas burst, amplifikasi pembacaan, dan noisy neighbors untuk penyimpanan jaringan. Cadangkan kapasitas untuk WAL, checkpoint, autovacuum, dan backup.
6. Menetapkan gerbang peluncuran dan rollback
Tentukan batas manfaat dan regresi per beban kerja: P95 tidak boleh memburuk, antrean penyimpanan tidak boleh terus jenuh, dan backlog vacuum tidak boleh bertambah. Luncurkan ke sebagian kecil instans dalam jendela pemeliharaan dengan pemilik yang ditentukan. Melewati ambang batas akan memicu pengalihan kembali ke sync atau nilai konkurensi sebelumnya serta mempertahankan statistik sebelum/sesudah.
7. Menyatakan batasan dan langkah berikutnya
AIO PostgreSQL 18 meningkatkan jalur yang dapat mengeluarkan I/O konkuren; ini tidak menggantikan indeks, rencana kueri, tuning cache, atau peningkatan perangkat keras penyimpanan. Catat kernel, opsi build, io_method, dan snapshot parameter, lalu ulangi baseline multi-beban kerja selama proses upgrade sebelum memperluas peluncuran.
Contoh jawaban yang kuat
“Saya akan menggunakan read replica dengan kondisi data, statistik, dan cache yang tetap untuk mengukur sequential scan, bitmap heap scan, dan vacuum dalam kondisi cold dan warm, serta mencatat EXPLAIN BUFFERS, pgstatio, latensi disk, dan CPU. Saya akan mulai dengan worker, membandingkan iouring hanya setelah memverifikasi liburing dan dukungan kernel, serta mempertahankan sync sebagai kontrol dan jalur rollback. Saya akan meningkatkan effectiveioconcurrency dan maintenanceioconcurrency secara bertahap sambil membatasi iomaxconcurrency dan ioworkers, memantau antrean penyimpanan dan P99. pg_aios mengonfirmasi handle yang aktif. Hanya beban kerja yang memenuhi gerbang latensi/throughput tanpa kejenuhan antrean yang mendapatkan deployment canary; regresi pada tail-latency atau backlog akan dialihkan kembali ke sync.”
Pola kegagalan umum
- Memaksimalkan konkurensi tanpa baseline atau anggaran kapasitas.
- Menganggap io_uring tersedia tanpa pemeriksaan build dan kernel.
- Memantau latensi rata-rata sambil mengabaikan P95/P99, antrean, dan backlog vacuum.
- Menganggap pg_aios sebagai bukti bahwa setiap kueri menggunakan AIO, mengabaikan jalur yang didukung dan cache hit.
- Menghilangkan gerbang canary, kepemilikan (ownership), ambang batas, dan rencana rollback ke sync.
Arah tindak lanjut
Kapan Anda akan memilih worker daripada io_uring?
Pilih worker ketika build atau kernel tidak memiliki dukungan liburing atau ketika jalur kompatibilitas konservatif diperlukan, lalu buat keputusan berdasarkan hasil pengukuran.
Mengapa memisahkan pengujian cold cache dan warm cache?
Pengujian warm cache sebagian besar menguji CPU dan memori; cold cache mengekspos konkurensi penyimpanan dan tail latency. Mencampurkan keduanya akan menyembunyikan efek AIO yang sebenarnya.
Apakah nilai effective_io_concurrency yang lebih besar selalu lebih baik?
Tidak. Konkurensi yang berlebihan dapat memperkuat kontensi penyimpanan dan tail latency global, jadi kalibrasikan nilainya untuk perangkat dan beban kerja terkait.
Bagaimana Anda membuktikan manfaat pada vacuum?
Pertahankan bloat, dead tuple, dan jendela pemeliharaan tetap konstan, lalu bandingkan waktu penyelesaian, I/O wait, dampak penguncian (lock impact), dan backlog.
Apakah pg_aios merupakan sumber pemantauan jangka panjang?
View ini menampilkan handle saat ini dan berguna untuk diagnosis atau sampel; pemantauan tren memerlukan pgstatio, metrik sistem, dan label beban kerja.
Referensi
PostgreSQL 18 “Release Notes”, “Resource Consumption Configuration”, dan “pg_aios System View”.