VACUUM i ANALIZA to dwie najważniejsze operacje związane z utrzymaniem bazy danych PostgreSQL.
Próżnia służy do odzyskiwania miejsca zajmowanego przez „martwe krotki” w stole. Martwa krotka jest tworzona, gdy rekord zostanie usunięty lub zaktualizowany (usunięcie, a następnie wstawienie). PostgreSQL nie usuwa fizycznie starego wiersza z tabeli, ale umieszcza na nim „znacznik”, aby zapytania nie zwracały tego wiersza. Po uruchomieniu procesu próżniowego przestrzeń zajmowana przez te martwe krotki jest oznaczana jako nadająca się do ponownego użycia przez inne krotki.
Operacja „analizuj” robi to, co mówi jej nazwa – analizuje zawartość tabel bazy danych i zbiera statystyki dotyczące rozkładu wartości w każdej kolumnie każdej tabeli. Silnik zapytań PostgreSQL wykorzystuje te statystyki, aby znaleźć najlepszy plan zapytań. W miarę wstawiania, usuwania i aktualizowania wierszy w bazie danych zmieniają się również statystyki kolumn. ANALIZA – uruchamiana ręcznie przez DBA lub automatycznie przez PostgreSQL po autoodkurzaniu – zapewnia aktualność statystyk.
Chociaż brzmią stosunkowo prosto, zakulisowe odkurzanie i analiza to dwa złożone procesy. Na szczęście administratorzy baz danych nie muszą się zbytnio martwić o swoje wewnętrzne elementy. Jednak często są zdezorientowani, jeśli chodzi o ręczne uruchamianie tych procesów lub ustawianie optymalnych wartości parametrów konfiguracyjnych.
W tym artykule podzielimy się kilkoma najlepszymi praktykami dotyczącymi PRÓŻNI i ANALIZY.
Wskazówka 1:Nie uruchamiaj ręcznego ODKURZACZA ani ANALIZY bez powodu
Odkurzanie PostgreSQL (automatyczne lub ręczne odkurzanie) minimalizuje rozrost tabeli i zapobiega zawijaniu identyfikatora transakcji. Autovacuum nie odzyskuje miejsca na dysku zajmowanego przez martwe krotki. Jednak uruchomienie PRÓŻNI PEŁNEJ polecenie to zrobi. VACUUM FULL ma jednak wpływ na wydajność. Tabela docelowa jest blokowana wyłącznie podczas operacji, uniemożliwiając nawet odczyty na stole. Proces tworzy również pełną kopię tabeli, co wymaga dodatkowego miejsca na dysku podczas działania. Zalecamy, aby nie uruchamiać VACUUM FULL, chyba że występuje bardzo wysoki procent rozdęcia, a zapytania nie działają prawidłowo. Zalecamy również używanie okresów najniższej aktywności bazy danych.
Najlepszą praktyką jest również nie uruchamianie zbyt często ręcznego odkurzania w całej bazie danych; docelowa baza danych może być już optymalnie odkurzona w procesie autovacuum. W rezultacie ręczna próżnia może nie usunąć martwych krotek, ale spowodować niepotrzebne obciążenia we/wy lub skoki procesora. Jeśli to konieczne, ręczne odkurzanie powinno być uruchamiane na podstawie tabeli po stole tylko wtedy, gdy jest to konieczne, na przykład niski stosunek rzędów na żywo do rzędów martwych lub duże odstępy między automatycznymi odkurzaczami. Ponadto ręczne odkurzanie należy uruchamiać, gdy aktywność użytkownika jest minimalna.
Autovacuum utrzymuje również aktualne statystyki dystrybucji danych w tabeli (nie odbudowuje ich). Po uruchomieniu ręcznym ANALIZA polecenie faktycznie odbudowuje te statystyki zamiast je aktualizować. Ponownie, odbudowanie statystyk, gdy są już optymalnie zaktualizowane przez regularne automatyczne odkurzanie, może powodować niepotrzebną presję na zasoby systemowe.
Czas, w którym trzeba uruchomić ANALIZA ręcznie, następuje natychmiast po zbiorczym załadowaniu danych do tabeli docelowej. Duża liczba (nawet kilkaset) nowych wierszy w istniejącej tabeli znacznie zniekształci rozkład danych w jej kolumnach. Nowe wiersze spowodują, że wszelkie istniejące statystyki kolumn będą nieaktualne. Gdy optymalizator zapytań korzysta z takich statystyk, wydajność zapytań może być naprawdę niska. W takich przypadkach uruchomienie polecenia ANALIZA natychmiast po załadowaniu danych w celu całkowitego odbudowania statystyk jest lepszą opcją niż czekanie na uruchomienie automatycznego odkurzania.
Wskazówka 2:Dostosuj próg automatycznej próżni
Niezbędne jest sprawdzenie lub dostrojenie automatycznego odkurzania i przeanalizowanie parametrów konfiguracyjnych w pliku postgresql.conf pliku lub w poszczególnych właściwościach tabeli, aby uzyskać równowagę między automatyczną próżnią a wzrostem wydajności.
PostgreSQL używa dwóch parametrów konfiguracyjnych, aby zdecydować, kiedy uruchomić automatyczne odkurzanie:
- autovacuum_vacuum_threshold :ma domyślną wartość 50
- autovacuum_vacuum_scale_factor :ma domyślną wartość 0,2
Razem te parametry informują PostgreSQL, aby uruchomił automatyczną próżnię, gdy liczba martwych wierszy w tabeli przekroczy liczbę wierszy w tej tabeli pomnożoną przez współczynnik skali plus próg próżni. Innymi słowy, PostgreSQL uruchomi automatyczne odkurzanie na stole, gdy:
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
W przypadku małych i średnich stołów może to wystarczyć. Na przykład w przypadku stołu z 10 000 rzędów liczba martwych rzędów musi przekraczać 2050 ((10 000 x 0,2) + 50), zanim rozpocznie się automatyczne odkurzanie.
Nie każda tabela w bazie danych podlega takim samym zmianom danych. Zwykle kilka dużych tabel będzie podlegać częstym modyfikacjom danych, w wyniku czego będzie mieć większą liczbę martwych wierszy. Wartości domyślne mogą nie działać w przypadku takich tabel. Na przykład, przy wartościach domyślnych, tabela z 1 milionem wierszy będzie musiała mieć więcej niż 200 050 martwych wierszy, zanim rozpocznie się automatyczna próżnia ((1000,000 x 0,2) + 50). Może to oznaczać dłuższe przerwy między automatycznymi próżniami, coraz dłuższe czasy automatycznego odkurzania, a co gorsza, automatyczne odkurzanie w ogóle nie działa, jeśli aktywne transakcje na stole blokują go.
Dlatego celem powinno być ustawienie tych progów na optymalne wartości, tak aby automatyczne odkurzanie mogło odbywać się w regularnych odstępach czasu i nie zabierało dużo czasu (i wpływało na sesje użytkowników), jednocześnie utrzymując stosunkowo niską liczbę martwych wierszy.
Jednym z podejść jest użycie jednego lub drugiego parametru. Tak więc, jeśli ustawimy autovacuum_vacuum_scale_factor na 0, a zamiast tego ustawimy autovacuum_vacuum_threshold na, powiedzmy, 5000, tabela zostanie automatycznie odkurzona, gdy jej liczba martwych wierszy przekroczy 5000.
Wskazówka 3:Dostrój próg automatycznej analizy
Podobnie jak w przypadku automatycznego odkurzania, funkcja autoanalizy wykorzystuje również dwa parametry, które decydują o tym, kiedy funkcja automatycznego odkurzania uruchomi również autoanalizę:
- autovacuum_analyze_threshold :ma domyślną wartość 50
- autovacuum_analyze_scale_factor :domyślna wartość to 0.1
Podobnie jak autovacuum, parametr autovacuum_analyze_threshold można ustawić na wartość, która określa liczbę wstawionych, usuniętych lub zaktualizowanych krotek w tabeli przed rozpoczęciem autoanalizy. Zalecamy ustawienie tego parametru osobno w przypadku tabel z dużymi i wysokimi transakcjami. Konfiguracja tabeli zastąpi wartości postgresql.conf.
Poniższy fragment kodu przedstawia składnię SQL służącą do modyfikowania ustawienia autovacuum_analyze_threshold dla tabeli.
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
Wskazówka 4:Dostosuj pracowników do automatycznego odkurzania
Innym parametrem często pomijanym przez administratorów baz danych jest autovacuum_max_workers , który ma domyślną wartość 3. Autovacuum nie jest pojedynczym procesem, ale kilkoma pojedynczymi wątkami próżniowymi działającymi równolegle. Powodem wybrania wielu pracowników jest upewnienie się, że odkurzanie dużych stołów nie wstrzymuje odkurzania mniejszych stołów i sesji użytkowników. Parametr autovacuum_max_workers mówi PostgreSQL, aby rozkręcił liczbę wątków roboczych autovacuum w celu wykonania czyszczenia.
Powszechną praktyką administratorów baz danych PostgreSQL jest zwiększanie maksymalnej liczby wątków roboczych w nadziei, że przyspieszy to automatyczne odkurzanie. To nie działa, ponieważ wszystkie wątki mają ten sam autovacuum_vacuum_cost_limit , który ma domyślną wartość 200. Każdemu wątkowi automatycznego odkurzania przypisywany jest limit kosztów za pomocą poniższego wzoru:
individual thread’s cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers
Koszt pracy wykonanej przez wątek autovacuum jest obliczany za pomocą trzech parametrów:
- vacuum_cost_page_hit :ma domyślną wartość 1
- vacuum_cost_page_miss :ma domyślną wartość 10
- vacuum_cost_page_dirty :ma domyślną wartość 20
Znaczenie tych parametrów jest następujące:
- Gdy wątek próżniowy znajdzie stronę danych, którą ma wyczyścić we współdzielonym buforze, koszt wynosi 1.
- Jeśli strona danych nie znajduje się we współdzielonym buforze, ale w pamięci podręcznej systemu operacyjnego, koszt wyniesie 10.
- Jeśli strona musi być oznaczona jako brudna, ponieważ wątek próżniowy musiał usunąć martwe wiersze, koszt wyniesie 20.
Zwiększona liczba wątków roboczych obniży limit kosztów dla każdego wątku. Ponieważ każdy wątek ma przypisany niższy limit kosztów, będzie częściej przechodził w stan uśpienia, ponieważ próg kosztów zostanie łatwo osiągnięty, co ostatecznie spowoduje spowolnienie całego procesu próżniowego. Zalecamy zwiększenie autovacuum_vacuum_cost_limit do wyższej wartości, np. 2000, a następnie dostosowanie maksymalnej liczby wątków roboczych.
Lepszym sposobem jest dostrojenie tych parametrów dla poszczególnych tabel tylko wtedy, gdy jest to konieczne. Na przykład, jeśli automatyczne odkurzanie dużego stołu transakcyjnego trwa zbyt długo, stół może być tymczasowo skonfigurowany do korzystania z własnego limitu kosztów próżni i opóźnień kosztów. Limit kosztów i opóźnienie zastąpią wartości ogólnosystemowe ustawione w postgresql.conf.
Poniższy fragment kodu pokazuje, jak skonfigurować poszczególne tabele.
ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_limit = <large_value>) ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_delay = <lower_cost_delay>)
Użycie pierwszego parametru zapewni, że wątek autovacuum przypisany do stołu wykona więcej pracy przed pójściem spać. Obniżenie autovacuum_vacuum_cost_delay będzie również oznaczać, że wątek śpi mniej czasu.
Ostateczne myśli
Jak widać, zmiana parametrów konfiguracyjnych dla próżni i analizy jest prosta, ale wymaga uważnej obserwacji. Każda baza danych różni się rozmiarem, wzorcem ruchu i szybkością transakcji. Zalecamy, aby administratorzy baz danych zaczęli od zebrania wystarczającej ilości informacji o swojej bazie danych przed zmianą parametrów lub wprowadzeniem ręcznego reżimu próżni/analizy. Takie informacje mogą być:
- Liczba wierszy w każdej tabeli
- Liczba martwych krotek w każdej tabeli
- Czas ostatniego podciśnienia dla każdego stołu
- Czas ostatniej analizy dla każdej tabeli
- Szybkość wstawiania/aktualizowania/usuwania danych w każdej tabeli
- Czas, jaki zajmuje automatyczne odkurzanie dla każdego stołu
- Ostrzeżenia dotyczące braku odkurzania stołów
- Aktualna wydajność najbardziej krytycznych zapytań i tabel, do których uzyskują dostęp
- Wydajność tych samych zapytań po ręcznym odkurzaniu/analizie
Stąd administratorzy baz danych mogą wybrać kilka tabel „pilotażowych”, aby rozpocząć optymalizację. Mogą rozpocząć zmianę właściwości próżni/analizy dla tabel i sprawdzić wydajność. PostgreSQL to inteligentny silnik bazy danych – administratorzy baz danych często uznają, że najlepiej jest pozwolić PostgreSQLowi na odkurzanie i analizę, zamiast robić to ręcznie.
