Vakum / otovakum işlemi ne kadar zaman alır?

Bazıları milyonlarca kayıt tutan çeşitli rollere sahip tablolar içeren büyük (yüzlerce konser) bir veritabanı yönetiyorum. Bazı tablolarda yalnızca çok sayıda ekleme ve silme, bazı diğer birkaç ekleme ve çok sayıda güncelleme bulunur.

Veritabanı, 16 gigabayt RAM ile Debian 6.0 amd64 sisteminde PostgreSQL 8.4 üzerinde çalışır.

Soru bazen bir masadaki otovakum işlemidir, tamamlanması çok uzun zaman alır (günler). Kabaca belirli bir vakum komutunun ne kadar zaman alacağını, iptal edip etmeyeceğimize karar verebilmek istiyorum. Ayrıca postgres vakum operasyonları için bir ilerleme göstergesi olsaydı, gerçekten yararlı olurdu.

Düzenle:

Kurşun geçirmez bir çözüm aramıyorum. Karar vermek için sadece ölü kapların sayısı veya gerekli G / Ç baytlarının sayısı hakkında kabaca bir ipucu yeterlidir. Ne zaman VACUUMbitecek, hiçbir ipucu olmaması gerçekten can sıkıcı .

pg_catalog.pg_stat_all_tablesÖlü kaplumbağalar için bir sütun olduğunu gördüm . Bu nedenle, daha ANALYZEönce tabloya sahip olması gerektiği anlamına gelse bile, bir tahmin yapmak mümkündür . Öte yandan autovacuum_vacuum_thresholdve autovacuum_vacuum_scale_factorayarlar tek başına postgres'in kendisinin masalardaki değişim miktarı hakkında bir şeyler bildiğini ve muhtemelen DBA'nın ellerine koyduğunu kanıtlıyor .

Çalıştırdığımda VACUUM VERBOSE, yalnızca tabloların değil, aynı zamanda bunlardaki dizinlerin de işlendiğini gördüğüm için hangi sorguyu çalıştırılacağından emin değilim .

Benim PostgreSQL (8.3) üzerinde bu hile kullanın:

1. Tablonun disk boyutunu kullanarak alıyorum pg_total_relation_size()- bu dizinler ve hangi VACUUMsüreçler TOAST boyutu içerir . Bu bana kaç bayt VACUUMokuması gerektiği fikrini verir .
2. VACUUMMasaya koşuyorum .
3. Ben bulmak pidait VACUUMsürecinde (içinde pg_catalog.pg_stat_activity).
4. Linux kabuğunda çalıştırıyorum while true; do cat /proc/123/io | grep read_bytes; sleep 60; done( 123pid nerede ) - bu bana şimdiye kadar disk tarafından işlem tarafından okunan baytları gösteriyor.

Bu bana her dakika kaç baytın işlendiğine (okunduğuna) dair kaba bir fikir veriyor VACUUM. Bunu tahmin VACUUMkimin disk boyutu ben 1. adımdaki biliyoruz (endeksler ve TOST dahil) bütün tablo, okumak gerekir.

Tablonun sayfalarının çoğunun diskten okunması (Postgres paylaşılan belleğinde bulunmaması) için read_bytesyeterince büyük olduğunu varsayıyorum, bu nedenle alan bir ilerleme sayacı olarak kullanılacak kadar iyi.

Bunu her yaptığımda, işlem tarafından okunan toplam bayt toplam ilişki boyutundan% 5'ten fazla değildi, bu yüzden bu yaklaşımın sizin için yeterince iyi olabileceğini düşünüyorum.

Bunu belirlemek çok zor. Otomatik vakumlamayı ayarlayabilirsiniz daha agresif veya daha hafif olacak . Ancak hafif olarak ayarlandığında ve geride kaldığında ve temel G / Ç yükü çok yüksek olduğunda, asla uygun vakumlu duruma ulaşamayabilir - o zaman sürecin çalıştığını ve çalıştığını ve çalıştığını görürsünüz. Ayrıca, sonraki PostreSQL sürümleri çok gelişmiş oto-vakum kapasitelerine sahiptir, bu tek başına bunlardan birine geçmek için yeterli olabilir (tercihen en sonuncusu olarak 9.2).

İlerleme çubuğu iyi bir fikir gibi geliyor ama anlamlı bir şekilde uygulanmasının o kadar kolay olmadığını düşünüyorum. Masalarınızda sabit yükünüz olduğu için, ilerlemenin görünüşte geriye doğru gitmesi oldukça olasıdır (yani, ölü satır sayısı / yüzde azaltmak yerine artmaktadır) - o zaman hangi sonucu çiziyorsunuz?

Üretimimizde en büyük tablolardan birinde şu kütük vardı:

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

Bu, en kötü kaynak tüketimi, diğer tüm tablolar 2 saniyeden az sürdü.

Bu tür günlükleri görmek için bunu yürütmelisiniz:

alter system set log_autovacuum_min_duration TO 5; 

(5 msn için), yapılandırma dosyasını yeniden yükleyin.

Bu gönderiyi ve bu gönderiyi buldum yararlı , ancak diğerlerinin de belirttiği gibi, işlemin birkaç ayrı işlemi içerdiğinden, vakumun genel ilerlemesini hesaplamak zor olabilir.

Bu sorguyu işin toplu gibi görünüyor vakum tablo tarama ilerlemesini izlemek için kullanın:

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;

Bununla birlikte, bu daha sonra gerçekleşen dizin taramasını içermez ve bir ton dizininiz varsa daha uzun değilse daha uzun sürebilir. Ne yazık ki, indeks tarama / vakumlamayı izlemenin bir yolunu bulamıyorum.