Bagaimana Anda mendesain manajemen kapasitas worker autovacuum di PostgreSQL 18?

Pertanyaan dan konteks

Sebuah kluster PostgreSQL 18 melayani tabel pesanan dengan pembaruan tinggi dan tabel arsip berfrekuensi rendah. Tuple mati (dead tuples) menumpuk, kueri melambat, dan lonjakan I/O disk terjadi. Desain manajemen kapasitas worker autovacuum dan jelaskan autovacuum_worker_slots, autovacuum_max_workers, pengaturan tabel, pemeliharaan paralel, serta kompromi (trade-offs) saat insiden.

Apa yang dievaluasi oleh pewawancara

• Apakah Anda memisahkan kapasitas worker, worker konkuren, ambang batas pemicu, dan paralelisme per perintah.
• Apakah Anda menjelaskan autovacuum_worker_slots pada PostgreSQL 18 dan batas penyesuaian saat runtime-nya.
• Apakah Anda menggunakan progress view, dead tuple, usia transaksi (transaction age), dan metrik I/O untuk menemukan bottleneck.
• Apakah Anda memprioritaskan perlindungan transaksi ID wraparound dibandingkan latensi dan tekanan disk.

Pertanyaan klarifikasi di awal

Beban kerja

Berapa rasio pembaruan (update), penghapusan (delete), dan penyisipan (insert) per basis data dan tabel? Apakah tabel yang panas (hot table) memiliki banyak indeks, transaksi panjang, atau penghapusan massal? Apakah SLA berfokus pada latensi kueri, throughput penulisan, atau pertumbuhan disk?

Batasan sumber daya

Berapa batas CPU, I/O, memori, dan pertumbuhan disk? Bagaimana max_worker_processes, max_parallel_workers, maintenance_work_mem, serta batas kontainer atau VM dikonfigurasi?

Risiko dan pemulihan

Apakah kluster mendekati transaction ID wraparound? Bisakah Anda menjalankan VACUUM manual atau swap partisi di luar jam sibuk? Tabel mana yang dapat dikurangi aktivitas penulisannya untuk sementara, dan bukti apa yang harus tetap dapat diaudit?

Jawaban 30 detik

Saya akan mengukur pertumbuhan dead tuple, keterlambatan autovacuum, usia transaksi, dan I/O berdasarkan tabel dan basis data, lalu menentukan ukuran slot worker serta konkurensi normal. Tabel panas mendapatkan faktor skala yang lebih rendah dan ambang batas yang sesuai; tabel dingin menghindari pemindaian yang tidak perlu. Sebelum meningkatkan konkurensi, saya akan memeriksa CPU, I/O, dan memori pemeliharaan, lalu menggunakan progress view untuk memverifikasi pengurangan backlog. Risiko wraparound adalah prioritas utama; pembatasan laju (rate limiting) dan pemeliharaan manual yang terarah merupakan tindakan darurat yang terikat batas.

Solusi mendalam

1. Memetakan hierarki sumber daya

autovacuum_worker_slots memesan slot backend untuk worker autovacuum saat server dimulai. PostgreSQL 18 biasanya menetapkan default 16 slot, tergantung pada dukungan kernel. autovacuum_max_workers membatasi proses autovacuum yang berjalan bersamaan dan tidak boleh melebihi pool slot yang efektif. max_worker_processes, CPU, dan I/O tetap menjadi sumber daya bersama, sehingga satu pengaturan tidak dapat disesuaikan secara terpisah.

2. Mendesain konkurensi berlapis

Tetapkan autovacuum_worker_slots sebagai pool kapasitas untuk beban puncak yang sanggup Anda tangani, lalu gunakan autovacuum_max_workers untuk konkurensi normal. PostgreSQL 18 memungkinkan autovacuum_max_workers diubah saat runtime hingga batas slot, sedangkan slot itu sendiri memerlukan restart server. Sebelum meningkatkan kapasitas, cadangkan proses latar belakang, koneksi, dan semafor sistem operasi.

3. Menetapkan pemicu spesifik per tabel

Ambang batas global menyediakan baseline keselamatan. Tabel yang panas dapat menurunkan autovacuum_vacuum_scale_factor atau menetapkan autovacuum_vacuum_threshold yang lebih sesuai; tabel dengan banyak penyisipan juga memerlukan autovacuum_vacuum_insert_threshold. Hitung override tabel dari pertumbuhan dead tuple dan ukuran tabel sehingga tabel kecil tidak tertunda dan tabel besar tidak dipindai terlalu sering.

4. Membatasi sumber daya satu VACUUM

VACUUM reguler dapat berjalan bersamaan dengan operasi baca dan tulis, tetapi operasi ini menghasilkan I/O. max_parallel_maintenance_workers berlaku untuk pembuatan indeks dan VACUUM tanpa FULL; worker sebenarnya juga dibatasi oleh max_worker_processes dan max_parallel_workers. maintenance_work_mem diterapkan pada perintah utilitas secara keseluruhan, sementara CPU dan I/O masih dapat meningkat dengan adanya paralelisme.

5. Menangani wraparound dan transaksi berdurasi panjang

Bahkan ketika autovacuum reguler dinonaktifkan, PostgreSQL tetap menjalankan pekerjaan yang diperlukan untuk mencegah transaction ID wraparound. Pantau usia transaksi tertua, progres pembekuan (freeze), dan transaksi panjang yang memblokir VACUUM. Perlindungan wraparound tidak dapat diabaikan oleh kebijakan penundaan biasa. Jika perlu, hentikan transaksi pemblokir, jeda pekerjaan batch berprioritas rendah, dan lakukan pemeliharaan pada tabel target.

6. Membangun observabilitas yang dapat ditindaklanjuti

Gunakan pg_stat_progress_vacuum untuk fase, blok heap, blok yang dibersihkan, siklus indeks, bita dead tuple, dan penundaan biaya (cost delay). Gabungkan dengan nilai pg_stat_all_tables seperti n_dead_tup, last_autovacuum, last_autoanalyze, ukuran tabel, dan usia transaksi untuk memperkirakan backlog dan waktu penyelesaian. Simpan bukti tugas yang lambat dengan log_autovacuum_min_duration; gunakan pg_stat_io untuk mengisolasi I/O worker autovacuum.

7. Lakukan penyesuaian secara bertahap dan siapkan rollback

Ubah satu dimensi pada satu waktu: tingkatkan slot atau max worker, amati CPU, I/O, latensi, dan backlog, lalu lanjutkan. Jika perebutan sumber daya (contention) meningkat, kurangi konkurensi, turunkan frekuensi tabel, atau jadwalkan ulang pekerjaan batch. Catat versi, cakupan tabel, jendela metrik, dan nilai rollback untuk setiap perubahan agar penumpukan singkat tidak disalahartikan sebagai kekurangan kapasitas permanen.

Contoh jawaban yang kuat

Saya memperlakukan slot worker sebagai pool sumber daya, max worker sebagai konkurensi normal, dan ambang batas tabel sebagai generator pekerjaan. Tabel panas mendapatkan ambang batas berdasarkan pertumbuhan dead tuple; tabel dingin menghindari pemindaian yang tidak perlu. Pertama, saya mengukur efek konkurensi worker terhadap I/O dan latensi kueri, lalu meningkatkannya secara bertahap. Observabilitas menggabungkan fase progres, n_dead_tup, usia transaksi, log autovacuum, dan pg_stat_io. Wraparound lebih diutamakan daripada latensi biasa, dan transaksi panjang yang memblokir ditangani sebelum penyesuaian rutin. Setiap perubahan memiliki catatan rollback.

Kesalahan umum

• Meningkatkan autovacuum_max_workers tanpa menambahkan slot atau memeriksa shared worker pool.
• Memperlakukan slot sebagai konkurensi aktual meskipun itu hanya dikonfigurasi saat startup.
• Menerapkan satu faktor skala untuk setiap tabel, yang menunda tabel kecil dan memindai tabel besar secara berlebihan.
• Menggunakan VACUUM FULL sebagai pemeliharaan rutin terlepas dari kunci (locks) dan biaya penulisan ulang tabel.
• Memperhatikan ruang disk sambil mengabaikan usia transaksi, dead tuple, dan fase progres.
• Menonaktifkan autovacuum demi latensi dan melupakan perlindungan wraparound.

Pertanyaan lanjutan dan jawaban

Apa perbedaan antara autovacuum_worker_slots dan autovacuum_max_workers?

Yang pertama memesan slot backend worker saat startup; yang kedua membatasi proses autovacuum yang berjalan bersamaan. Menaikkan max worker di atas slot efektif tidak akan menghasilkan konkurensi tersebut. PostgreSQL 18 memungkinkan perubahan max worker saat runtime dalam batas slot.

Apakah konkurensi yang lebih tinggi membuat VACUUM lebih cepat?

Tidak secara otomatis. Ini dapat mempersingkat waktu pemeliharaan sekaligus meningkatkan penggunaan CPU, I/O, dan perebutan sumber daya aplikasi. Nilailah bersamaan dengan waktu penyelesaian backlog, latensi kueri, dan lonjakan I/O secara terpadu.

Mengapa menggunakan faktor skala spesifik per tabel?

Sebuah rasio dapat berubah menjadi jumlah absolut dead tuple yang sangat besar pada tabel besar dan pemicu yang terlalu jarang pada tabel kecil. Penyesuaian spesifik tabel menyelaraskan pekerjaan dengan laju pembaruan, ukuran, dan SLA.

Bagaimana Anda membuktikan bahwa I/O memperlambat worker?

Gunakan fase dan waktu tunda pada pg_stat_progress_vacuum, korelasikan baris worker autovacuum di pg_stat_io dengan latensi disk dan metrik kueri aplikasi, serta bandingkan pada rentang waktu yang sama.

Kapan pekerjaan wraparound harus diprioritaskan?

Ketika usia transaksi tertua mendekati ambang batas perlindungan, progres pembekuan tertinggal, atau kluster menjalankan autovacuum pencegahan wraparound, singkirkan pemblokir dan selesaikan pembekuan terlebih dahulu. Penyesuaian bisnis rutin harus mengalah pada risiko tersebut.