Haruskah saya secara manual VACUUM database PostgreSQL saya jika autovacuum dihidupkan?

Saya menggunakan perangkat lunak yang membuat database PostgreSQL besar (ada tabel dengan sejuta baris di dalamnya) dan pengembang mengatakan saya harus VACUUMdan ANALYZEsecara berkala. Tetapi default database PostgreSQL autovacuumdihidupkan.

Haruskah saya vakum / menganalisis sama sekali? Apa manfaatnya? Apa perbedaan antara vakum otomatis dan manual

Misalnya, dalam Pgadmin3, saya punya ini:

Saya setuju dengan ETL bahwa tidak ada jawaban singkat. Ukuran bukan satu-satunya hal yang penting - kami menjalankan PostgreSQL OLTP Database yang cukup besar (dengan beberapa tabel> 100.000.000 baris) di bawah beban berat dan saat ini kami hanya mengandalkan autovacuum saja.

Namun, ada dua hal yang penting bagi saya:

• Tampaknya ada konsensus, bahwa autovacuum tidak boleh dimatikan, kecuali jika Anda memiliki beban kerja yang sangat jelas pada database Anda dan Anda tahu persis apa yang Anda lakukan. Tapi, tentu saja, Anda bisa melakukan tambahan VACUUMdan / atau ANALYZElari.

• Sebelum mempertimbangkan langkah tambahan VACUUM, saya akan memeriksa bagaimana autovacuum terus berjalan. Anda dapat memeriksa apakah ada tabel di luar ambang batas autovacuum dengan menanyakan pg_stat_user_tablesdan pg_class. Saya memposting pertanyaan seperti itu di utas lain, yang mungkin menarik: Aggressive Autovacuum di PostgreSQL .

  Sayangnya, tidak semudah itu (yaitu tidak mungkin saat ini) untuk melakukan pemeriksaan serupa untuk ambang batas analisis otomatis. Namun, secara otomatis menganalisis tendangan jauh sebelum autovacuum secara default dan itu jauh lebih murah. Jadi, pada dasarnya jika database Anda dapat mengikuti autovacuum, mungkin akan baik-baik saja dengan analisis otomatis juga. Tanggal analisis otomatis terakhir juga dapat ditanyakan dari pg_stat_user_tables.

Beberapa bagian dari dokumentasi PostgreSQL (paling bagus), yang menurut saya bermanfaat:

• Penyedotan Rutin
• Kolektor Statistik

Autovacuum harus menutupinya dengan baik, kecuali Anda salah mengkonfigurasi sesuatu. Jawaban lain sudah mencakup itu.

Ada satu kasus yang jelas untuk manual VACUUM (dan yang lebih penting: manual ANALYZE) meskipun: tabel sementara , mereka tidak dianggap oleh setan autovacuum. Saya mengutip manualnya di CREATE TABLEsini :

The autovacuum daemon tidak bisa akses dan karena itu tidak dapat vakum atau menganalisis tabel sementara. Untuk alasan ini, operasi vakum dan analisis yang tepat harus dilakukan melalui perintah SQL sesi. Misalnya, jika tabel sementara akan digunakan dalam kueri yang kompleks, sebaiknya jalankan ANALYZEdi tabel sementara setelah diisi.

Tidak ada jawaban singkat untuk itu karena itu tergantung pada banyak faktor. Apakah sistemnya lambat? Apakah vakum otomatis menyentuh tabel ini? dll.

Berikut ini beberapa tautan bagus tentang hal ini:

• Pertimbangan kinerja PostgreSQL
• Optimalisasi Kinerja (wiki PostgreSQL)
• Pengantar VACUUM, ANALYZE, EXPLAIN, dan COUNT (sumber yang sama)
• Menafsirkan Tampilan pg_stat, Memahami Tampilan pg_stat

Untuk membuat keputusan yang jelas, dibutuhkan pemahaman tentang database itu sendiri dan rincian lebih lanjut tentang apa yang terjadi.

Saya tidak berpikir Anda perlu menyedot debu secara manual, kecuali jika Anda mulai melihat penurunan kinerja. Namun, saya akan sangat menyarankan untuk meninjau pengaturan vakum dan autovacuum Anda dan menyesuaikannya dengan kebutuhan Anda

Untuk melihat pengaturan Anda saat ini, jalankan kueri ini:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

Sebagian besar bidang sudah jelas, tetapi berikut ini adalah dokumentasi untuknya: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

Saya akan mengatakan, bahwa tujuan Anda adalah mengkonfigurasi autovacuum untuk membersihkan sampah secara konsisten, tetapi jangan terus-menerus menjalankan autovacuum

Pengaturan yang paling penting adalah:

• autovacuum_vacuum_scale_factor - menentukan persentase tuple yang dapat mati sebelum pembersihan dipicu. Nilai standar = 0,2
• autovacuum_vacuum_threshold - jumlah minimum tuple mati sebelum pembersihan dipicu. Nilai standar = 50

Ambang batas membantu mencegah proses pembersihan yang terlalu sering dipicu untuk tabel kecil.

Pengaturan default berfungsi dengan baik, kecuali jika Anda memiliki tabel yang sangat besar. Sederhananya, jika Anda memiliki meja yang membutuhkan 100GB, Anda akan mengumpulkan 20GB sampah, sebelum autovacuum akan dipicu. Jadi, saya biasanya merekomendasikan untuk mengatur faktor skala rendah. Seberapa rendah Anda harus menentukan sendiri. Saya menggunakan 0,05 pada proyek saya saat ini

Ambang batas juga dapat ditingkatkan. Banyak aplikasi memiliki beberapa tabel, yang sering diperbarui dan 50 tupel tidak banyak. Meningkatkannya menjadi 1000 seharusnya tidak menimbulkan masalah, tapi tentu saja, Anda harus mempertimbangkan kasus Anda sendiri

Anda juga dapat menyempurnakan autovacuum dan memiliki pengaturan berbeda untuk beberapa tabel Anda

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Jika Anda mengkonfigurasi scale_factor dan ambang batas, Anda akan baik-baik saja. Anda juga dapat meningkatkan autovacuum_vacuum_cost_limit, yang secara default sama dengan vacuum_cost_limit, yang diatur ke 200. Ini adalah fitur vakum yang sangat penting, yang tidak memungkinkannya memakan semua sumber daya dan memungkinkan aplikasi Anda untuk beroperasi dengan data bahkan selama proses menyedot debu , tetapi nilai standar terlalu rendah. Meningkatkannya menjadi 1000 seharusnya tidak menyebabkan penundaan yang signifikan, tetapi akan memungkinkan proses vakum selesai lebih cepat

Tentu saja, Anda juga dapat menjalankan vakum secara manual. Dalam kasus yang paling sederhana, Anda dapat memiliki pekerjaan cron sederhana, yang akan melakukan pembersihan penuh setiap malam, ketika DB Anda tidak sering diakses

Semoga itu bisa membantu!