Ile czasu zajmie działanie odkurzania / automatycznego odkurzania?

Zarządzam dużą (kilkaset koncertów) bazą danych zawierającą tabele z różnymi rolami, niektóre z nich zawierają miliony rekordów. Niektóre tabele otrzymują tylko dużą liczbę wstawek i usunięć, inne kilka wstawek i dużą liczbę aktualizacji.

Baza danych działa na PostgreSQL 8.4 w systemie Debian 6.0 amd64 z 16 gigabajtami pamięci RAM.

Czasami pojawia się pytanie o proces automatycznej próżni na stole, którego wypełnienie zajmuje bardzo dużo czasu (dni). Chcę być w stanie z grubsza określić, ile czasu zajmie dane polecenie próżniowe, aby móc zdecydować, czy je anulować, czy nie. Byłoby też bardzo pomocne, gdyby istniał wskaźnik postępu dla operacji próżniowych postgres.

Edytować:

Nie szukam rozwiązania kuloodpornego. Wystarczy tylko przybliżona wskazówka na temat liczby martwych krotek lub niezbędnych bajtów We / Wy. To naprawdę denerwujące, że nie mam pojęcia, kiedy VACUUMsię skończy.

Widziałem, że pg_catalog.pg_stat_all_tablesma kolumnę z liczbą martwych krotek. Możliwe jest więc oszacowanie, nawet jeśli oznacza to, że należy wcześniej do ANALYZEtabeli. Z drugiej strony autovacuum_vacuum_thresholdi autovacuum_vacuum_scale_factorsame ustawienia dowodzą, że sam postgres wie coś o ilości zmian w tabelach i prawdopodobnie oddaje to również w ręce DBA.

Nie jestem pewien, jakie zapytanie uruchomić, ponieważ kiedy uruchamiam VACUUM VERBOSE, widzę, że przetwarzane są nie tylko tabele, ale również indeksy na nich.

Na moim PostgreSQL (8.3) używam tej sztuczki:

1. Otrzymuję rozmiar dysku tabeli za pomocą pg_total_relation_size()- obejmuje to indeksy i rozmiar TOAST, który właśnie VACUUMprzetwarza. To daje mi pojęcie, ile bajtów VACUUMmusi przeczytać.
2. Biegnę VACUUMna stół.
3. Uważam, że pidw VACUUMprocesie (w pg_catalog.pg_stat_activity).
4. W Linuksie uruchamiam while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(gdzie 123jest pid) - pokazuje mi to bajty odczytane przez proces z dysku do tej pory.

Daje mi to ogólny pogląd na to, ile bajtów jest przetwarzanych (czytanych) co minutę przez VACUUM. Zakładam, że VACUUMnależy przeczytać całą tabelę (w tym indeksy i TOAST), których rozmiar dysku znam z kroku 1.

Zakładam, że tabela jest na tyle duża, że ​​większość jej stron musi zostać odczytana z dysku (nie ma ich w pamięci współużytkowanej Postgres), więc read_bytespole jest wystarczająco dobre, aby można je było wykorzystać jako licznik postępu.

Za każdym razem, gdy to robiłem, całkowita liczba bajtów odczytanych przez proces wynosiła nie więcej niż 5% całkowitej wielkości relacji, więc myślę, że to podejście może być dla Ciebie wystarczające.

Jest to bardzo trudne do ustalenia. Możesz dostroić automatyczne odkurzanie, aby było bardziej agresywne lub łagodniejsze. Ale gdy jest ustawiony na łagodny i pozostaje w tyle, a podstawowe obciążenie we / wy jest zbyt wysokie, może się zdarzyć, że nigdy nie osiągnie właściwego stanu próżni - wtedy proces będzie działał i działał. Co więcej, późniejsze wersje PostreSQL mają znacznie ulepszone możliwości automatycznego usuwania próżni, samo to może wystarczyć, aby przejść do jednej z nich (najlepiej 9,2 jako najnowszej).

Pasek postępu wydaje się dobrym pomysłem, ale wyobrażam sobie, że jego wdrożenie nie jest tak łatwe. Ponieważ masz ciągłe obciążenie swoich stołów, jest całkiem możliwe, że postęp postępuje wyraźnie wstecz (mam na myśli, że liczba martwych wierszy / odsetek rośnie zamiast maleć) - to jaki wniosek wyciągasz?

W naszej produkcji jeden z największych stołów miał ten log:

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

Jest to zdecydowanie najgorsze zużycie zasobów, wszystkie inne tabele zajęły mniej niż 2 s.

Aby zobaczyć te typy dzienników, wykonaj następujące czynności:

alter system set log_autovacuum_min_duration TO 5; 

(przez 5 ms), załaduj ponownie plik konfiguracyjny.

Uznałem ten post i ten post za pomocny, ale jak wspomnieli inni, obliczenie ogólnego postępu próżni może być trudne, ponieważ proces obejmuje kilka osobnych operacji.

Używam tego zapytania do monitorowania postępu skanowania tabeli próżni, co wydaje się być dużą częścią pracy:

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;

Nie obejmuje to jednak skanowania indeksów, co dzieje się później, i może trwać tak długo, jeśli nie dłużej, jeśli masz mnóstwo indeksów. Niestety nie mogę znaleźć sposobu na monitorowanie skanowania / odkurzania indeksu.