Petunjuk dan ruang lingkup
Beban kerja mengalami pemindaian yang lebih lambat, latensi baca yang meningkat, serta lalu lintas campuran antara OLTP dan analitik. PostgreSQL 18 menambahkan lebih banyak visibilitas I/O, termasuk data pgstatio berbasis byte dan statistik per-backend. Gunakan view tersebut bersama dengan query plan, wait event, dan pengukuran sistem operasi untuk membentuk diagnosis yang dapat diuji kesalahannya (falsifiable) daripada menyesuaikan satu parameter hanya berdasarkan insting.
Ini adalah pertanyaan data karena keterampilan utamanya adalah observabilitas basis data, penalaran beban kerja, dan eksperimen performa yang aman.
Apa yang dinilai oleh pewawancara
Pertama, apakah Anda dapat mengidentifikasi dimensi baris pgstatio dan menghindari penjumlahan konteks yang tidak kompatibel? Tipe backend, objek, konteks, dan operasi mendeskripsikan sumber I/O yang berbeda.
Kedua, apakah Anda memisahkan counter kumulatif dari suatu jendela waktu? Suatu laju (rate) memerlukan dua sampel dengan interval yang diketahui, dan reset atau restart harus dicatat.
Ketiga, apakah Anda dapat menghubungkan bukti basis data dengan sebuah kueri? EXPLAIN ANALYZE dengan timing I/O dan buffer menunjukkan apakah suatu rencana melakukan pembacaan, penulisan, atau prefetch; ini tidak menggantikan bukti tingkat sistem.
Keempat, apakah Anda dapat membedakan cache miss, tekanan checkpoint, pekerjaan vacuum, dan saturasi penyimpanan?
Kelima, apakah Anda dapat mengubah satu variabel, menjaga kebenaran data, dan memvalidasi hasilnya terhadap beban kerja yang representatif?
Pertanyaan klarifikasi awal
- Apakah perlambatan terjadi pada satu kueri, satu kelas beban kerja, atau seluruh instans?
- Apakah ada perubahan pada skema, statistik, volume, bauran kueri, atau versi PostgreSQL?
- Apa sinyal latensi baca/tulis, throughput, dan queue depth pada lapisan penyimpanan?
- Apakah statistik di-reset, instans di-restart, atau failover dilakukan selama perbandingan?
- Apakah beban kerja dibatasi oleh CPU, memori, I/O, lock, atau konkurensi klien?
- SLO kebenaran dan latensi apa yang membatasi remediasi?
Kerangka jawaban 30 detik
“Saya akan menetapkan jendela sebelum dan sesudah, mencatat restart dan reset statistik, lalu mengambil sampel pgstatio berdasarkan tipe backend, objek, konteks, dan operasi. Saya akan mengorelasikan delta dengan timing I/O EXPLAIN ANALYZE, penggunaan buffer, wait event, aktivitas checkpoint dan vacuum, serta latensi OS. Saya akan mengklasifikasikan bottleneck, mengubah satu kontrol yang dapat dibatalkan (reversible), memutar ulang beban kerja representatif, dan membandingkan throughput, tail latency, kebenaran data, serta cadangan sumber daya (resource headroom).”
Jawaban langkah demi langkah
Langkah 1: Tetapkan jendela yang dapat dibandingkan
Ambil versi PostgreSQL, profil beban kerja, ID kueri, waktu restart, waktu reset statistik, dan topologi penyimpanan. Ambil dua sampel pgstatio dengan jarak waktu yang cukup untuk menunjukkan laju, dan simpan snapshot mentah tersebut agar reset berikutnya tidak disalahartikan sebagai peningkatan performa.
SELECT backend_type, object, context, reads, read_bytes,
writes, write_bytes, read_time, write_time
FROM pg_stat_io;Kolom persis dan izin tergantung pada versi mayor target; pastikan dokumentasi dan kueri yang digunakan oleh agen pemantau sudah sesuai.
Langkah 2: Atribusikan I/O berdasarkan dimensi
Bandingkan tipe backend dan konteks secara terpisah. Backend klien, checkpointer, background writer, worker autovacuum, dan operasi pemeliharaan mengindikasikan solusi yang berbeda. Data relasi, indeks, dan file sementara juga memiliki perilaku fisik yang berbeda. Hindari satu angka global “I/O tinggi”.
Langkah 3: Korelasikan dengan kueri yang lambat
Jalankan EXPLAIN (ANALYZE, BUFFERS, WAL, SETTINGS) representatif jika aman, dan aktifkan timing I/O hanya dengan menyadari overhead pengukurannya. Bandingkan baris aktual, blok yang dibaca, blok hit, prefetch, dan waktu yang berlalu. Rencana dengan banyak pembacaan mungkin wajar untuk suatu pemindaian; pertanyaannya adalah apakah laju pembacaan dan latensi melanggar batas beban kerja.
Langkah 4: Pisahkan penyebab yang bersaing
Pembacaan tinggi dengan latensi perangkat rendah mengindikasikan tekanan cache atau perubahan rencana/ukuran data. Latensi baca dan queue depth yang tinggi mengindikasikan saturasi penyimpanan. Penulisan checkpoint yang intensif, aktivitas vacuum, atau pertumbuhan file sementara dapat bersaing dengan kueri foreground. Wait event dan utilisasi CPU membantu membedakan antrean I/O dari bottleneck lock atau executor.
Langkah 5: Bentuk hipotesis yang dapat diuji (falsifiable)
Nyatakan klaim yang terukur seperti “pemindaian partisi baru melebihi kapasitas cache dan menyebabkan pembacaan acak” atau “lonjakan penulisan checkpoint menunda pembacaan foreground.” Pilih pengujian kontrafaktual: perubahan rencana, pemanasan cache terkontrol, penyesuaian laju checkpoint, perbaikan indeks atau partisi, atau isolasi beban kerja.
Langkah 6: Terapkan remediasi yang dapat dibatalkan (reversible)
Ubah satu kontrol pada satu waktu, lengkap dengan nilai rollback dan interval observasi. Jangan menaikkan memori, worker, atau pengaturan checkpoint melebihi kapasitas host. Jika akar masalahnya adalah regresi kueri atau tata letak data, perbaiki hal tersebut sebelum menutupinya dengan cache yang lebih besar.
Langkah 7: Validasi dan simpan bukti
Putar ulang bauran beban kerja representatif, bandingkan p50 dan tail latency, throughput, tingkat kesalahan, byte baca/tulis, wait event, dan metrik OS. Konfirmasikan bahwa hasil kueri dan perilaku replikasi tetap benar. Simpan kedua jendela data dan catatan keputusan sehingga restart atau reset statistik di kemudian hari tetap terlihat.
Jawaban model
“Pertama-tama saya akan mencatat versi, waktu restart dan reset, bauran beban kerja, metrik penyimpanan, dan dua snapshot pgstatio. Saya akan membandingkan delta berdasarkan tipe backend, objek, konteks, dan operasi, lalu menghubungkan kueri yang dicurigai dengan buffer EXPLAIN ANALYZE, timing I/O, WAL, wait event, serta aktivitas checkpoint atau vacuum. Saya tidak akan memperlakukan counter kumulatif atau satu rasio cache-hit sebagai diagnosis akhir.
Setelah mengklasifikasikan tekanan cache, latensi penyimpanan, persaingan checkpoint, aktivitas vacuum, atau regresi rencana, saya akan membuat satu perubahan yang dapat dibatalkan dan memutar ulang beban kerja representatif. Keberhasilan membutuhkan tail latency yang lebih rendah dengan kebenaran data, throughput, cadangan sumber daya, dan perilaku replikasi yang stabil. Bukti dan nilai rollback akan dicatat dalam rekaman insiden.”
Kesalahan umum
- Menjumlahkan setiap baris pgstatio → dimensi yang tidak kompatibel menyesatkan → kelompokkan berdasarkan backend, objek, konteks, dan operasi.
- Membandingkan counter tanpa jendela waktu → laju yang dihasilkan tidak nyata → ambil delta berjangka waktu dan catat reset.
- Menganggap rasio cache hit sebagai bukti mutlak → latensi penyimpanan dan bentuk rencana tersembunyi → korelasikan dengan byte, timing, wait event, dan data OS.
- Menjalankan EXPLAIN ANALYZE di produksi secara membabi buta → mengganggu beban kerja → gunakan replika yang aman atau sampel terkontrol.
- Mengubah banyak pengaturan sekaligus → hubungan sebab-akibat hilang → ubah satu variabel yang dapat dibatalkan.
- Mengabaikan vacuum dan checkpoint → pekerjaan latar belakang disalahkan pada kueri → atribusikan konteks backend secara terpisah.
- Memperbaiki gejala dengan menambah memori → tekanan host semakin parah → validasi kapasitas dan penyebab kueri/tata letak data terlebih dahulu.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Apakah pgstatio baru di PostgreSQL 18?
View ini sudah ada sebelum versi 18, sementara PostgreSQL 18 menambahkan visibilitas I/O lebih lanjut seperti kolom pelaporan byte dan statistik per-backend. Selalu gunakan dokumentasi untuk versi mayor yang digunakan.
Pertanyaan lanjutan 2: Bagaimana cara menghitung suatu laju (rate)?
Ambil dua snapshot beserta timestamp-nya, kurangkan nilai counter, bagi dengan waktu yang berlalu, dan catat restart atau reset statistik apa pun di antara keduanya.
Pertanyaan lanjutan 3: Apakah read_bytes yang tinggi membuktikan kueri yang buruk?
Tidak. Pemindaian besar mungkin disengaja. Bandingkan ekspektasi rencana, jumlah baris, latensi, status cache, dan SLO beban kerja sebelum melabelinya sebagai regresi.
Pertanyaan lanjutan 4: Mengapa perlu memeriksa backend_type?
Klien foreground, checkpointer, background writer, autovacuum, dan pekerjaan pemeliharaan menciptakan pola persaingan sumber daya serta opsi remediasi yang berbeda.
Pertanyaan lanjutan 5: Kapan timing I/O EXPLAIN tidak aman?
Pada jalur produksi yang sibuk, overhead pengukuran dapat mendistorsi latensi. Gunakan replika, kueri sampel, atau jendela terkontrol dan nyatakan batasan tersebut.
Pertanyaan lanjutan 6: Apa yang membuktikan bahwa perbaikan berhasil?
Pengujian beban kerja representatif yang berulang menunjukkan peningkatan tail latency dan throughput tanpa adanya regresi kebenaran data, replikasi, atau kapasitas, dengan bukti sebelum dan sesudah yang terdokumentasi dengan baik.