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 VACUUM
się skończy.
Widziałem, że pg_catalog.pg_stat_all_tables
ma kolumnę z liczbą martwych krotek. Możliwe jest więc oszacowanie, nawet jeśli oznacza to, że należy wcześniej do ANALYZE
tabeli. Z drugiej strony autovacuum_vacuum_threshold
i autovacuum_vacuum_scale_factor
same 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.
źródło
VACUUM FULL
w wersji 9.0+, ponieważ całkowicie przepisuje tabelę. Powinien też działać normalnieVACUUM
, ale jeszcze go nie przetestowałem. Naautovacuum
to działa, jeśli byli w stanie złapać proces roboczy autovacuum na danym stole, ale nie wiem, jak to osiągnąć.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?
źródło
VACUUM ANALYZE VERBOSE
przynajmniej drukuje jakąś aktywność na konsoli, jak to robi. Lepiej jest patrzeć na statyczne podpowiedzi, zastanawiając się, czy coś nie utknęło przez wiele godzin.VACUUM
auto próżni, ale nadal jest czymś.W naszej produkcji jeden z największych stołów miał ten log:
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:
(przez 5 ms), załaduj ponownie plik konfiguracyjny.
źródło
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:
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.
źródło