http://postgres.cz/index.php?title=Monitoring_PostgreSQL&feed=atom&action=historyMonitoring PostgreSQL - Historie editací2024-03-29T08:29:52ZHistorie editací této stránkyMediaWiki 1.36.0http://postgres.cz/index.php?title=Monitoring_PostgreSQL&diff=579&oldid=previmported>Pavel: Založena nová stránka s textem „Autor: ''Pavel Stěhule'' Category:Články Ať už používáme jakoukoliv databázi, je nutné monitorovat jak databázi, tak databázový server. D…“2016-12-16T04:44:49Z<p>Založena nová stránka s textem „Autor: ''Pavel Stěhule'' <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: ''Pavel Stěhule''<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é <i>shared_preload_libraries</i>. Po restartu je nutné ještě extenzi zaregistrovat<br />
příkazem <code>CREATE EXTENSION pg_stat_statements</code> v těch databázích,<br />
kde chceme mít dostupnou statistiku SQL příkazů.<br />
<pre><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 />
</pre><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 />
<p>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.<br><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.<br><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 <code>ANALYZE</code> nad tabulkou.<br />
V případě tabulky s 20% změn vytvoří nový proces a v něm provede <code>VACUUM</code> 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