En av de mer användbara delarna av
PostgreSQL-dokumentationen jag någonsin arbetat med är att ställa in din PostgreSQL
server. När det skrevs sommaren 2008, några månader efter
släppet av PostgreSQL 8.3, var det svårt att hitta någon liknande guide som
var både (relativt) kortfattad och aktuell. Sedan dess har jag och
många andra PostgreSQL-bidragsgivare hjälpt till att hålla dokumentet uppdaterat
eftersom ändringar i PostgreSQL gjordes.
Den intressanta och hjälpsamma trenden
under den perioden är att parametrar hela tiden försvinner från uppsättningen
av dem du behöver oroa dig för. I PostgreSQL 8.2 fanns det en lång
lista över parametrar som du sannolikt behövde för att justera för bra prestanda
på en PostgreSQL-server:shared_buffers, effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers och (om man använder
partitionering) constraint_exclusion.
8.3 gjorde autovakuum som standard till att
aktiveras med rimligt beteende, tillsammans med att ta bort några
bakgrundsskrivarparametrar som inte orsakade något annat än problem (de
dick aldrig in på listan). 8.4 tog bort behovet av de två
max_fsm_* parametrarna, ökade default_statistics_target till ett mycket
bättre startvärde och gjorde inställningen constraint_exclusion
onödig i de vanligaste fallen. Det är sex färre parametrar
som du sannolikt behöver justera.
Tyvärr gjorde version 9.0 bara
serverkonfigurationen mer komplicerad. Och nyare Linux-kärnor
förde till och med standardbeteendet bakåt. Från och med Linux-kärnan
2.6.33 ändrades standardvärdet för wal_sync_method till
open_datasync. Detta visar sig ha fruktansvärda prestanda
implikationer för PostgreSQL, särskilt i kombination med den låga
standardinställningen för wal_buffers på servern.
Men marschen mot bättre standard
beteende har nyligen återupptagits för vad som så småningom planeras att bli
PostgreSQL 9.1. Under den senaste CommitFest skapades en patch Marti
Raudsepp för att fixa wal_sync_method-problemet begicks
efter några tunga argument om vilken form den förändringen skulle ta.
Att upptäckte att denna beteendeförändring bröt PostgreSQL totalt
när man körde på ext4 med alternativet “data=journal” hjälpte det
att göra rätt här som standard.
Två parametrar som jag inte rekommenderar
berör i de flesta fall är commit_siblings och commit_delay,
artefakter av ett äldre försök att förbättra prestandan på system med
långsamma commit-tider (vilket inkluderar de flesta system som inte har en
batteristödd skrivcache för att accelerera det området). Nuförtiden
att stänga av parametern synchronous_commit som introducerades i 8.3 är
mycket mer sannolikt att det hjälper här. Även om dessa sannolikt inte förbättrar
prestandan, har människor som försöker ställa in dem lidit mer än
nödvändigt av nackdelarna med det beslutet. Det värsta
beteendet här förbättrades avsevärt i en patch jag skrev för att optimera hur logiken som dessa parametrar kontrollerar exekveras.
Och den här veckan är den senaste parametern
att effektivt elimineras i de flesta fall wal_buffers. En ändring som jag
föreslog gjordes för att ställa in detta automatiskt som en procentandel av storleken (cirka 3%)
tilldelad de normalt mycket större shared_buffers-parametrarna.
Detta ställer in värdet på wal_buffers till normal övre gräns för dess
effektiva intervall, 16MB, när du väl har tilldelats minst 512MB till
delade_buffertar. Och om du överhuvudtaget har ökat shared_buffers från dess lilla
standard, får du en motsvarande förbättring av denna
viktiga commit-prestandaparameter. Du måste gå ur
din sätt att bryta inställningen av denna parameter för att nå de dåliga
situationer som är möjliga i tidigare versioner.
Att ha den mängd konfiguration du
behöver göra för servern som standard blir mindre komplicerat är alltid
värt besväret, och att se parametrar försvinna från den kritiska listan är
en välkommen förändring. Vad kommer härnäst? Kärnproblemen med att allokera
delat minne på UNIX-härledda operativsystem, särskilt Linux,
gör det mycket svårt att eliminera shared_buffers. Och oro
om att servern tar över systemet begränsar helt och hållet möjligheten
att automatiskt ställa in parametrar som work_mem till rätt intervall.
Några förslag för att bättre hantera arbetsminnespoolen har varit
föreslagna, så att man kan se en viss förbättring.
Nästa parameter jag har koll på är
checkpoint_segments. Efter att ha lagt till bara extra loggning i det här området i
förra CommitFest, finns det några förbättringar inom detta område som närmar sig
åta nu för att faktiskt förbättra kontrollpunktsbeteendet. Jag hoppas att
så småningom byta över kontrollpunktsinställningen så att den kan kontrolleras strikt
via tidsorienterade parametrar, snarare än att kräva att användarna
förstår mekaniken i hur loggen för skriv framåt fungerar för att justera
system. Det finns fortfarande för många fula situationer här för att göra
det i tid för 9.1, men att ställa in segmenträkningen automatiskt är
möjligt att måla för 9.2.