Sběr histogramu dotazů
Pokud používáte PostgreSQL a potřebujete sledovat výkonnostní anomálie, znáte asi konfigurační volbu log_min_duration a možná i auto_explain modul, které vám umožňují nějakým způsobem reagovat na výskyt dotazů pomalejších než stanovený limit. To je samozřejmě výborná věc, ale má to jeden drobný háček - jak stanovit vhodnou hranici, zejména pokud je doba běhu jednotlivých dotazů velmi různorodá?
Pokud hranici stanovíte příliš nízko, získáte obří logy s velkým množstvím dotazů. Naopak pokud ji stanovíte příliš vysoko, nebudete mít možnost zaznamenat změny u rychlejších dotazů. Co když máte hranici nastavenu na 200ms ale změna se uděje pod touto hranicí, tj. co když dotazy které původně trvaly 50ms náhle trvají 150ms? Doba zpracování se efektivně ztrojnásobila ale nic se nezaloguje ...
Žádný zázračný návod jak nastavit hranici logování nemám, existuje ale komplexní pohled na všechny spuštěné dotazy - histogram. Napsal jsem extension query_histogram (pgxn), která vám umožní histogram generovat a přistupovat k němu pomocí SQL.
Instalace a použití je podrobněji popsáno v README, ale tak alespoň stručně - pokud používáte 9.1, můžete použít extensions. Přidejte "query_histogram" do shared preload libraries, a pak
$ make install $ psql dbname -c "CREATE EXTENSION query_histogram"
a tím je histogram připraven k použití v dynamickém módu - to znamená že ho za běhu můžete modifikovat (počet a šířka buněk apod.).
SET query_histogram.bin_count = 100; SET query_histogram.bin_width = 50;
Kdykoliv se samozřejmě můžete podívat na aktuální data (podrobněji viz. README)
SELECT * FROM query_histogram;
případně histogram resetovat
SELECT * FROM query_histogram_reset();
a tak dále. Aktuální verze je kompatibilní pouze s 9.1, předpokládám že verzi kompatibilní s 9.0 uvolním příští týden.
Overhead histogramu
Důležitou otázkou samozřejmě je o kolik histogram snižuje výkon databáze - zkusil jsem provést read-only pgbench s různými nastaveními histogramu (dynamic vs. static a různou úrovní samplování), a srovnat je s čistou instalací bez extensions a také s extension pg_stat_statements (která dělá něco podobného a je součástí oficiální distribuce).
Celá databáze se pohodlně vešla do paměti (I/O tedy není omezujícím faktorem) a test probíhal na 4-jádrovém systému (Core i5-2500) s různým počtem klientů. Je zřejmé bez ohledu na konfiguraci si histogram nevede špatně - dopad je mezi 3-5% a vždy je výrazně nižší než v případě pg_stat_statements (tam se dopad pohybuje kolem 8%).
Je ale nutno říci že toto je dopad v extrémním případě kdy databáze není nijak omezována I/O a efekt zamykání (struktur ve sdílené paměti) se tak může maximálně projevit. V typickém reálném provozu hraje I/O výrazně větší roli a dopad na výkon tak bude výrazně nižší.
Současně je ale pravda že na strojích s větším počtem procesorů může zamykání hrát větší roli, to ale nemohu otestovat protože k takovému stroji aktuálně nemám přístup. Při návrhu histogramu jsem se snažil umožnit konfiguraci která by nutnost zamykání minimalizovala - konkrétně se jedná o statický histogram s malým procentem samplovaných dotazů.
Budoucnost
Aktuální histogram je globální, tj. per cluster. Mám v plánu umožnit vytváření "per database" histogramů, byť jen pro vybrané databáze.
Zaujala vás tato extension? Pokud ano, prosím o otestování a komentáře, návrhy na změny, hlášení případných chyb a podobně.
