Kontrolpunkter kan være et stort træk på skrivetunge PostgreSQL-installationer. Det første skridt mod at identificere problemer på dette område er at overvåge, hvor ofte de sker, hvilket netop er blevet tilføjet en brugervenlig grænseflade til databasen for nylig.
Kontrolpunkter er periodiske vedligeholdelsesoperationer, som databasen udfører for at sikre, at alt, hvad den har gemt i hukommelsen, er blevet synkroniseret med disken. Tanken er, at når du er færdig med en, kan du eliminere behovet for at bekymre dig om ældre poster, der er placeret i databasens fremskrivningslog. Det betyder mindre tid til at komme sig efter et nedbrud.
Problemet med checkpoints er, at de kan være meget intensive, for for at fuldføre en kræver det at skrive hver eneste bit af ændrede data i databasens buffercache ud til disk. Der blev tilføjet en række funktioner til PostgreSQL 8.3, som giver dig mulighed for bedre at overvåge checkpoint overhead, og at sænke det ved at sprede aktiviteten over en længere periode. Jeg skrev en lang artikel om disse ændringer kaldet Checkpoints and the Background Writer, der går over, hvad der ændrede sig, men det er ret tør læsning.
Det, du sikkert gerne vil vide, er, hvordan man overvåger kontrolpunkter på dit produktionssystem, og hvordan man fortæller hvis de sker for ofte. Selvom tingene er blevet bedre, er "checkpoint spikes", hvor disk I/O bliver rigtig tung, stadig mulige selv i nuværende PostgreSQL-versioner. Og det hjælper ikke, at standardkonfigurationen er indstillet til meget lav diskplads og hurtig gendannelse af nedbrud frem for ydeevne. Checkpoint_segments-parameteren, der er ét input til, hvor ofte et checkpoint sker, er som standard 3, hvilket tvinger et checkpoint efter kun 48 MB skrivninger.
Du kan finde ud af checkpoint-frekvensen på to måder. Du kan slå log_checkpoints til og se, hvad der sker i loggene. Du kan også bruge visningen pg_stat_bgwriter, som giver en optælling af hver af de to kilder for kontrolpunkter (tid, der går og skriver, der forekommer) samt statistik over, hvor meget arbejde de har udført.
Det største problem med at gøre det nemmere at gør er, at det indtil for nylig har været umuligt at nulstille tællerne inde i pg_stat_bgwriter. Det betyder, at du skal tage et øjebliksbillede med et tidsstempel på, vente et stykke tid, tage endnu et øjebliksbillede og derefter trække alle værdierne fra for at udlede enhver nyttig statistik fra dataene. Det er en smerte.
Nok smerte til, at jeg skrev et plaster for at gøre det lettere. Med den aktuelle udviklingsversion af databasen kan du nu kalde pg_stat_reset_shared('bgwriter') og sætte alle disse værdier tilbage til 0 igen. Dette gør det muligt at følge en praksis, der plejede at være almindelig på PostgreSQL. Før 8.3 var der en parameter ved navn stats_reset_on_server_start, du kunne slå til. Det nulstillede alle serverens interne statistikker, hver gang du startede den. Det betød, at du kunne kalde den praktiske pg_postmaster_start_time()-funktion, sammenligne med det aktuelle klokkeslæt og altid have en nøjagtig optælling i form af operationer/sekund af enhver statistik tilgængelig på systemet.
Det er stadig ikke automatisk, men nu at nulstilling af disse delte stykker er muligt, kan du gøre det selv. Den første nøgle er at integrere statistikrydning i din serverstartsekvens. Et script som dette vil virke:
pg_ctl start -l $PGLOG -w
psql -c "select pg_stat_reset();"
psql -c "select pg_stat_reset_shared('bgwriter');"
Bemærk "-w" på startkommandoen der – det vil få pg_ctl til at vente, indtil serveren er færdig med at starte, før den vender tilbage, hvilket er vigtigt, hvis du straks vil udføre en sætning mod den.
Hvis du har gjort det. det, og din serverstarttid er i det væsentlige den samme, som da baggrundsforfatterens statistik startede indsamlingen, kan du nu bruge denne sjove forespørgsel:
SELECT
total_checkpoints,
seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints
FROM
(SELECT
EXTRACT(EPOCH FROM (now() - pg_postmaster_start_time())) AS seconds_since_start,
(checkpoints_timed+checkpoints_req) AS total_checkpoints
FROM pg_stat_bgwriter
) AS sub;
Og få en simpel rapport om præcis, hvor ofte kontrolpunkter sker på dit system. Outputtet ser således ud:
total_checkpoints | 9
minutes_between_checkpoints | 3.82999310740741
Det du gør med denne information er at stirre på det gennemsnitlige tidsinterval og se om det virker for hurtigt. Normalt vil du gerne have, at et kontrolpunkt ikke finder sted mere end hvert femte minut, og på et travlt system skal du muligvis skubbe det til ti minutter eller mere for at have et håb om at følge med. Med dette eksempel er hvert 3.8. minut sandsynligvis for hurtigt – dette er et system, der kræver, at checkpoint_segments er højere.
Ved at bruge denne teknik til at måle checkpoint-intervallet kan du vide, om du har brug for at øge parametrene checkpoint_segments og checkpoint_timeout i rækkefølge at nå det mål. Du kan beregne tallene manuelt lige nu, og når først 9.0 er sendt, er det noget, du kan overveje at gøre helt automatisk – så længe du ikke har noget imod, at din statistik forsvinder hver gang serveren genstarter.
Der er nogle andre interessante måder at analysere de data, som baggrundsforfatteren giver dig i pg_stat_bgwriter, men jeg vil ikke give alle mine tricks væk i dag.