Jednym z bardziej użytecznych fragmentów
dokumentacji PostgreSQL, nad którymi kiedykolwiek pracowałem, jest Tuning Your PostgreSQL
Serwer. Kiedy powstało to latem 2008 roku, kilka miesięcy po
wydaniu PostgreSQL 8.3, trudno było znaleźć podobny przewodnik,
który byłby zarówno (stosunkowo) zwięzły, jak i aktualny. Od tego czasu ja i
wielu innych współtwórców PostgreSQL pomogliśmy aktualizować ten dokument
w miarę wprowadzania zmian w PostgreSQL.
Ciekawym i pomocnym trendem
w tym okresie jest to, że parametry wciąż znikają z zestawu
z tych, o które musisz się martwić. W PostgreSQL 8.2 istniała długa
lista parametrów, które prawdopodobnie trzeba było dostosować w celu uzyskania dobrej wydajności
na serwerze PostgreSQL:shared_buffers, Effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers i (jeśli używasz
partycjonowania) bound_exclusion.
8.3 sprawił, że automatyczne odkurzanie było domyślnie
włączone z rozsądnym zachowaniem, wraz z usunięciem kilku
parametry zapisu w tle, które powodowały tylko kłopoty (nigdy
nie znalazły się na liście). Wersja 8.4 usunęła potrzebę stosowania dwóch
max_fsm_* parametrów, zwiększyła default_statistics_target do znacznie
lepszej wartości początkowej i uczyniła ustawienie ograniczenia_wykluczenia
niepotrzebnym w najczęstszych przypadkach. To o sześć parametrów mniej,
które prawdopodobnie będziesz musiał dostosować.
Niestety tylko wersja 9.0 uczyniła
konfigurację serwera bardziej skomplikowaną. A nowsze jądra Linuksa nawet
wycofały domyślne zachowanie. Począwszy od jądra Linux
2.6.33, domyślna wartość wybrana dla wal_sync_method została zmieniona na
open_datasync. Okazuje się, że ma to fatalne skutki
wydajności PostgreSQL, szczególnie w połączeniu z niskim
domyślnym ustawieniem wal_buffers na serwerze.
Ale marsz w kierunku lepszych domyślnych
zachowań został niedawno wznowiony w związku z tym, co ostatecznie planuje się
PostgreSQL 9.1. Podczas ostatniego CommitFest, Marti powstała łata
Raudsepp, która naprawiła problem wal_sync_method,
po ciężkich argumentach na temat formy, jaką ta zmiana powinna przybrać.
Odkrycie, że ta zmiana zachowania całkowicie zepsuła PostgreSQL
uruchomienie na ext4 z opcją „data=journal” pomogło
domyślnie ustalić właściwą rzecz do zrobienia.
Dwa parametry, których nie polecam
dotykania w większości przypadków to commit_siblings i commit_delay,
artefakty starszej próby poprawy wydajności w systemach z
wolnymi czasami zatwierdzania (co obejmuje większość systemów, które nie mają
bateryjnej pamięci podręcznej zapisu w celu przyspieszenia tego obszaru). Obecnie
wyłączenie parametru synchronous_commit wprowadzonego w wersji 8.3 jest
dużo bardziej pomocne. Chociaż jest mało prawdopodobne, by poprawiły
wydajność, ludzie, którzy próbują je ustawić, ucierpieli bardziej niż
niezbędnie z powodu wad tej decyzji. Najgorsze
zachowanie w tym przypadku zostało znacznie ulepszone w łacie, którą napisałem, aby zoptymalizować logikę wykonywania tych parametrów.
W tym tygodniu najnowszym parametrem
do skutecznego wyeliminowania w większości przypadków jest wal_buffers. Sugerowana przeze mnie
zmiana polegała na automatycznym ustawieniu tego jako procentu rozmiaru (około 3%)
przydzielonego do zwykle znacznie większych parametrów shared_buffers.
To ustawia wartość wal_buffers na normalny górny limit jego
efektywnego zakresu, 16 MB, gdy przydzielisz co najmniej 512 MB do
shared_buffers. A jeśli w ogóle zwiększyłeś shared_buffers z jego małych
domyślnych wartości, uzyskasz odpowiednią poprawę w tym
ważnym parametrze wydajności zatwierdzania. Będziesz musiał zrobić wszystko,
aby przerwać ustawienie tego parametru, aby trafić w złe
sytuacje możliwe we wcześniejszych wersjach.
Mając domyślną ilość konfiguracji, którą
musisz wykonać na serwerze, jest zawsze mniej skomplikowana
warte zachodu, a obserwowanie, jak parametry znikają z listy krytycznej, jest
mile widzianą zmianą. Co dalej? Podstawowe problemy związane z przydzielaniem
pamięci współdzielonej w systemach operacyjnych wywodzących się z systemu UNIX, zwłaszcza w Linuksie,
sprawiają, że bardzo trudno jest wyeliminować shared_buffers. A obawy
o przejęcie systemu przez serwer całkowicie ograniczają możliwość
automatycznego ustawiania parametrów takich jak work_mem we właściwym zakresie.
Niektóre propozycje lepszego zarządzania pulą pamięci roboczej zostały
sugerowane, aby można było zauważyć pewną poprawę.
Następny parametr, na który mam oko, to
segmenty_punktu kontrolnego. Po dodaniu tylko dodatkowego logowania w tym obszarze w
ostatnim CommitFest, jest kilka ulepszeń w tym obszarze, które zbliżają się
do zatwierdzenia teraz, aby faktycznie poprawić zachowanie punktów kontrolnych. Mam nadzieję
w końcu przełączyć dostrajanie punktów kontrolnych na ściśle kontrolowaną
za pomocą parametrów zorientowanych na czas, zamiast wymagać od użytkowników
zrozumienia mechaniki działania dziennika zapisu z wyprzedzeniem w celu dostrojenia
br />system. Wciąż jest tu zbyt wiele brzydkich sytuacji, aby zrobić to
na czas dla wersji 9.1, ale ustawienie automatycznej liczby segmentów jest
wykonalne do kierowania dla wersji 9.2.
