Berapa lama waktu yang dibutuhkan untuk operasi vakum / autovacuum?

Saya mengelola database besar (beberapa pertunjukan) yang berisi tabel dengan berbagai peran, beberapa dari mereka memegang jutaan catatan. Beberapa tabel hanya menerima sejumlah besar sisipan dan penghapusan, beberapa sisipan lainnya dan sejumlah besar pembaruan.

Basis data berjalan pada PostgreSQL 8.4 pada sistem Debian 6.0 amd64 dengan RAM 16 gigabytes.

Pertanyaannya adalah kadang-kadang proses autovacuum di atas meja, membutuhkan waktu sangat lama (hari) untuk menyelesaikannya. Saya ingin mengetahui secara kasar berapa banyak waktu yang dibutuhkan oleh perintah vakum tertentu, untuk dapat memutuskan apakah akan membatalkannya atau tidak. Juga jika ada indikator kemajuan untuk operasi vakum postgres, itu akan sangat membantu.

Edit:

Saya tidak mencari solusi anti peluru. Hanya petunjuk kasar tentang jumlah tupel mati atau byte I / O yang diperlukan sudah cukup untuk memutuskan. Sangat menyebalkan tidak memiliki petunjuk kapan VACUUMakan selesai, apa pun.

Saya telah melihat bahwa pg_catalog.pg_stat_all_tablesmemiliki kolom untuk jumlah tupel mati. Jadi adalah mungkin untuk memiliki estimasi, bahkan jika itu berarti kita harus ke ANALYZEtabel sebelumnya. Di sisi lain, autovacuum_vacuum_thresholddan autovacuum_vacuum_scale_factorpengaturan sendiri membuktikan bahwa postgres sendiri tahu sesuatu tentang jumlah perubahan pada tabel dan mungkin menempatkannya di tangan DBA juga.

Saya tidak yakin permintaan apa yang harus dijalankan, karena ketika saya menjalankan VACUUM VERBOSE, saya melihat bahwa tidak hanya tabel, tetapi indeks juga sedang diproses.

Pada PostgreSQL saya (8.3) saya menggunakan trik ini:

1. Saya mendapatkan ukuran disk tabel menggunakan pg_total_relation_size()- ini termasuk indeks dan ukuran TOAST, yang merupakan VACUUMproses apa . Ini memberi saya ide berapa byte yang VACUUMharus dibaca.
2. Saya berlari VACUUMdi atas meja.
3. Saya menemukan piddari VACUUMproses (di pg_catalog.pg_stat_activity).
4. Di Linux shell saya jalankan while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(di mana 123pid) - ini menunjukkan kepada saya byte yang dibaca oleh proses dari disk sejauh ini.

Ini memberi saya gambaran kasar tentang berapa banyak byte yang diproses (baca) setiap menit oleh VACUUM. Saya menganggap bahwa VACUUMharus membaca seluruh tabel (termasuk indeks dan TOAST), yang ukuran disk saya tahu dari langkah 1.

Saya berasumsi bahwa tabelnya cukup besar sehingga sebagian besar halamannya harus dibaca dari disk (tidak ada dalam memori bersama Postgres), sehingga read_bytesbidangnya cukup baik untuk digunakan sebagai penghitung kemajuan.

Setiap kali saya melakukan ini, total byte yang dibaca oleh proses tidak lebih dari 5% dari ukuran total relasi, jadi saya kira pendekatan ini mungkin cukup baik untuk Anda.

Ini sangat sulit ditentukan. Anda dapat menyetel autovacuuming menjadi lebih agresif atau lebih ringan. Tetapi ketika diatur ke ringan dan tertinggal di belakang dan beban I / O dasar terlalu tinggi, bisa terjadi bahwa ia tidak pernah mencapai kondisi hampa udara yang tepat - maka Anda melihat proses berjalan dan berjalan dan berjalan. Selain itu, edisi PostreSQL yang lebih baru memiliki kemampuan autovacuum yang jauh lebih baik, ini saja mungkin cukup untuk berpindah ke salah satunya (lebih disukai 9,2 sebagai yang terbaru).

Bilah kemajuan kedengarannya ide yang bagus tapi saya membayangkan itu tidak mudah untuk diimplementasikan secara bermakna. Karena Anda memiliki beban konstan pada tabel Anda, sangat mungkin bahwa kemajuan tampaknya mundur (maksud saya bahwa jumlah deadline / persentase meningkat bukannya menurun) - lalu kesimpulan apa yang Anda ambil?

Dalam produksi kami, salah satu tabel terbesar memiliki log ini:

pages: 0 removed, 1801722 remain
tuples: 238912 removed, 42582083 remain, 1396 are dead but not yet removable
buffer usage: 9477565 hits, 3834218 misses, 2220101 dirtied
avg read rate: 2.976 MB/s, avg write rate: 1.723 MB/s
system usage: CPU 68.47s/177.49u sec elapsed 10065.08 sec

Sejauh ini konsumsi sumber daya terburuk, semua tabel lainnya hanya memakan waktu kurang dari 2 detik.

Untuk melihat jenis-jenis log ini, Anda harus menjalankan ini:

alter system set log_autovacuum_min_duration TO 5; 

(selama 5 ms), muat ulang file konfigurasi.

Saya menemukan posting ini dan posting ini bermanfaat, tetapi seperti yang lain telah disebutkan, mungkin sulit untuk menghitung kemajuan vakum secara keseluruhan, karena prosesnya melibatkan beberapa operasi terpisah.

Saya menggunakan kueri ini untuk memantau kemajuan pemindaian tabel vakum, yang tampaknya merupakan bagian terbesar dari pekerjaan:

SELECT heap_blks_scanned/cast(heap_blks_total as numeric)*100 as heap_blks_percent, progress.*, activity.query
FROM pg_stat_progress_vacuum AS progress
INNER JOIN pg_stat_activity AS activity ON activity.pid = progress.pid;

Namun, ini tidak akan mencakup pemindaian indeks, yang terjadi setelahnya, dan dapat memakan waktu, jika tidak lebih lama, jika Anda memiliki satu ton indeks. Sayangnya, saya tidak dapat menemukan cara untuk memantau pemindaian indeks / penyedotan.