Kontrolní body mohou být hlavní brzdou v instalacích PostgreSQL náročných na zápis. Prvním krokem k identifikaci problémů v této oblasti je sledovat, jak často k nim dochází, což bylo nedávno do databáze přidáno snazší uživatelské rozhraní.
Kontrolní body jsou operace periodické údržby, které databáze provádí, aby se ujistil, že vše, co byla uložena do mezipaměti, bylo synchronizováno s diskem. Myšlenka je taková, že jakmile jeden dokončíte, můžete se eliminovat nutností starat se o starší záznamy umístěné do protokolu pro zápis napřed v databázi. To znamená méně času na zotavení po havárii.
Problém s kontrolními body je v tom, že mohou být velmi intenzivní, protože jejich dokončení vyžaduje zapsání každého jednotlivého bitu změněných dat ve vyrovnávací paměti databáze na disk. Do PostgreSQL 8.3 byla přidána řada funkcí, které vám umožňují lépe sledovat režii kontrolního bodu a snížit ji rozložením aktivity na delší časové období. Napsal jsem dlouhý článek o těchto změnách nazvaný Kontrolní body a Zapisovatel na pozadí, který popisuje, co se změnilo, ale je to dost suché čtení.
To, co pravděpodobně chcete vědět, je, jak monitorovat kontrolní body ve vašem produkčním systému a jak to zjistit pokud se dějí příliš často. I když se věci zlepšily, "nárůsty kontrolních bodů", kdy se diskový I/O stává opravdu těžkým, jsou stále možné i v současných verzích PostgreSQL. A nepomáhá ani to, že výchozí konfigurace je vyladěna pro velmi málo místa na disku a rychlé zotavení po havárii, nikoli výkon. Parametr checkpoint_segments, který je jedním ze vstupů, jak často ke kontrolnímu bodu dochází, je ve výchozím nastavení 3, což vynutí kontrolní bod po pouhých 48 MB zápisů.
Frekvenci kontrolních bodů můžete zjistit dvěma způsoby. Můžete zapnout log_checkpoints a sledovat, co se děje v protokolech. Můžete také použít pohled pg_stat_bgwriter, který udává počet každého ze dvou zdrojů pro kontrolní body (ubíhající čas a vyskytující se zápisy) a také statistiky o tom, kolik práce vykonali.
Hlavní problém, jak to usnadnit donedávna nebylo možné resetovat čítače uvnitř pg_stat_bgwriter. To znamená, že musíte pořídit snímek s časovým razítkem, chvíli počkat, pořídit další snímek a poté odečíst všechny hodnoty, abyste z dat odvodili užitečné statistiky. To je bolest.
Dost bolesti, že jsem napsal patch, aby to bylo jednodušší. S aktuální vývojovou verzí databáze můžete nyní zavolat pg_stat_reset_shared(‘bgwriter’) a vrátit všechny tyto hodnoty zpět na 0. To umožňuje následovat praxi, která byla na PostgreSQL běžná. Před verzí 8.3 existoval parametr s názvem stats_reset_on_server_start, který jste mohli zapnout. To resetuje všechny interní statistiky serveru pokaždé, když jej spustíte. To znamenalo, že jste mohli zavolat praktickou funkci pg_postmaster_start_time(), porovnávat s aktuálním časem a vždy mít přesný počet operací/sekundu jakékoli statistiky dostupné v systému.
Stále to není automatické, ale nyní že resetování těchto sdílených kusů je možné, můžete to udělat sami. Prvním klíčem je integrace mazání statistik do spouštěcí sekvence vašeho serveru. Skript jako tento bude fungovat:
pg_ctl start -l $PGLOG -w
psql -c "select pg_stat_reset();"
psql -c "select pg_stat_reset_shared('bgwriter');"
Všimněte si "-w" na příkazu start tam – to způsobí, že pg_ctl bude čekat, dokud se server nedokončí, než se vrátí, což je důležité, pokud proti němu chcete okamžitě provést příkaz.
Pokud jste to udělali že a čas spuštění vašeho serveru je v podstatě stejný, jako když shromažďování statistik zapisovače na pozadí zahájilo, můžete nyní použít tento zábavný dotaz:
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;
A získejte jednoduchou zprávu o tom, jak často se ve vašem systému přesně vyskytují kontrolní body. Výstup vypadá takto:
total_checkpoints | 9
minutes_between_checkpoints | 3.82999310740741
Co s těmito informacemi uděláte, je zírat na průměrný časový interval a zjistit, zda se nezdá příliš rychlý. Normálně byste chtěli, aby ke kontrolnímu bodu nedocházelo častěji než každých pět minut, a na vytíženém systému ho možná budete muset posunout na deset minut nebo více, abyste měli naději, že udržíte krok. V tomto příkladu je každých 3,8 minuty pravděpodobně příliš rychlé – toto je systém, který potřebuje, aby byly checkpoint_segments vyšší.
Použití této techniky k měření intervalu kontrolního bodu vám dá vědět, zda potřebujete zvýšit parametry checkpoint_segments a checkpoint_timeout v pořadí dosáhnout toho cíle. Čísla můžete spočítat ručně hned teď, a jakmile bude 9.0 odeslána, můžete zvážit, zda to udělat zcela automaticky – pokud vám nebude vadit, že vaše statistiky zmizí pokaždé, když se server restartuje.
Existují některé další zajímavé způsoby analyzovat data, která vám autor poskytuje v pg_stat_bgwriter, ale dnes neprozradím všechny své triky.