Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
PostgreSQL
checkpoints are occurring too frequently - jak dostroić
max_wal_size zmusza serwer do ciągłego zrzucania danych na dysk.max_wal_size i wydłużenie checkpoint_timeout, tak by checkpointy były rzadsze i rozłożone w czasie.To jedno z najczęstszych ostrzeżeń w logach PostgreSQL i zarazem jedno z najłatwiejszych do usunięcia. Wyjaśnimy Ci, co checkpoint faktycznie robi, dlaczego dzieje się za często i jak go bezpiecznie rozstroić na spokojniejsze tempo.
W pliku logu serwera raz po raz widzisz wpis: "checkpoints are occurring too frequently (X seconds apart)" z podpowiedzią, by zwiększyć max_wal_size. Zwykle towarzyszy temu skokowe obciążenie dysku i chwilowe spadki wydajności zapisu - zwłaszcza podczas importów, masowych UPDATE czy nocnych wsadów. Ostrzeżenie mówi wprost: checkpointy wywoływane są częściej niż co interwał ustawiony w checkpoint_timeout, bo WAL zapełnia się szybciej, niż serwer zdąży odczekać ten czas. Efekt to więcej pełnych zapisów stron i więcej pracy dyskowej, niż byłoby to konieczne.
Checkpoint to moment, w którym PostgreSQL zapisuje na dysk wszystkie "brudne" strony z pamięci i zaznacza w WAL punkt, od którego można zacząć odtwarzanie po awarii. Wyzwalają go dwie rzeczy: upływ czasu (checkpoint_timeout, domyślnie 5 minut) oraz ilość zapisanego WAL (gdy zbliża się do max_wal_size). Jeśli baza dużo pisze, a max_wal_size jest niski, to drugi warunek zaskakuje jako pierwszy - checkpointy robią się co kilkadziesiąt sekund. To kosztowne, bo po każdym checkpoincie pierwsza modyfikacja strony trafia do WAL w całości (tzw. full page write). Częste checkpointy oznaczają więc więcej pełnych stron w WAL i większy narzut na dysk. Wydłużenie odstępów między checkpointami redukuje ten narzut.
SELECT * FROM pg_stat_checkpointer; (w starszych wersjach pg_stat_bgwriter) i zwróć uwagę na to, ile checkpointów było wyzwolonych ilością WAL, a ile czasem.SHOW max_wal_size;, SHOW checkpoint_timeout;, SHOW checkpoint_completion_target;.max_wal_size - to główna dźwignia. Dla obciążonego serwera rozsądny punkt startu to kilka GB, np. ALTER SYSTEM SET max_wal_size = '4GB';. Daj WAL-owi tyle miejsca, by checkpointy wyzwalał czas, a nie limit rozmiaru.checkpoint_timeout, np. ALTER SYSTEM SET checkpoint_timeout = '15min';. Rzadsze checkpointy to mniej pełnych stron w WAL, kosztem nieco dłuższego odtwarzania po awarii - to świadomy kompromis.ALTER SYSTEM SET checkpoint_completion_target = 0.9;. Dzięki temu zapisy brudnych stron są rozsmarowane niemal na cały interwał zamiast uderzać jednym skokiem.SELECT pg_reload_conf();. Parametry max_wal_size, checkpoint_timeout i checkpoint_completion_target działają bez restartu serwera.max_wal_size to więcej miejsca zajętego przez pliki w pg_wal oraz potencjalnie dłuższe odtwarzanie po awarii. Dobierz wartości do pojemności dysku i akceptowalnego czasu startu po awarii.Najprostszy dowód: ostrzeżenie "checkpoints are occurring too frequently" przestaje pojawiać się w logu przy typowym obciążeniu. Po zmianach obserwuj pg_stat_checkpointer - odstępy między checkpointami powinny wyraźnie się wydłużyć, a udział checkpointów wyzwalanych limitem WAL (zamiast czasem) powinien spaść niemal do zera. Warto porównać liczniki przed i po: zapisz wartości, odczekaj typowy cykl pracy i sprawdź różnicę. Jeśli mimo zwiększenia max_wal_size checkpointy nadal są za częste, to znak, że obciążenie zapisem jest naprawdę duże - wtedy dokładaj miejsca w WAL etapami i kontroluj wolną przestrzeń na dysku.
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
Komentarze (0)
Brak komentarzy...