Nástroj pro profilování perf který je dodáván s linuxovým jádrem, je extrémně užitečný pro zkoumání chování v rámci celého systému a více procesů – ale umí mnohem víc než profilování CPU, pro které se často používá. Pravděpodobně jste se podívali na perf top -az nebo perf top -u postgres výstup, ale to je jen to nejmenší, co dokáže. (Pokud chcete verzi TL/DR, přejděte dolů na „Dynamické sondy uživatelského prostoru“).
Jedna z velkých výhod perf je, že to není rušivé. Nemusíte připojovat ladicí program a přerušovat provádění. Nemusíte spouštět příkazy přímo pod profilerem ve speciálním prostředí. Není třeba restartovat server, abyste odladili problematickou zátěž, a často není třeba znovu kompilovat s možnostmi ladění. To je mimořádně užitečné, když se snažíte vystopovat problémy s výkonem v živém systému, protože vám to umožňuje rychle a s minimálním dopadem testovat teorie o tom, co se může stát.
výkon není jen profiler, má také podporu pro sledování. Profilování je založeno na vzorkování stavu systému při spuštění hardwarovými nebo softwarovými čítači výkonu; poskytuje statistický výběr bodů, kde systém tráví nejvíce času. Trasování místo toho odebírá vzorky, kdykoli dojde k určité události trasování, takže je mnohem užitečnější pro méně časté, ale důležité události.
Při práci s PostgreSQL jedna z nejzajímavějších funkcí perf je schopnost sledovat procesy v uživatelském prostoru . Chcete vědět, jak často váš PostgreSQL vyměňuje segmenty WAL, jak často vyhledává cizí klíče atd.? Pro jeden PostgreSQL backend nebo přes celý cluster? výkon s tím může pomoci.
Sledovací body v uživatelském prostoru a v prostoru jádra lze kombinovat a lze je použít současně s profilováním čítače výkonu, což vám pomůže získat dobrý obrázek o systému. výkon dokáže zachytit stopy zásobníku jak z jádra, tak z uživatelského prostoru a může také provádět statistické vizualizace. Sledovací body v uživatelském prostoru jsou vytvářeny dynamickými sondami; kernel-space ty mohou být předdefinované nebo to mohou být dynamické sondy.
Jak tedy používáte některé z těchto funkcí?
Nainstalujte nástroje
Nejprve se ujistěte, že používáte aktuální perf . Tento článek byl napsán na Fedoře 19 s perf 3.11.6 na x86_64 a některé funkce jsou relativně nové.
Pokud chcete výsledky zásobníku uživatelského prostoru, budete chtít, aby byl kód, na který se díváte, vytvořen pomocí -Og -ggdb -fno-omit-frame-pointer . Pokud používáte perf vytvořený pomocí libunwind nepotřebujete ukazatele snímků; viz tento příspěvek Stack Overflow a RH Bugzilla #1025603. Nic z toho není potřeba, pokud vás zajímají pouze data na straně jádra. Pokud používáte distro balíčky, možná budete muset nainstalovat -debuginfo také balíčky.
Všechny následující testy byly spuštěny se základními balíčky PGDG PostgreSQL 9.2 z http://yum.postgresql.org/ pomocí perf přestavěn pomocí libunwind podporu podle výše uvedených pokynů.
Sledovací body jádra a sondy
výkon dokáže zachytit data z předdefinovaných sledovacích bodů jádra, z nichž některé jsou informativní při pohledu na problémy s fragmentací paměti, diskovými I/O atd. Seznam sledovacích bodů můžete získat pomocí sudo perf list . Lze specifikovat seznamy sledovacích bodů a jsou podporovány zástupné znaky. Pokud například chceme získat statistiky zápisu a vyprázdnění disku na běžící instanci PostgreSQL, můžeme spustit:
sudo perf record -g dwarf -e block:block_rq_issue,syscalls:sys_enter_fsync -u postgres sleep 10
k zachycení dat. Místo spánku můžete použít žádný příkaz a stisknout Ctrl-C, když skončíte s nahráváním, nebo můžete použít nějaký jiný příkaz, jako je psql -c ke spuštění zátěže, kterou chcete měřit.
-u postgres profiluje všechny procesy běžící jako uživatel postgres . Místo toho můžete použít -a pro profilování celého systému napříč všemi CPU. Je také možné sledovat pouze jeden backend. Spusťte psql , spusťte select pg_backend_pid() , spusťte perf s -p $the_pid , pak spusťte zátěž ve stejném psql relace.
Když pracujete s PostgreSQL, výchozí cílový proces, což je příkaz spuštěný pod kontrolou perf , není obvykle příliš užitečné, protože většinu práce dělá backend, nikoli psql . Stále je užitečné používat dílčí příkaz k řízení pracovní zátěže a načasování testu.
Jakmile zachytíte data, můžete použít přehled výkonnosti abych to prozkoumal. Existuje příliš mnoho možností, o kterých by se zde dalo diskutovat – ovládání agregace a zjednodušení výsledků, zobrazení trasování zásobníku, interaktivní kletby vs výstup textové zprávy a další.
Vezměte si tuto relaci jako příklad, kde existuje shellová relace (terminál „T2“) a postgresová relace připojená k databázi „regress“ (terminál „T1“):
T1| regress=> vyberte pg_backend_pid();T1| pg_backend_pid T1| -----------------T1| 4495T1|(1 řádek)
T2| $ sudo perf record -g dwarf -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -p 4495
T1| regress=> vytvořit tabulku x jako výběr FROM create_series(1,1000000) a;T1| regrese=>
T2| $ ^CT2| [ záznam výkonu:332krát probuzen pro zápis dat ]T2| [ záznam výkonu:Zachytil a zapsal 86,404 MB perf.data (~3775041 vzorků) ]T2|T2| $ sudo perf report -g
Můžete použít přehled výkonu 's curses gui, abyste se dostali do stopy, nebo můžete použít perf report --stdio možnost přimět jej k streamování dat na stdout. Pokud například chcete trasování zásobníku, můžete spustit:
$ zpráva sudo perf -g --stdio... bla bla ...# Ukázky:1 události 'syscalls:sys_enter_fsync'# Počet událostí (přibližně):1## Režijní příkaz Symbol sdíleného objektu# .. ....................... ............. ................................# 100,00 % postgres libc-2.17.so [.] __GI___libc_fsync | --- __GI___libc_fsync mdimmedsync heap_sync intorel_shutdown standard_ExecutorRun ExecCreateTableAs PortalRunUtility PortalRunMulti PortalSpustit PostgresMain ServerLoop PostmasterMain hlavní __libc_start_main _lahstart (nula)...což ukazuje, že pro událost syscalls:sys_enter_fsync došlo k jedné události s výše uvedeným zásobníkem, fsync vyvolaným přes ExecCreateTableAs .
(Z důvodu, že se mi zatím nepodařilo zjistit finální fsync() nezdá se, že by byl zachycen perf když psql běží přímo pod kontrolou perf . Toto není problém se statistikami výkonu , pouze záznam výkonu . To je důvod, proč přeskakuji, abych předem vybral backend pomocí pid výše.)
Dynamické sondy v uživatelském prostoru
Někdy vás více zajímá něco, co se děje v samotném PostgreSQL, než události v jádře, které PostgreSQL spouští. Novější verze perf může s tím pomoci vložením dynamických sledovacích bodů, které se spouštějí při volání v programech v uživatelském prostoru.
Řekněme, že vás zajímá sledování aktivity WAL a chcete vidět, kdy XLogFlush , XLogFileInit nebo XLogFileOpen jsou nazývány. Dynamické sledovací body pro tato volání můžete vložit pomocí perf :
sudo perf probe -x `který postgres` XLogFileInitsudo perf probe -x `který postgres` XLogFileOpensudo perf probe -x `který postgres` XLogFlushMůžete testovat pouze externí symboly (nestatické, neskryté pomocí parametrů -fvisibility), pokud jste nevytvořili -ggdb . výkon bude si stěžovat nebyly nalezeny žádné symboly pokud se pokusíte použít symbol, který neexistuje. V době psaní článku perf nepodporuje použití externích informací o ladění k vyhledání symbolů pro sondy, i když je může použít pro analýzu zásobníku. Obecně platí, že pokud je to externí v src/include můžete jej použít s perf .
Každý sledovací bod vypíše název vytvořeného sledovacího bodu a můžete použít perf probe -l přesto je všechny vypsat:
$ sudo perf probe -l probe_postgres:XLogFileInit (na 0x000000000009a360) probe_postgres:XLogFileOpen (na 0x000000000009a860) probe_postgres:XLogFlush (0000)0060000000Tyto sondy jsou nyní použitelné jako události výkonu. Podívejme se na aktivitu xlog během ukázkové pracovní zátěže, monitorování napříč celým clusterem, zatímco já spouštím pgbench:
sudo perf record -g dwarf -u postgres -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlushVyzkoušejte to sami pomocí perf report -g . Zde je návod, jak vypadají výsledky. Můžete použít volby jako -g fractal,0 ovládat detaily. Budete moci vidět procento zásahů daného počítadla, které pocházejí z jedné nebo druhé větve zásobníku, pid a proces atd. --sort možnosti vám poskytují větší kontrolu nad agregací a seskupováním.
Ale počkejte, je toho víc
Měli byste se také podívat na statistiky výkonu a nejvyšší výkon příkazy. Mohou mít stejné seznamy událostí jako perf record , ačkoli z nějakého zvláštního důvodu je jejich podpora procesního filtru odlišná.
Zde je příklad, který spouští fiktivní zátěž a během běhu se dívá na sledovací body I/O jádra:
$ sudo perf stat -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -a -r 5 -- psql -q -U postgres craig -c "přetáhněte tabulku, pokud existuje x; vytvořte tabulku x jako výběr FROM create_series(1,1000000) a;"; Statistiky počítadla výkonu pro 'psql -U postgres craig -c drop table, pokud existuje x; vytvořit tabulku x jako vybrat FROM create_series(1,1000000) a;' (5 spuštění):0 block:block_rq_abort [100,00 %] 0 block:block_rq_requeue [100,00 %] 97 block:block_rq_complete ( +- 14,82 % ) [100,00 %] 96 block:block +-rq 0,0 %] [17 % 0,0 %] block:block_rq_issue ( +- 14,67 % ) [100,00 %] 0 block:block_rq_remap [100,00 %] 10 607 syscalls:sys_enter_write ( +- 0,17 % ) [100,00 % :8<8 sekund 8_sync1 syscalls5 sys.8 sekund. /před>Můžete vidět, že to dělá v průměru asi 100 I/O požadavků na blokové vrstvě přes 10k write()s a dělá jeden fsync(). Něco z toho je šum na pozadí systému, protože děláme veškeré profilování systému (-a ), ale protože je systém poměrně nečinný, není to mnoho a je to zprůměrováno na pět spuštění.
Podobně pomocí dynamických sond, které jsme přidali dříve, sledujte aktivitu xlog během běhu pgbench:
$ sudo perf stat -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlush -a -- /usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000spouštění vakua...end. typ transakce:TPC-B (druh) škálovací faktor:100režim dotazu:jednoduchýpočet klientů:2počet vláken:1počet transakcí na klienta:10000počet skutečně zpracovaných transakcí:20000/20000tps =715,854663 (včetně navazování spojení)0921316 tps =71316. kromě navazování připojení) Statistiky počítadla výkonu pro '/usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000':64 probe_postgres:XLogFileInit [100,00%] 0 probe_postgres:XLogFile05Open,5000bepost%4:Uplynulý čas XLogFlush 27,987364469 sekundJe toho mnohem víc, co můžete udělat, včetně zachycení stavu místních proměnných pomocí perf probe . Později napíšu několik užitečných příkladů. Mezitím si hrajte, objevujte a bavte se s novým diagnostickým nástrojem.
Aktualizace: Michael Paquier nedávno napsal související článek o sledování PostgreSQL pomocí systemtapu, který může být pro čtenáře tohoto článku zajímavý. Chcete-li použít tento přístup, musíte Pg překompilovat, ale syntaxe je hezčí a nabízí některé další výhody.