En af de mere nyttige dele af
PostgreSQL-dokumentation, jeg nogensinde har arbejdet på, er Tuning Your PostgreSQL
server. Da det blev skrevet i sommeren 2008, et par måneder efter
udgivelsen af PostgreSQL 8.3, var det svært at finde nogen lignende guide, der
var både (relativt) kortfattet og aktuel. Siden da har jeg og
mange andre PostgreSQL-bidragydere hjulpet med at holde dokumentet opdateret
i takt med at der blev foretaget ændringer i PostgreSQL.
Den interessante og nyttige tendens
i den periode er, at parametre bliver ved med at forsvinde fra sættet
af dem, du skal bekymre dig om. I PostgreSQL 8.2 var der en lang
liste over parametre, du sandsynligvis havde brug for for at justere for god ydeevne
på en PostgreSQL-server:shared_buffers, effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers og (hvis du bruger
partitionering) constraint_exclusion.
8.3 har gjort autovakuum som standard til at være
aktiveret med rimelig adfærd, sammen med fjernelse af nogle få
baggrundsskriverparametre, der ikke forårsagede andet end problemer (de
kom aldrig med på listen). 8.4 fjernede behovet for de to
max_fsm_* parametre, øgede default_statistics_target til en meget
bedre startværdi og gjorde indstilling af constraint_exclusion
unødvendig i de mest almindelige tilfælde. Det er seks færre parametre
som du sandsynligvis skal justere.
Desværre gjorde version 9.0 kun
serverkonfigurationen mere kompliceret. Og nyere Linux-kerner
skubbede endda standardadfærd bagud. Startende med Linux-kernen
2.6.33 blev standardværdien valgt for wal_sync_method ændret til
open_datasync. Dette viser sig at have en frygtelig ydeevne
implikationer for PostgreSQL, især når det kombineres med den lave
standardindstilling for wal_buffere på serveren.
Men marchen mod bedre standard
adfærd er for nylig genoptaget for det, der i sidste ende planlægges at være
PostgreSQL 9.1. Under den sidste CommitFest opstod en patch Marti
Raudsepp for at løse problemet med wal_sync_method blev begået
efter nogle tunge argumenter om, hvilken form den ændring skulle have.
Opdagelsen af, at denne adfærdsændring brød PostgreSQL totalt
når du kører på ext4 med "data=journal"-indstillingen, hjalp det
afgøre det rigtige at gøre her som standard.
To parametre, jeg ikke anbefaler
at røre ved, er i de fleste tilfælde commit_siblings og commit_delay,
artefakter af et ældre forsøg på at forbedre ydeevnen på systemer med
langsomme commit-tider (hvilket omfatter de fleste systemer, der ikke har en
batteriunderstøttet skrivecache til at accelerere dette område). Nu til dags
deaktiverer det synchronous_commit-parameteren, der blev introduceret i 8.3,
meget mere sandsynligt, at det hjælper her. Selvom disse sandsynligvis ikke forbedrer
ydeevnen, har folk, der forsøger at indstille dem, lidt mere end
nødvendigt under ulemperne ved den beslutning. Den værst tænkelige
adfærd her blev forbedret betydeligt i en patch, jeg skrev for at optimere, hvordan logikken, som disse parametre kontrollerer, udføres.
Og i denne uge er den seneste parameter, der i de fleste tilfælde effektivt skal elimineres, wal_buffers. En ændring, jeg
foreslog, blev forpligtet til at indstille dette automatisk som en procentdel af størrelsen (ca. 3%)
allokeret til de normalt meget større shared_buffers-parametre.
Dette indstiller værdien af wal_buffers til normal øvre grænse for dets
effektive område, 16MB, når du er tildelt mindst 512MB til
shared_buffers. Og hvis du overhovedet har øget shared_buffers fra dens lille
standard, vil du få en tilsvarende forbedring i denne
vigtige commit-ydeevneparameter. Du bliver nødt til at gå ud af
din måde at bryde indstillingen af denne parameter for at ramme de dårlige
situationer, der er mulige i tidligere versioner.
At have den mængde konfiguration, du
skal udføre på serveren som standard, bliver mindre kompliceret, er altid
det er umagen værd, og at se parametre forsvinde fra den kritiske liste er
en velkommen ændring. Hvad er det næste? Kerneproblemerne med at allokere
delt hukommelse på UNIX-afledte operativsystemer, især Linux,
gør det meget vanskeligt at eliminere shared_buffers. Og bekymringer
om at serveren overtager systemet begrænser fuldstændigt muligheden for
til automatisk at indstille parametre som work_mem til det rigtige område.
Nogle forslag til bedre styring af arbejdshukommelsespuljen er blevet
foreslået, så man måske kan se en forbedring.
Den næste parameter, jeg har øje for, er
checkpoint_segments. Efter at have tilføjet blot ekstra logning i dette område i
den sidste CommitFest, er der nogle forbedringer på dette område, der nærmer sig
forpligtelse nu til rent faktisk at forbedre kontrolpunkternes adfærd. Jeg håber at
efterhånden skifte til tuning af checkpoint til at blive strengt kontrolleret
via tidsorienterede parametre i stedet for at kræve, at brugerne
forstår mekanikken i, hvordan fremskrivningsloggen fungerer for at tune
br />system. Der er stadig for mange grimme situationer mulige her til at gøre
det i tide til 9.1, men det er muligt at indstille segmentantal automatisk
at målrette mod 9.2.