Bagaimanakah anda mereka bentuk pengurusan kapasiti pekerja autovacuum PostgreSQL 18?

Soalan dan konteks

Sebuah kluster PostgreSQL 18 mengendalikan jadual pesanan yang kerap dikemas kini dan jadual arkib berfrekuensi rendah. Tuple mati (dead tuples) terkumpul, pertanyaan menjadi perlahan, dan I/O cakera melonjak. Reka bentuk pengurusan kapasiti pekerja autovacuum dan terangkan autovacuum_worker_slots, autovacuum_max_workers, tetapan jadual, penyelenggaraan selari dan kompromi (trade-offs) semasa insiden.

Perkara yang dinilai oleh penemu duga

• Sama ada anda mengasingkan kapasiti pekerja, pekerja serentak, ambang pencetus dan keselarian setiap arahan.
• Sama ada anda menerangkan autovacuum_worker_slots dalam PostgreSQL 18 dan batasan penalaan masa jalannya.
• Sama ada anda menggunakan paparan kemajuan, tuple mati, usia transaksi (transaction age) dan metrik I/O untuk mengesan kekangan (bottlenecks).
• Sama ada anda mengutamakan perlindungan pembalutan ID transaksi (wraparound) berbanding kependaman dan tekanan cakera.

Soalan penjelasan awal

Beban kerja

Apakah kadar kemas kini, pemadaman dan pemasukan bagi setiap pangkalan data dan jadual? Adakah jadual hangat (hot tables) mempunyai banyak indeks, transaksi yang panjang atau pemadaman pukal? Adakah SLA tertumpu pada kependaman pertanyaan, daya pemprosesan penulisan atau pertumbuhan cakera?

Had sumber

Apakah had CPU, I/O, memori dan pertumbuhan cakera? Bagaimanakah max_worker_processes, max_parallel_workers, maintenance_work_mem, dan had kontena atau VM dikonfigurasikan?

Risiko dan pemulihan

Adakah kluster menghampiri pembalutan ID transaksi? Bolehkah anda menjalankan VACUUM manual atau pertukaran partisyen di luar waktu puncak? Jadual manakah yang boleh mengurangkan penulisan buat sementara waktu, dan bukti apakah yang mesti kekal boleh diaudit?

Jawapan 30 saat

Saya akan mengukur pertumbuhan tuple mati, kelewatan autovacuum, usia transaksi dan I/O mengikut jadual dan pangkalan data, kemudian menentukan saiz slot pekerja dan keserakikan normal. Jadual hangat menerima faktor skala yang lebih rendah dan ambang yang sesuai; jadual sejuk mengelakkan imbasan yang tidak perlu. Sebelum meningkatkan keserakikan, saya akan memeriksa CPU, I/O dan memori penyelenggaraan, kemudian menggunakan paparan kemajuan untuk mengesahkan pengurangan tunggakan. Risiko pembalutan adalah keutamaan tertinggi; pengehadan kadar dan penyelenggaraan manual yang disasarkan adalah kawalan kecemasan yang terikat had.

Penyelesaian mendalam

1. Petakan hierarki sumber

autovacuum_worker_slots menempah slot bahagian belakang (backend slots) untuk pekerja autovacuum semasa pelayan dimulakan. PostgreSQL 18 biasanya menggunakan nilai lalai 16 slot, tertakluk kepada sokongan kernel. autovacuum_max_workers mengehadkan proses autovacuum yang berjalan serentak dan tidak boleh melebihi kolam slot yang berkesan. max_worker_processes, CPU dan I/O kekal sebagai sumber yang dikongsi, jadi satu tetapan tidak boleh ditala secara berasingan.

2. Reka bentuk keserakikan berlapis

Tetapkan autovacuum_worker_slots sebagai kolam kapasiti untuk beban puncak yang mampu ditampung, kemudian gunakan autovacuum_max_workers untuk keserakikan biasa. PostgreSQL 18 membenarkan autovacuum_max_workers diubah semasa masa jalan sehingga had slot, manakala slot itu sendiri memerlukan pelayan dimulakan semula. Sebelum meningkatkan kapasiti, tempah proses latar belakang, sambungan dan semafor sistem pengendalian.

3. Tetapkan pencetus khusus mengikut jadual

Ambang global menyediakan garis dasar keselamatan. Jadual hangat boleh merendahkan autovacuum_vacuum_scale_factor atau menetapkan autovacuum_vacuum_threshold yang lebih sesuai; jadual dengan sisipan yang tinggi juga memerlukan autovacuum_vacuum_insert_threshold. Kira penggantian jadual daripada pertumbuhan tuple mati dan saiz jadual supaya jadual kecil tidak tertangguh dan jadual besar tidak diimbas terlalu kerap.

4. Hadkan sumber untuk satu VACUUM

VACUUM biasa boleh berjalan bersama-sama operasi baca dan tulis, tetapi ia menjana I/O. max_parallel_maintenance_workers digunakan untuk pembinaan indeks dan VACUUM tanpa FULL; pekerja sebenar juga dihadkan oleh max_worker_processes dan max_parallel_workers. maintenance_work_mem digunakan untuk keseluruhan arahan utiliti, manakala CPU dan I/O masih boleh meningkat dengan keselarian.

5. Kendalikan pembalutan dan transaksi yang panjang

Walaupun autovacuum biasa dinyahdayakan, PostgreSQL melancarkan kerja yang diperlukan untuk mengelakkan pembalutan ID transaksi. Pantau usia transaksi tertua, kemajuan pembekuan (freeze), dan transaksi panjang yang menyekat VACUUM. Perlindungan pembalutan tidak boleh diatasi oleh dasar kelewatan biasa. Jika perlu, tamatkan transaksi yang menyekat, jeda kerja kelompok berkeutamaan rendah dan selenggara jadual sasaran.

6. Bina kebolehcerapan yang boleh diambil tindakan

Gunakan pg_stat_progress_vacuum untuk fasa, blok heap, blok yang dibersihkan, kitaran indeks, bait tuple mati dan kelewatan kos. Gabungkannya dengan nilai pg_stat_all_tables seperti n_dead_tup, last_autovacuum, last_autoanalyze, saiz jadual dan usia transaksi untuk menganggarkan tunggakan dan masa penyiapan. Simpan bukti tugasan yang perlahan dengan log_autovacuum_min_duration; gunakan pg_stat_io untuk mengasingkan I/O pekerja autovacuum.

7. Tala secara beransur-ansur dan laksanakan pengunduran (rollback)

Ubah satu dimensi pada satu masa: tingkatkan slot atau bilangan pekerja maksimum, perhatikan CPU, I/O, kependaman dan tunggakan, kemudian teruskan. Jika pertikaian sumber meningkat, kurangkan keserakikan, rendahkan kekerapan jadual atau jadualkan semula kerja kelompok. Catatkan versi, skop jadual, tetingkap metrik dan nilai pengunduran bagi setiap perubahan supaya tunggakan sementara tidak disalah anggap sebagai kekurangan kapasiti kekal.

Contoh jawapan yang mantap

Saya menganggap slot pekerja sebagai kolam sumber, pekerja maksimum sebagai keserakikan normal, dan ambang jadual sebagai penjana kerja. Jadual hangat mendapat ambang berdasarkan pertumbuhan tuple mati; jadual sejuk mengelakkan imbasan yang tidak perlu. Mula-mula, saya mengukur kesan keserakikan pekerja terhadap I/O dan kependaman pertanyaan, kemudian meningkatkannya secara beransur-ansur. Kebolehcerapan menggabungkan fasa kemajuan, n_dead_tup, usia transaksi, log autovacuum dan pg_stat_io. Pembalutan mengatasi kependaman biasa, dan transaksi panjang yang menyekat dikendalikan sebelum penalaan rutin. Setiap perubahan mempunyai rekod pengunduran.

Kesilapan biasa

• Meningkatkan autovacuum_max_workers tanpa menambah slot atau memeriksa kolam pekerja kongsi.
• Menganggap slot sebagai keserakikan sebenar walaupun ia dikonfigurasikan semasa permulaan.
• Menggunakan satu faktor skala untuk setiap jadual, menangguhkan jadual kecil dan mengimbas jadual besar secara berlebihan.
• Menggunakan VACUUM FULL sebagai penyelenggaraan rutin walaupun terdapat kunci (locks) dan kos penulisan semula jadual.
• Memerhatikan ruang cakera sambil mengabaikan usia transaksi, tuple mati dan fasa kemajuan.
• Menyahdayakan autovacuum demi kependaman dan melupakan perlindungan pembalutan.

Soalan susulan dan jawapan

Apakah perbezaan antara autovacuum_worker_slots dan autovacuum_max_workers?

Yang pertama menempah slot bahagian belakang pekerja semasa permulaan; yang kedua mengehadkan proses autovacuum yang berjalan serentak. Menaikkan pekerja maksimum melebihi slot berkesan tidak akan menghasilkan keserakikan tersebut. PostgreSQL 18 membenarkan perubahan pekerja maksimum masa jalan dalam had slot.

Adakah keserakikan yang lebih tinggi menjadikan VACUUM lebih pantas?

Tidak secara automatik. Ia mungkin memendekkan masa penyelenggaraan di samping meningkatkan penggunaan CPU, I/O dan pertikaian aplikasi. Nilaikannya bersama-sama dengan masa penyiapan tunggakan, kependaman pertanyaan dan puncak I/O secara serentak.

Mengapakah faktor skala khusus mengikut jadual digunakan?

Nisbah boleh menghasilkan bilangan mutlak tuple mati yang sangat besar pada jadual yang besar dan pencetus yang terlalu jarang pada jadual yang kecil. Penggantian jadual menyelaraskan kerja dengan kadar kemas kini, saiz dan SLA.

Bagaimanakah anda membuktikan bahawa I/O memperlahankan pekerja?

Gunakan fasa dan masa kelewatan pg_stat_progress_vacuum, hubung kaitkan baris pekerja autovacuum dalam pg_stat_io dengan kependaman cakera dan metrik pertanyaan aplikasi, serta bandingkan dalam tetingkap masa yang sama.

Bilakah kerja pembalutan mesti diutamakan?

Apabila usia transaksi tertua menghampiri ambang perlindungan, kemajuan pembekuan ketinggalan, atau kluster menjalankan autovacuum pencegahan pembalutan, singkirkan penyekat dan selesaikan pembekuan terlebih dahulu. Penalaan perniagaan rutin mesti memberi laluan kepada risiko tersebut.