http://postgres.cz/index.php?action=history&feed=atom&title=Monitoring_PostgreSQL 2026-05-12T22:30:25Z Historie editací této stránky MediaWiki 1.43.3 http://postgres.cz/index.php?title=Monitoring_PostgreSQL&diff=579&oldid=prev 2016-12-16T04:44:49Z

<p>Založena nová stránka s textem „Autor: &#039;&#039;Pavel Stěhule&#039;&#039; <a href="/wiki/Kategorie:%C4%8Cl%C3%A1nky" title="Kategorie:Články">Category:Články</a> Ať už používáme jakoukoliv databázi, je nutné monitorovat jak databázi, tak databázový server. D…“</p> <p><b>Nová stránka</b></p><div>Autor: &#039;&#039;Pavel Stěhule&#039;&#039;<br /> [[Category:Články]]<br /> <br /> Ať už používáme jakoukoliv databázi, je nutné monitorovat jak databázi,<br /> tak databázový server. Dnes si ani nedovedu představit provoz nějaké náročnější<br /> aplikace bez základního monitoringu. V praxi se ale setkávám s tím, že dobře<br /> nastavený monitoring databáze a databázového serveru je spíše výjimkou,<br /> která potvrzuje pravidlo. Opět se pokusím ukázat, že se nejedná o nic<br /> komplikovaného a je velká škoda, že se vývojáři připravují o množství<br /> nedocenitelných informací, které jim monitoring může přinést.<br /> <br /> Asi každá aplikace má lepší nebo horší logování, které je možné využít i<br /> pro analýzy výkonu. Monitoring na straně klienta poskytuje pouze část obrazu.<br /> V případě výkonnostních problémů nevíme, jestli už vzniká problém v databázi<br /> (případně v zdrojích O.S. serveru) nebo až na straně klienta. Z pohledu<br /> klienta nevíme, kde na serveru narážíme na limity. <br /> <br /> U databázových aplikací je samotná databáze přirozeným úzkým hrdlem, a jakákoliv<br /> informace ohledně výkonu je jedna z mála objektivních vyčíslitelných zpětných<br /> vazeb pro vývojáře. Bohužel hodně vývojářů netuší, že tyto informace existují,<br /> a tak je vůbec nepožadují. Důvodů je několik - někdy nezkušenost, někdy<br /> organizační překážky, někdy i osobní averze mezi administrátory a vývojáři.<br /> Často je to bludná víra, že databáze si už nějak poradí, a běžný programátor<br /> nemá šanci nějak ovlivnit výkon - případně, že to už je práce databázového<br /> administrátora a nikoliv programátora. Nic není vzdálenější pravdě.<br /> <br /> Výkon aplikace je dán primárně použitou architekturou, potom návrhem interface<br /> a použitými algoritmy, dále pak vlastní implementací - skoro až na úplném konci<br /> je konfigurace databáze. Databázový administrátor může leccos pokazit, ale už toho<br /> nemůže moc zachránit. Co ale může, a měl by, je poskytování zpětné vazby vývojářům.<br /> Přeci jen má informace z první ruky - a přeci jen vývojáři by se neměli dostat<br /> blízko k produkčním serverům (z mnoha důvodů). Vím o týmech, kde to funguje.<br /> Samozřejmě, že jsem viděl i týmy, kde vývojáři obviňují adminy z neschopnosti,<br /> a admini vývojáře z pitomosti. To ale žádný výkonnostní problém nevyřeší.<br /> <br /> ==Analýza pomalých dotazů==<br /> Prvním nástrojem pro sledování databázového serveru je sledování pomalých<br /> dotazů (případně všech dotazů). Téměř v každé aplikaci se objeví dotazy, které<br /> server, z nějakého důvodu, nemůže efektivně provést. Ke všemu se často<br /> jedná o chybně napsané dotazy - kdy dostaneme nesprávný výsledek a ještě<br /> si na něj musíme dlouho počkat. S logem pomalých dotazů se vývojář může <br /> zaměřit na několik málo dotazů a ty prověřit po všech stránkách. Pokud se <br /> používají ORM systémy, tak log pomalých dotazů je často prvním místem, kde<br /> může vývojář vidět dotaz v celku, vidět dobu provádění dotazu a četnost<br /> jeho provádění. Když už nic jiného, tak by vývojáři měli používat log<br /> pomalých dotazů - je to jednostranná informace, ale už jenom s tím se dá žít.<br /> Ne každý pomalý dotaz je možné vyřešit (odstranit). Počítání reportu můžeme<br /> zrychlit do určité míry, ale nemůžeme oblafnout fyziku - ať už je to rychlost <br /> čtení dat z disků, počet IOPS disků nebo rychlost čtení z operační paměti.<br /> O každém pomalém dotazu bychom měli ovšem vědět, a měli bychom vědět, proč<br /> je pomalý.<br /> <br /> ===pg_stat_statements===<br /> V Postgresu máme pro sledování pomalých dotazů tři nástroje. Nejjednodušším<br /> na použití je extenze [https://www.postgresql.org/docs/current/static/pgstatstatements.html pg_stat_statements]. Ta se instaluje registrací v konfigurační<br /> proměnné &lt;i&gt;shared_preload_libraries&lt;/i&gt;. Po restartu je nutné ještě extenzi zaregistrovat<br /> příkazem &lt;code&gt;CREATE EXTENSION pg_stat_statements&lt;/code&gt; v těch databázích,<br /> kde chceme mít dostupnou statistiku SQL příkazů.<br /> &lt;pre&gt;<br /> bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /<br /> nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent<br /> FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;<br /> -[ RECORD 1 ]---------------------------------------------------------------------<br /> query | UPDATE pgbench_branches SET bbalance = bbalance + ? WHERE bid = ?;<br /> calls | 3000<br /> total_time | 9609.00100000002<br /> rows | 2836<br /> hit_percent | 99.9778970000200936<br /> -[ RECORD 2 ]---------------------------------------------------------------------<br /> query | UPDATE pgbench_tellers SET tbalance = tbalance + ? WHERE tid = ?;<br /> calls | 3000<br /> total_time | 8015.156<br /> rows | 2990<br /> hit_percent | 99.9731126579631345<br /> -[ RECORD 3 ]---------------------------------------------------------------------<br /> query | copy pgbench_accounts from stdin<br /> calls | 1<br /> total_time | 310.624<br /> rows | 100000<br /> hit_percent | 0.30395136778115501520<br /> -[ RECORD 4 ]---------------------------------------------------------------------<br /> query | UPDATE pgbench_accounts SET abalance = abalance + ? WHERE aid = ?;<br /> calls | 3000<br /> total_time | 271.741999999997<br /> rows | 3000<br /> hit_percent | 93.7968855088209426<br /> -[ RECORD 5 ]---------------------------------------------------------------------<br /> query | alter table pgbench_accounts add primary key (aid)<br /> calls | 1<br /> total_time | 81.42<br /> rows | 0<br /> hit_percent | 34.4947735191637631<br /> &lt;/pre&gt;<br /> ===pgFouine===<br /> Dalším, dnes už letitým nástrojem je analyzátor logu pomalých dotazů [http://pgfouine.projects.pgfoundry.org/ pgFouine] - <br /> Mně osobně se velice líbí. Generované [http://pgfouine.projects.pgfoundry.org/reports/sample_default.html reporty] jsou přehledné, názorné. Dělá<br /> to přesně to, co je potřeba. Jedná se ale o aplikaci, která dnes už není udržovaná, a nějakou modernizaci by potřebovala.<br /> Výhodou pgFouine je možnost se v reportu podívat na příklady pomalých dotazů<br /> a minimální dopad na výkon aplikace.<br /> <br /> ===pgBadger===<br /> Moderním a rozvíjený nástroj na zpracování Postgresových logů je [http://dalibo.github.io/pgbadger/ pgBadger].<br /> Umí z Postgresových logů vyčíst maximum možných informací a poskytuje relativně<br /> ucelený náhled na provoz. Pro samotnou analýzu pomalých dotazů mám ale raději<br /> jednodušší (skromnější) jednoúčelový pgFouine.<br /> <br /> Z logu pomalých dotazů nevyčteme nic o důvodech, proč jsou dotazy pomalé. Jestli<br /> v tu dobu bylo zrovna přetížené IO, nebo databáze odbavovala tisíce dotazů za <br /> vteřinu nebo naráz prováděla stovky dotazů. Pro plastičtější obraz potřebujeme <br /> nástroj pro monitoring operačního systému. Určitě některý znáte: munin, nagios, Grafana.<br /> <br /> ==Zobrazení dalších metrik==<br /> <br /> Subjektivně mi stále nejvíc vyhovuje [https://en.wikipedia.org/wiki/Munin_(software) munin]. Jeho výstupy jsou pro mne dobře čitelné, zřetelné - <br /> vyhovuje mi výchozí barevné schéma. Jedná se o poměrně letitý software s určitými<br /> muškami - z GoodData vím o výkonnostních problémech při monitoringu větších desítek<br /> serverů. Jeho visual je docela archaický - pro každodenní práci ale ocením čitelnost<br /> na první pohled. Je úplně jedno, který nástroj používáte. Důležité je mít alespoň<br /> jeden monitoring a ten aktivně používat - tj jednou za týden, jednou denně (podle<br /> důležitosti aplikace) se na něj podívat, plus samozřejmě v případě problémů.<br /> <br /> ===Zátěž IO===<br /> Výkon jakékoliv transakční databáze závisí od stavu IO. IO samozřejmě může mít vliv<br /> i na netransakční databáze. Monitorování IO je základ. Je velice praktické sledovat<br /> metriky jako je počet IO operací/sec, intenzita zápisu(čtení)/sec, utilizaci IO,<br /> případně inverzní hodnotu IO waits. Ve chvíli, kdy máte v databázovém serveru dlouhodobě<br /> velké IO waits, tak se razantně prodlužuje zpracování příkazů (z ms i na desítky<br /> vteřin).<br /> <br /> ===Využití disků===<br /> &lt;p&gt;Další extrémně zajímavou metrikou je obsazenost disků - u dnešních relativně<br /> velkých a rychlých disků se doporučuje si udržovat v lepším případě 50% volného<br /> místa, v horším případě alespoň 30%. Často je problém s výkonem spojený s nárůstem<br /> velikosti databáze - atypicky velký nárůst databáze může signalizovat útok,<br /> chyby v čištění, archivaci - v designu skriptů, které realizují upload dat.<br /> Ve větších organizacích už nemusí být přehled o všech činnostech, které se dějí<br /> na databázovém serveru - upload 100GB databáze hodně zacvičí s IO - při monitoringu<br /> uvidíme novou databázi s velkým intenzivním nárůstem. To už stačí k tomu, aby <br /> člověk věděl koho se zeptat, případně na co se zeptat.<br /> <br /> ===Spojení do databáze===<br /> Zajímavou informací jsou počty spojení - aktivní, neaktivní, čekající na zámek,<br /> s otevřenými transakcemi. To hodně říká o designu aplikace, o tom jak náročné<br /> jsou dotazy, kde jsou úzká hrdla. Pokud aplikace správně neuvolňuje spojení,<br /> neukončuje transakce, tak má neobvykle velké požadavky na počet otevřených<br /> spojení do databáze. V grafu počtu spojení je takový problém perfektně vidět.&lt;br&gt;<br /> <br /> ===Nejdelší transakce, nejdelší dotazy, počty transakcí===<br /> V SQL databázi zajímavou informací může být graf vykreslující dobu nejdelší aktivní <br /> transakce, dobu nejdelšího aktivního dotazu. Zajímavé jsou i počty transakcí.<br /> Z nich je vidět, kdy jsou špičky, jak jsou velké - je možné propojit vliv<br /> transakcí na zátěž IO. Z počtu transakcí je vidět i dostupnost aplikace. Pokud<br /> na Firewallu zaříznete velkého aktivního zákazníka, tak výrazně klesne počet<br /> transakcí. Log firewallu běžně nikdo nestuduje - o jednu IP adresu více nebo méně.<br /> Propad počtu transakcí je perfektně vidět.&lt;br&gt;<br /> <br /> ===Autovacuum===<br /> V PostgreSQL je extrémně důležité vakuování tabulek. Většinu situací řeší<br /> automat autovacuum. Tento automat iteruje nad tabulkami, a pokud najde tabulku<br /> s 10% změn, tak vytvoří nový proces a v něm spustí příkaz &lt;code&gt;ANALYZE&lt;/code&gt; nad tabulkou.<br /> V případě tabulky s 20% změn vytvoří nový proces a v něm provede &lt;code&gt;VACUUM&lt;/code&gt; tabulky.<br /> Počet procesů, které může autovacuum vytvořit je omezený. Je nutné sledovat,<br /> jestli je tento limit dostatečný - počet procesů vytvořených automatem nesmí<br /> být dlouhodobě na maximu. To by znamenalo, že Postgres nestíhá vacuovat, a docházelo<br /> by k zbytečnému nafukování tabulek.<br /> <br /> ===Ostatní===<br /> Není od věci si nechat vykreslovat běh delších operací, které mohou mít vliv<br /> na zátěž databáze - zálohování, masivní exporty a importy, výpočet fakturace,<br /> párování přijatých faktur a plateb. Pokud zjistím například vysokou utilizaci<br /> disku, pak si ji mohu jednoduše spojit např. se zálohováním (pokud mám zálohování<br /> zobrazené). Tam, kde už na produktu pracuje víc lidí, víc nezávislých týmů<br /> je to nedocenitelné.<br /> <br /> ==Závěr==<br /> Monitoring je dobré doplnit nástrojem na zpracování logů - občas je nutné<br /> provést podrobnější analýzu - a tam už obrázky nestačí. Když se umí zacházet<br /> ze [https://cs.wikipedia.org/wiki/Splunk splunkem], tak to člověk<br /> jen zírá. Dost možná, že na většinu zdejších aplikací<br /> by splunk byl tím kanónem na vrabce - postačí [https://www.elastic.co/products/logstash Logstash] a Elasticsearch. Proti<br /> klasickému procházení logů je to neskutečný komfort. Nehledě na to, že opět<br /> odstiňuje vývojáře od produkce.<br /> <br /> U trochu důležitějších aplikací je vhodné monitoring doplnit alertingem. <br /> Dochází místo disku, některá důležitá operace běží neobvykle dlouhou <br /> dobu, dochází k několika hodinovému čekání na zámek, k několika hodinovým<br /> dotazům, transakcím - to vše může vyžadovat pozornost administrátora. Je <br /> hloupé, když Vás na kritické problémy upozorňují uživatelé.<br /> <br /> Postavení základního monitoringu databázového serveru je práce na maximálně <br /> na půl dne. Fungující monitoring umožňuje vidět problémy, vidět trendy, lépe<br /> identifikovat úzká hrdla. S těmito znalostmi lze využít maximálně výkon<br /> hardware - nemusíte už pak řešit jestli Vaše aplikace letos přežije předvánoční<br /> nákupní šílenství, protože máte dostatek výkonu.</div>

imported>Pavel