Które zapytania zapisać w logu (log_min_duration_statement)

PostgreSQL

Które zapytania zapisać w logu (log_min_duration_statement)

W skrócie

Log wolnych zapytań to podstawa diagnostyki wydajności w PostgreSQL, ale włączony bez głowy potrafi zaszkodzić bardziej niż pomóc. Kluczem jest jeden parametr: log_min_duration_statement. Ustawia on próg czasu, powyżej którego zapytanie trafia do logu wraz ze swoim czasem trwania. Dzięki temu zamiast przekopywać się przez miliony wpisów, dostajemy krótką listę zapytań, które naprawdę trwają za długo. Pokazujemy, jak dobrać próg i uniknąć typowych błędów.

Jak to wygląda w praktyce

Są dwa skrajne scenariusze, oba złe. W pierwszym log jest pusty, bo nikt nie włączył logowania - gdy pojawia się problem z wydajnością, nie mamy żadnych danych i musimy czekać, aż powtórzy się na żywo. W drugim ktoś włączył log_statement = 'all', więc baza zapisuje każde zapytanie, plik logu rośnie o gigabajty dziennie, a samo logowanie dodatkowo obciąża serwer i spowalnia go jeszcze bardziej. Objawem tego drugiego błędu jest paradoks: włączyliśmy logowanie, żeby zdiagnozować spowolnienie, a ono to spowolnienie pogłębiło. Właściwe ustawienie omija oba te problemy, bo zapisuje tylko to, co przekracza rozsądny próg.

Dlaczego tak się dzieje

PostgreSQL ma kilka parametrów sterujących logowaniem i łatwo je pomylić. log_statement decyduje, które kategorie poleceń logować niezależnie od czasu - wartość all zapisuje dosłownie wszystko, stąd zalanie dysku. log_min_duration_statement działa zupełnie inaczej: to próg w milisekundach, po którego przekroczeniu zapytanie trafia do logu razem ze zmierzonym czasem. Ustawiony na wartość dodatnią loguje tylko zapytania wolniejsze od progu; ustawiony na zero loguje wszystkie z czasem, a na minus jeden wyłącza tę funkcję. Różnica jest zasadnicza: przy sensownym progu narzut jest znikomy, bo baza zapisuje garstkę wpisów, a nie każde wywołanie. Dodatkowo warto pamiętać, że logowanie zawsze kosztuje trochę zapisów, więc próg nie powinien być absurdalnie niski.

Jak to rozwiązać krok po kroku

1. Zacznij od bezpiecznego, wysokiego progu, aby złapać tylko wyraźne wolne zapytania: ALTER SYSTEM SET log_min_duration_statement = '1000'; zapisze wszystko, co trwa ponad sekundę.
2. Przeładuj konfigurację bez restartu: SELECT pg_reload_conf();. Ten parametr nie wymaga zatrzymywania serwera.
3. Upewnij się, że log jest czytelny. Ustaw sensowny prefiks wpisów, na przykład z czasem, użytkownikiem i bazą: ALTER SYSTEM SET log_line_prefix = '%m [%p] %u@%d ';, i przeładuj.
4. Obserwuj log przez kilka dni i obniżaj próg stopniowo - do 500, potem do 200 milisekund - dopóki liczba wpisów pozostaje możliwa do przejrzenia. Nie schodź od razu do zera na produkcji.
5. Nie mieszaj z log_statement = 'all'. Do polowania na wolne zapytania służy wyłącznie próg czasowy; kategorie zostaw na domyślnym ustawieniu, chyba że potrzebujesz osobno logować DDL.
6. Do głębszej analizy najcięższych zapytań w skali całego serwera połącz log z rozszerzeniem pg_stat_statements - log pokazuje pojedyncze przypadki, a rozszerzenie sumy.

Jak sprawdzić, że zadziałało

Sprawdź bieżącą wartość parametru: SHOW log_min_duration_statement;. Następnie celowo uruchom wolne zapytanie, na przykład SELECT pg_sleep(2);, i zajrzyj do pliku logu - powinien pojawić się wpis z tekstem zapytania i zmierzonym czasem ponad progiem. Równocześnie szybkie zapytania nie powinny zostawiać żadnego śladu, co potwierdza, że próg działa i log nie jest zalewany. Zdrowy obraz to log, w którym dziennie przybywa od kilkunastu do kilkudziesięciu wpisów o realnie wolnych zapytaniach, a nie miliony linii ze wszystkiego.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5