{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Z\u00e1klady monitorov\u00e1n\u00ed PostgreSQL. Alexej Lesovsk\u00fd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Doporu\u010duji se sezn\u00e1mit s transkripc\u00ed prezentace Alexeje Lesovsk\u00e9ho z Data Egret \"Z\u00e1klady monitorov\u00e1n\u00ed PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

V t\u00e9to prezentaci se Alexej Lesovsk\u00fd pod\u011bl\u00ed o kl\u00ed\u010dov\u00e9 momenty statistiky PostgreSQL, co znamenaj\u00ed a pro\u010d by m\u011bly b\u00fdt sou\u010d\u00e1st\u00ed monitorov\u00e1n\u00ed; o typech graf\u016f, kter\u00e9 by m\u011bly b\u00fdt v monitorov\u00e1n\u00ed, jak je p\u0159idat a jak je interpretovat. Prezentace bude u\u017eite\u010dn\u00e1 pro spr\u00e1vce datab\u00e1z\u00ed, syst\u00e9mov\u00e9 administr\u00e1tory a v\u00fdvoj\u00e1\u0159e, kte\u0159\u00ed se zaj\u00edmaj\u00ed o troubleshootov\u00e1n\u00ed PostgreSQL.<\/p>\n

\n

\r\n \"P\u0159ehr\u00e1t\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Jmenuji se Alexej Lesovsk\u00fd a zastupuji spole\u010dnost Data Egret. <\/p>\n

<\/p>\n

N\u011bco m\u00e1lo o sob\u011b. Za\u010d\u00ednal jsem kdysi d\u00e1vno jako syst\u00e9mov\u00fd administr\u00e1tor. <\/p>\n

<\/p>\n

Administrativn\u011b jsem se v\u011bnoval r\u016fzn\u00fdm distribuc\u00edm Linuxu, pracoval jsem na r\u016fzn\u00fdch v\u011bcech spojen\u00fdch s Linuxem, tedy virtualizac\u00ed, monitorov\u00e1n\u00edm, pracoval jsem s proxy atd. Ale v ur\u010dit\u00e9m okam\u017eiku jsem se za\u010dal v\u00edce soust\u0159edit na datab\u00e1ze, konkr\u00e9tn\u011b na PostgreSQL. Velmi se mi l\u00edbil, a postupn\u011b jsem za\u010dal v\u011bnovat v\u011bt\u0161inu sv\u00e9ho pracovn\u00edho \u010dasu PostgreSQL. Tak jsem se postupn\u011b stal DBA PostgreSQL.<\/p>\n

<\/p>\n

A po celou svou kari\u00e9ru m\u011b v\u017edy zaj\u00edmala t\u00e9mata statistiky, monitorov\u00e1n\u00ed a sb\u011bru telemetrie. Kdy\u017e jsem byl syst\u00e9mov\u00fdm administr\u00e1torem, intenzivn\u011b jsem se zab\u00fdval Zabbixem a napsal jsem mal\u00fd soubor skript\u016f jako zabbix-extensions<\/a><\/noindex>. Ten byl v t\u00e9 dob\u011b docela popul\u00e1rn\u00ed. Umo\u017e\u0148oval monitorovat r\u016fzn\u00e9 d\u016fle\u017eit\u00e9 v\u011bci, nejen Linux, ale i dal\u0161\u00ed komponenty.<\/p>\n

<\/p>\n

V sou\u010dasnosti se ji\u017e v\u011bnuji PostgreSQL. P\u00ed\u0161u n\u011bco jin\u00e9ho, co umo\u017e\u0148uje pracovat se statistikou PostgreSQL. Naz\u00fdv\u00e1 se pgCenter<\/a><\/noindex> (\u010dl\u00e1nek na Habru \u2014 PostgreSQL statistika bez nerv\u016f a stresu<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Kr\u00e1tk\u00fd \u00favod. Jak\u00e9 situace se objevuj\u00ed u na\u0161ich z\u00e1kazn\u00edk\u016f? Doch\u00e1z\u00ed k n\u011bjak\u00e9 hav\u00e1rii souvisej\u00edc\u00ed s datab\u00e1z\u00ed. A kdy\u017e je datab\u00e1ze obnovena, p\u0159ijde vedouc\u00ed odd\u011blen\u00ed nebo vedouc\u00ed v\u00fdvoje a \u0159\u00edk\u00e1: \u201eP\u0159\u00e1tel\u00e9, m\u011bli bychom monitorovat datab\u00e1zi, proto\u017ee se stalo n\u011bco \u0161patn\u00e9ho a je pot\u0159eba, aby se to v budoucnu neopakovalo\u201c. A zde za\u010d\u00edn\u00e1 zaj\u00edmav\u00fd proces v\u00fdb\u011bru monitorovac\u00edho syst\u00e9mu nebo p\u0159izp\u016fsoben\u00ed st\u00e1vaj\u00edc\u00edho monitorovac\u00edho syst\u00e9mu tak, aby bylo mo\u017en\u00e9 monitorovat svou datab\u00e1zi \u2013 PostgreSQL, MySQL nebo jin\u00e9. A kolegov\u00e9 za\u010d\u00ednaj\u00ed navrhovat: \u201eSly\u0161el jsem, \u017ee existuje takov\u00e1 datab\u00e1ze. Poj\u010fme ji pou\u017e\u00edt\u201c. Kolegov\u00e9 spolu za\u010dnou spory. A nakonec se zjist\u00ed, \u017ee vyb\u00edr\u00e1me n\u011bjakou datab\u00e1zi, ale monitoring PostgreSQL v n\u00ed je zastoupen pom\u011brn\u011b slab\u011b a v\u017edy je t\u0159eba n\u011bco dod\u011bl\u00e1vat. Br\u00e1t n\u011bjak\u00e9 repozit\u00e1\u0159e z GitHubu, klonovat je, p\u0159izp\u016fsobovat skripty, n\u011bjak je doladit. A nakonec to vy\u00fast\u00ed v ur\u010ditou ru\u010dn\u00ed pr\u00e1ci. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Proto se v t\u00e9to zpr\u00e1v\u011b pokus\u00edm poskytnout v\u00e1m ur\u010dit\u00e9 znalosti o tom, jak vyb\u00edrat monitoring nejen pro PostgreSQL, ale tak\u00e9 pro datab\u00e1ze obecn\u011b. A poskytnout znalosti, kter\u00e9 v\u00e1m umo\u017en\u00ed dot\u00e1hnout v\u00e1\u0161 monitoring tak, abyste z n\u011bj m\u011bli n\u011bjak\u00fd u\u017eitek, mohli monitorovat svou datab\u00e1zi efektivn\u011b, aby bylo mo\u017en\u00e9 v\u010das varovat p\u0159ed jak\u00fdmikoliv nadch\u00e1zej\u00edc\u00edmi havarijn\u00edmi situacemi, kter\u00e9 by mohly vzniknout. <\/p>\n

<\/p>\n

A tyto my\u0161lenky, kter\u00e9 budou v t\u00e9to zpr\u00e1v\u011b, lze p\u0159\u00edmo p\u0159izp\u016fsobit jak\u00e9koli datab\u00e1zi, a\u0165 u\u017e jde o RDBMS nebo noSQL. Proto zde nen\u00ed pouze PostgreSQL, ale bude zde mnoho recept\u016f, jak to ud\u011blat v PostgreSQL. Budou zde p\u0159\u00edklady dotaz\u016f, p\u0159\u00edklady entit, kter\u00e9 existuj\u00ed v PostgreSQL pro monitoring. A pokud va\u0161e RDBMS m\u00e1 podobn\u00e9 v\u011bci, kter\u00e9 umo\u017e\u0148uj\u00ed je vlo\u017eit do monitoringu, m\u016f\u017eete je tak\u00e9 p\u0159izp\u016fsobit, p\u0159idat a bude to dobr\u00e9.<\/p>\n

<\/p>\n

\"Z\u00e1kladyV t\u00e9to zpr\u00e1v\u011b nebudu
\nvypr\u00e1v\u011bt o tom, jak dod\u00e1vat a uchov\u00e1vat metriky. Nebudu \u0159\u00edkat nic o post-processingu dat a jejich poskytov\u00e1n\u00ed u\u017eivatel\u016fm. A nebudu nic \u0159\u00edkat o alertingu.
\nV pr\u016fb\u011bhu vypr\u00e1v\u011bn\u00ed budu ukazovat r\u016fzn\u00e9 screenshoty existuj\u00edc\u00edch monitorovac\u00edch n\u00e1stroj\u016f a ob\u010das je kritizovat. Nicm\u00e9n\u011b se pokus\u00edm nezmi\u0148ovat zna\u010dky, abych nevytv\u00e1\u0159el reklamu nebo proti-reklamu t\u011bmto produkt\u016fm. Tak\u017ee ve\u0161ker\u00e1 shoda je n\u00e1hodn\u00e1 a z\u016fst\u00e1v\u00e1 na va\u0161\u00ed fantazii.
\n\"Z\u00e1klady
\nNejprve si objasn\u00edme, co monitorov\u00e1n\u00ed vlastn\u011b je. Monitorov\u00e1n\u00ed je velmi d\u016fle\u017eit\u00e1 v\u011bc, kterou je t\u0159eba m\u00edt. To ch\u00e1pe ka\u017ed\u00fd. Nicm\u00e9n\u011b monitorov\u00e1n\u00ed nepat\u0159\u00ed mezi business produkty a p\u0159\u00edmo nem\u00e1 vliv na zisk spole\u010dnosti, proto se mu v\u017edy v\u011bnuje \u010das a\u017e na posledn\u00edm m\u00edst\u011b. Pokud m\u00e1me \u010das, zab\u00fdv\u00e1me se monitorov\u00e1n\u00edm, pokud ne, tak OK, d\u00e1me to na backlog a n\u011bkdy se k t\u011bmto \u00fakol\u016fm vr\u00e1t\u00edme. <\/p>\n

<\/p>\n

Proto z na\u0161\u00ed praxe, kdy\u017e p\u0159ich\u00e1z\u00edme k klient\u016fm, je monitorov\u00e1n\u00ed \u010dasto nedostate\u010dn\u011b vyvinuto a postr\u00e1d\u00e1 zaj\u00edmav\u00e9 prvky, kter\u00e9 by n\u00e1m pomohly l\u00e9pe pracovat s datab\u00e1zemi. A proto je monitorov\u00e1n\u00ed v\u017edy t\u0159eba dokon\u010dit. <\/p>\n

<\/p>\n

Datab\u00e1ze jsou slo\u017eit\u00e9 v\u011bci, kter\u00e9 je tak\u00e9 t\u0159eba monitorovat, proto\u017ee datab\u00e1ze jsou \u00falo\u017ei\u0161t\u011bm informac\u00ed. A informace jsou pro firmu velmi d\u016fle\u017eit\u00e9, nesm\u00ed se ztr\u00e1cet. Nicm\u00e9n\u011b datab\u00e1ze jsou tak\u00e9 velmi slo\u017eit\u00e9 kusy softwaru. Skl\u00e1daj\u00ed se z mnoha komponent\u016f. A mnoh\u00e9 z t\u011bchto komponent\u016f je t\u0159eba monitorovat. <\/p>\n

<\/p>\n

\"Z\u00e1kladyPokud mluv\u00edme konkr\u00e9tn\u011b o PostgreSQL, m\u016f\u017eeme jej p\u0159edstavit jako sch\u00e9ma, kter\u00e9 se skl\u00e1d\u00e1 z mnoha komponent\u016f. Tyto komponenty si vz\u00e1jemn\u011b interaguj\u00ed. A z\u00e1rove\u0148 v PostgreSQL existuje takzvan\u00fd syst\u00e9m Stats Collector, kter\u00fd umo\u017e\u0148uje shroma\u017e\u010fovat statistiky o pr\u00e1ci t\u011bchto subsyst\u00e9m\u016f a poskytovat jak\u00fdsi rozhran\u00ed administr\u00e1torovi nebo u\u017eivateli, aby mohl tyto statistiky proch\u00e1zet. <\/p>\n

<\/p>\n

Tyto statistiky jsou prezentov\u00e1ny jako ur\u010dit\u00e1 sada funkc\u00ed a pohled\u016f (views). M\u016f\u017eeme je tak\u00e9 nazvat tabulkami. Tedy pomoc\u00ed b\u011b\u017en\u00e9ho klienta psql se m\u016f\u017eete p\u0159ipojit k datab\u00e1zi, prov\u00e9st select na t\u011bchto funkc\u00edch a pohledech a z\u00edskat konkr\u00e9tn\u00ed \u010d\u00edsla o \u010dinnosti subsyst\u00e9m\u016f PostgreSQL. <\/p>\n

<\/p>\n

M\u016f\u017eete tato \u010d\u00edsla p\u0159idat do va\u0161eho obl\u00edben\u00e9ho monitorovac\u00edho syst\u00e9mu, vytvo\u0159it grafy, p\u0159idat funkce a z\u00edskat analytiku v dlouhodob\u00e9 perspektiv\u011b. <\/p>\n

<\/p>\n

Ale v t\u00e9to zpr\u00e1v\u011b nebudu zva\u017eovat v\u0161echny tyto funkce, proto\u017ee by to mohlo zabrat cel\u00fd den. Zam\u011b\u0159\u00edm se na doslova dv\u011b a\u017e \u010dty\u0159i v\u011bci a budu \u0159\u00edkat, jak pom\u00e1haj\u00ed zlep\u0161it monitoring.
\n\"Z\u00e1klady
\nA pokud mluv\u00edme o monitoringu datab\u00e1ze, co je t\u0159eba sledovat? V prvn\u00ed \u0159ad\u011b je t\u0159eba sledovat dostupnost, proto\u017ee datab\u00e1ze je slu\u017eba, kter\u00e1 poskytuje p\u0159\u00edstup k dat\u016fm klient\u016fm, a mus\u00edme sledovat jej\u00ed dostupnost a tak\u00e9 n\u011bkter\u00e9 kvalitativn\u00ed a kvantitativn\u00ed charakteristiky. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Tak\u00e9 je t\u0159eba monitorovat klienty, kte\u0159\u00ed se p\u0159ipojuj\u00ed k na\u0161\u00ed datab\u00e1zi, proto\u017ee mohou b\u00fdt jako norm\u00e1ln\u00ed klienti, tak i \u0161kodliv\u00ed klienti, kte\u0159\u00ed mohou datab\u00e1zi po\u0161kodit. Je tak\u00e9 nutn\u00e9 je monitorovat a sledovat jejich \u010dinnost.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Kdy\u017e se klienti p\u0159ipoj\u00ed k datab\u00e1zi, je z\u0159ejm\u00e9, \u017ee za\u010d\u00ednaj\u00ed pracovat s na\u0161imi daty, proto mus\u00edme sledovat tak\u00e9 to, jak klienti pracuj\u00ed s daty: s jak\u00fdmi tabulkami, a v men\u0161\u00ed m\u00ed\u0159e s jak\u00fdmi indexy. Tedy mus\u00edme posoudit z\u00e1t\u011b\u017e (workload), kterou na\u0161i klienti vytv\u00e1\u0159ej\u00ed.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

N\u00e1klady na z\u00e1t\u011b\u017e se samoz\u0159ejm\u011b skl\u00e1daj\u00ed tak\u00e9 z dotaz\u016f. Aplikace se p\u0159ipojuj\u00ed k datab\u00e1zi a z\u00edsk\u00e1vaj\u00ed data prost\u0159ednictv\u00edm dotaz\u016f, a proto je d\u016fle\u017eit\u00e9 hodnotit, jak\u00e9 dotazy m\u00e1me v datab\u00e1zi, sledovat jejich adekv\u00e1tnost, \u017ee nejsou naps\u00e1ny chybn\u011b, \u017ee n\u011bkter\u00e9 mo\u017enosti je pot\u0159eba p\u0159epsat a zajistit, aby pracovaly rychleji a s lep\u0161\u00edmi v\u00fdkony. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A kdy\u017e mluv\u00edme o datab\u00e1zi, datab\u00e1ze v\u017edy zahrnuje procesy na pozad\u00ed. Procesy na pozad\u00ed umo\u017e\u0148uj\u00ed udr\u017eovat v\u00fdkonnost datab\u00e1ze na dobr\u00e9 \u00farovni, tak\u017ee pro jejich pr\u00e1ci vy\u017eaduj\u00ed ur\u010dit\u00e9 mno\u017estv\u00ed zdroj\u016f. A z\u00e1rove\u0148 se mohou p\u0159ekr\u00fdvat se zdroji klientsk\u00fdch dotaz\u016f, tak\u017ee n\u00e1ro\u010dn\u00e1 pr\u00e1ce proces\u016f na pozad\u00ed m\u016f\u017ee p\u0159\u00edmo ovlivnit v\u00fdkonnost klientsk\u00fdch dotaz\u016f. Proto je tak\u00e9 t\u0159eba je monitorovat a sledovat, aby nedoch\u00e1zelo k \u017e\u00e1dn\u00fdm nerovnostem v oblasti proces\u016f na pozad\u00ed. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A to v\u0161e ohledn\u011b monitorov\u00e1n\u00ed datab\u00e1ze z\u016fst\u00e1v\u00e1 v syst\u00e9mov\u00e9 metrice. Ale s ohledem na to, \u017ee v\u011bt\u0161ina na\u0161\u00ed infrastruktury se p\u0159esouv\u00e1 do cloudu, syst\u00e9mov\u00e9 metriky jednotliv\u00e9ho hostitele v\u017edy ustupuj\u00ed do pozad\u00ed. V datab\u00e1z\u00edch jsou v\u0161ak st\u00e1le aktu\u00e1ln\u00ed a sledov\u00e1n\u00ed syst\u00e9mov\u00fdch metrik samoz\u0159ejm\u011b tak\u00e9 nen\u00ed zbyte\u010dn\u00e9. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Se syst\u00e9mov\u00fdmi metrikami je to v\u00edce m\u00e9n\u011b v po\u0159\u00e1dku, v\u0161echny modern\u00ed monitorovac\u00ed syst\u00e9my ji\u017e tyto metriky podporuj\u00ed, ale celkov\u011b n\u011bkter\u00e9 komponenty st\u00e1le chyb\u00ed a je pot\u0159eba p\u0159id\u00e1vat n\u011bkter\u00e9 v\u011bci. O t\u011bchto pozn\u00e1mk\u00e1ch se tak\u00e9 zm\u00edn\u00edm, n\u011bkolik slid\u016f bude o nich. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nPrvn\u00ed bod pl\u00e1nu \u2013 dostupnost. Co je to dostupnost? Dostupnost v m\u00e9m ch\u00e1p\u00e1n\u00ed je schopnost datab\u00e1ze obsluhovat p\u0159ipojen\u00ed, tj. datab\u00e1ze je spu\u0161t\u011bn\u00e1 a jako slu\u017eba p\u0159ij\u00edm\u00e1 p\u0159ipojen\u00ed od klient\u016f. A tuto dostupnost lze hodnotit n\u011bkter\u00fdmi charakteristikami. Tyto charakteristiky je velmi pohodln\u00e9 um\u00edstit na dashboardy. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nV\u0161ichni v\u011bd\u00ed, co je to dashboard. Je to, kdy\u017e se jedn\u00edm pohledem pod\u00edv\u00e1te na obrazovku, na kter\u00e9 jsou soust\u0159ed\u011bny pot\u0159ebn\u00e9 informace. A vy u\u017e m\u016f\u017eete okam\u017eit\u011b ur\u010dit \u2013 je v datab\u00e1zi probl\u00e9m, nebo nen\u00ed.
\nOdpov\u00eddaj\u00edc\u00edm zp\u016fsobem je dostupnost datab\u00e1ze a dal\u0161\u00ed kl\u00ed\u010dov\u00e9 charakteristiky v\u017edy nutn\u00e9 um\u00edstit na dashboardy, aby tyto informace byly po ruce, byly v\u017edy bl\u00edzko v\u00e1s. N\u011bjak\u00e9 dodate\u010dn\u00e9 detaily, kter\u00e9 ji\u017e pom\u00e1haj\u00ed p\u0159i vy\u0161et\u0159ov\u00e1n\u00ed incident\u016f, p\u0159i anal\u00fdze n\u011bjak\u00fdch havarijn\u00edch situac\u00ed, je pot\u0159eba um\u00edstit na sekund\u00e1rn\u00ed dashboardy, nebo skr\u00fdt do drilldown odkaz\u016f, kter\u00e9 vedou k extern\u00edm monitorovac\u00edm syst\u00e9m\u016fm. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

P\u0159\u00edklad jednoho zn\u00e1m\u00e9ho monitorovac\u00edho syst\u00e9mu. Je to velmi skv\u011bl\u00fd monitorovac\u00ed syst\u00e9m. Shroma\u017e\u010fuje velk\u00e9 mno\u017estv\u00ed dat, ale z m\u00e9ho pohledu m\u00e1 divn\u00e9 pojet\u00ed dashboard\u016f. Je tam odkaz \u201evytvo\u0159it dashboard\u201c. Ale kdy\u017e vytvo\u0159\u00edte dashboard, vytvo\u0159\u00edte jak\u00fdsi seznam skl\u00e1daj\u00edc\u00ed se ze dvou sloupc\u016f, jak\u00fdsi seznam graf\u016f. A kdy\u017e pot\u0159ebujete n\u011bco zobrazit, za\u010dnete kliknout my\u0161\u00ed, listovat, hledat pot\u0159ebn\u00fd graf. A to zabere \u010das, tj. jako takov\u00e9 dashboardy neexistuj\u00ed. Jsou zde pouze seznamy graf\u016f.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Co je pot\u0159eba p\u0159idat na tyto dashboardy? M\u016f\u017eete za\u010d\u00edt s takovou charakteristikou, jako je doba odezvy. V PostgreSQL existuje pohled pg_stat_statements. Ve v\u00fdchoz\u00edm nastaven\u00ed je vypnut\u00fd, ale je to jeden z d\u016fle\u017eit\u00fdch syst\u00e9mov\u00fdch pohled\u016f, kter\u00fd je v\u017edy nutn\u00e9 zapnout a pou\u017e\u00edvat. Uchov\u00e1v\u00e1 informace o v\u0161ech prov\u00e1d\u011bn\u00fdch dotazech, kter\u00e9 byly vykon\u00e1ny v datab\u00e1zi. <\/p>\n

<\/p>\n

Na z\u00e1klad\u011b toho se m\u016f\u017eeme odrazit od souhrnn\u00e9ho \u010dasu proveden\u00ed v\u0161ech dotaz\u016f a pod\u011blit jej po\u010dtem dotaz\u016f pomoc\u00ed v\u00fd\u0161e uveden\u00fdch pol\u00ed. Ale to je sp\u00ed\u0161e pr\u016fm\u011brn\u00e1 teplota v nemocnici. M\u016f\u017eeme vych\u00e1zet z jin\u00fdch pol\u00ed \u2013 minim\u00e1ln\u00ed doba proveden\u00ed dotaz\u016f, maxim\u00e1ln\u00ed a medi\u00e1nov\u00e9. A dokonce m\u016f\u017eeme vytv\u00e1\u0159et percentily, v PostgreSQL existuj\u00ed odpov\u00eddaj\u00edc\u00ed funkce pro toto. A m\u016f\u017eeme z\u00edskat \u010d\u00edsla, kter\u00e1 charakterizuj\u00ed dobu odezvy na\u0161\u00ed datab\u00e1ze podle ji\u017e proveden\u00fdch dotaz\u016f, t. j. neprov\u00e1d\u00edme fale\u0161n\u00fd dotaz 'select 1' a nesledujeme dobu odezvy, ale analyzujeme doby odpov\u011bd\u00ed na ji\u017e proveden\u00e9 dotazy a vykreslujeme bu\u010f jako jednotliv\u00e9 \u010d\u00edslo, nebo z toho vytv\u00e1\u0159\u00edme graf. <\/p>\n

<\/p>\n

Je tak\u00e9 d\u016fle\u017eit\u00e9 sledovat po\u010det chyb, kter\u00e9 syst\u00e9m v dan\u00e9m okam\u017eiku generuje. A pro to m\u016f\u017eeme pou\u017e\u00edt pohled pg_stat_database. Orientujeme se na pole xact_rollback. Toto pole ukazuje nejen po\u010det rollback\u016f, kter\u00e9 se v datab\u00e1zi uskute\u010dnily, ale tak\u00e9 zohled\u0148uje po\u010det chyb. \u0158ekn\u011bme, \u017ee tuto \u010d\u00edslo m\u016f\u017eeme zobrazit na na\u0161em dashboardu a sledovat, kolik m\u00e1me v danou chv\u00edli chyb. Pokud je chyb mnoho, je to u\u017e dobr\u00fd d\u016fvod pod\u00edvat se do log\u016f a zjistit, co to jsou za chyby a pro\u010d se vyskytuj\u00ed, a pak ji\u017e vy\u0161et\u0159ovat a \u0159e\u0161it je.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

M\u016f\u017eete p\u0159idat takovou v\u011bc, jako je Tachometr. To je po\u010det transakc\u00ed za sekundu a po\u010det dotaz\u016f za sekundu. \u0158ekn\u011bme, \u017ee m\u016f\u017eete tyto \u010d\u00edsla pou\u017e\u00edt jako aktu\u00e1ln\u00ed v\u00fdkon va\u0161\u00ed datab\u00e1ze a sledovat, zda jsou vrcholy dotaz\u016f, vrcholy transakc\u00ed, nebo naopak, je \u0431\u0430\u0437\u0430 nedostate\u010dn\u011b zat\u00ed\u017een\u00e1, proto\u017ee n\u011bjak\u00fd backend selhal. Tato \u010d\u00edslo je d\u016fle\u017eit\u00e9 v\u017edy sledovat a pamatovat si, \u017ee pro n\u00e1\u0161 projekt je takov\u00fd v\u00fdkon norm\u00e1ln\u00ed, a hodnoty nad i pod t\u00edm jsou u\u017e probl\u00e9mov\u00e9 a nejasn\u00e9, co\u017e znamen\u00e1, \u017ee je pot\u0159eba zjistit, pro\u010d takov\u00e1 \u010d\u00edsla vznikaj\u00ed.<\/p>\n

<\/p>\n

Pro hodnocen\u00ed po\u010dtu transakc\u00ed se m\u016f\u017eeme op\u011bt obr\u00e1tit na pohled pg_stat_database. M\u016f\u017eeme se\u010d\u00edst po\u010det commit\u016f a po\u010det rollback\u016f a z\u00edskat tak po\u010det transakc\u00ed za sekundu. <\/p>\n

<\/p>\n

V\u0161ichni ch\u00e1pou, \u017ee do jedn\u00e9 transakce se m\u016f\u017ee vej\u00edt n\u011bkolik dotaz\u016f? Proto se TPS a QPS trochu li\u0161\u00ed. <\/p>\n

<\/p>\n

Po\u010det dotaz\u016f za sekundu m\u016f\u017eeme z\u00edskat z pg_stat_statements a jednodu\u0161e spo\u010d\u00edtat sou\u010det v\u0161ech proveden\u00fdch dotaz\u016f. Je jasn\u00e9, \u017ee porovn\u00e1v\u00e1me aktu\u00e1ln\u00ed hodnotu s p\u0159edchoz\u00ed, ode\u010d\u00edt\u00e1me a z\u00edsk\u00e1v\u00e1me zm\u011bnu, tedy po\u010det.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

M\u016f\u017eeme p\u0159idat dal\u0161\u00ed metriky podle pot\u0159eby, kter\u00e9 tak\u00e9 pom\u00e1haj\u00ed hodnotit dostupnost na\u0161\u00ed datab\u00e1ze a sledovat, zda nedo\u0161lo k n\u011bjak\u00e9mu v\u00fdpadku. <\/p>\n

<\/p>\n

Jednou z t\u011bchto metrik je uptime. Ale uptime v PostgreSQL je trochu slo\u017eit\u00e1 v\u011bc. Vysv\u011btl\u00edm, pro\u010d. Kdy\u017e PostgreSQL spust\u00ed, za\u010dne se po\u010d\u00edtat uptime. Ale pokud v n\u011bjak\u00e9m okam\u017eiku, nap\u0159\u00edklad v noci, prob\u00edhala n\u011bjak\u00e1 \u00faloha a OOM-killer n\u00e1siln\u011b ukon\u010dil podproces PostgreSQL, pak v tomto p\u0159\u00edpad\u011b PostgreSQL ukon\u010d\u00ed p\u0159ipojen\u00ed v\u0161ech klient\u016f, resetuje oblast shardovan\u00e9 pam\u011bti a za\u010dne obnovu z posledn\u00edho kontroln\u00edho bodu. A b\u011bhem t\u00e9to obnovy z kontroln\u00edho bodu datab\u00e1ze nep\u0159ij\u00edm\u00e1 p\u0159ipojen\u00ed, tedy tuto situaci je mo\u017en\u00e9 hodnotit jako v\u00fdpadek. Ale p\u0159itom se \u010d\u00edta\u010d uptime nevynuluje, proto\u017ee po\u010d\u00edt\u00e1 \u010das od spu\u0161t\u011bn\u00ed postmastera od samotn\u00e9ho za\u010d\u00e1tku. Proto si takov\u00e9 situace m\u016f\u017eeme p\u0159ehl\u00e9dnout.<\/p>\n

<\/p>\n

Tak\u00e9 je t\u0159eba monitorovat po\u010det pracovn\u00edch proces\u016f vacuum. V\u0161ichni v\u011bd\u00ed, co je to autovacuum v PostgreSQL? To je zaj\u00edmav\u00e1 podsyst\u00e9m v PostgreSQL. O n\u011bm bylo naps\u00e1no mnoho \u010dl\u00e1nk\u016f, byla uspo\u0159\u00e1d\u00e1na spousta prezentac\u00ed. Spousta diskuz\u00ed o vacuum a o tom, jak by m\u011bl fungovat. Mnoz\u00ed ho pova\u017euj\u00ed za nevyhnuteln\u00e9 zlo. Ale je to tak. Je to jak\u00fdsi ekvivalent sb\u011bra\u010de odpadu, kter\u00fd \u010dist\u00ed zastaral\u00e9 verze \u0159\u00e1dk\u016f, kter\u00e9 nejsou pot\u0159ebn\u00e9 \u017e\u00e1dn\u00e9 z transakc\u00ed a uvol\u0148uje m\u00edsto v tabulk\u00e1ch, indexech pro nov\u00e9 \u0159\u00e1dky. <\/p>\n

<\/p>\n

Pro\u010d je t\u0159eba ho monitorovat? Proto\u017ee vacuum n\u011bkdy zp\u016fsobuje velk\u00e9 probl\u00e9my. Spot\u0159ebov\u00e1v\u00e1 velk\u00e9 mno\u017estv\u00ed zdroj\u016f a klientsk\u00e9 dotazy t\u00edm za\u010d\u00ednaj\u00ed trp\u011bt. <\/p>\n

<\/p>\n

Monitorovat by se m\u011blo p\u0159es zobrazen\u00ed pg_stat_activity, o kter\u00e9m budu hovo\u0159it v n\u00e1sleduj\u00edc\u00ed \u010d\u00e1sti. Toto zobrazen\u00ed ukazuje aktu\u00e1ln\u00ed aktivitu v datab\u00e1zi. A p\u0159es tuto aktivitu m\u016f\u017eeme sledovat po\u010det vakuov\u00e1n\u00ed, kter\u00e9 prob\u00edhaj\u00ed pr\u00e1v\u011b te\u010f. M\u016f\u017eeme sledovat vakuov\u00e1n\u00ed a vid\u011bt, \u017ee pokud p\u0159ekro\u010d\u00edme limit, je to d\u016fvod pod\u00edvat se do nastaven\u00ed PostgreSQL a n\u011bjak optimalizovat pr\u00e1ci vakuov\u00e1n\u00ed. <\/p>\n

<\/p>\n

Dal\u0161\u00ed zvl\u00e1\u0161tnost\u00ed PostgreSQL je to, \u017ee PostgreSQL velmi trp\u00ed dlouh\u00fdmi transakcemi. Zejm\u00e9na od transakc\u00ed, kter\u00e9 dlouho vis\u00ed a nic ned\u011blaj\u00ed. Tyto se naz\u00fdvaj\u00ed stat idle-in-transaction. Takov\u00e1 transakce zadr\u017euje z\u00e1mky, br\u00e1n\u00ed vakuov\u00e1n\u00ed v pr\u00e1ci. A jako d\u016fsledek \u2013 tabulky se zv\u011bt\u0161uj\u00ed, zvy\u0161uj\u00ed se na velikosti. A dotazy, kter\u00e9 pracuj\u00ed s t\u011bmito tabulkami, za\u010d\u00ednaj\u00ed fungovat pomaleji, proto\u017ee je t\u0159eba proch\u00e1zet v\u0161echny star\u00e9 verze \u0159\u00e1dk\u016f z pam\u011bti na disk a zp\u011bt.<\/strong> Proto je tak\u00e9 nutn\u00e9 monitorovat \u010das, trv\u00e1n\u00ed nejdel\u0161\u00edch transakc\u00ed a nejdel\u0161\u00edch dotaz\u016f na vakuov\u00e1n\u00ed. A pokud vid\u00edme n\u011bjak\u00e9 procesy, kter\u00e9 ji\u017e pracuj\u00ed velmi dlouho, p\u0159es 10-20-30 minut pro OLTP z\u00e1t\u011b\u017e, je t\u0159eba na n\u011b ji\u017e v\u011bnovat pozornost a ukon\u010dit je n\u00e1siln\u011b nebo optimalizovat aplikaci, aby se nevytv\u00e1\u0159ely a nevisely tak dlouho.<\/strong> Pro analytickou z\u00e1t\u011b\u017e 10-20-30 minut je to norm\u00e1ln\u00ed, n\u011bkdy b\u00fdvaj\u00ed je\u0161t\u011b del\u0161\u00ed. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nD\u00e1le m\u00e1me mo\u017enost s p\u0159ipojen\u00fdmi klienty. Kdy\u017e jsme ji\u017e vytvo\u0159ili panel, um\u00edstili na n\u011bj kl\u00ed\u010dov\u00e9 metriky dostupnosti, m\u016f\u017eeme tak\u00e9 p\u0159idat dal\u0161\u00ed informace o p\u0159ipojen\u00fdch klientech. <\/p>\n

<\/p>\n

Informace o p\u0159ipojen\u00fdch klientech jsou d\u016fle\u017eit\u00e9, proto\u017ee z pohledu PostgreSQL jsou klienti r\u016fzn\u00ed. Jsou dob\u0159\u00ed klienti, jsou \u0161patn\u00ed klienti. <\/p>\n

<\/p>\n

Jednoduch\u00fd p\u0159\u00edklad. Pod klientem rozum\u00edm aplikaci. Aplikace se p\u0159ipojila k datab\u00e1zi a okam\u017eit\u011b za\u010dala pos\u00edlat sv\u00e9 dotazy, datab\u00e1ze je zpracov\u00e1v\u00e1 a vykon\u00e1v\u00e1, v\u00fdsledky vrac\u00ed klientovi. To jsou dob\u0159\u00ed a spr\u00e1vn\u00ed klienti. <\/p>\n

<\/p>\n

Jsou situace, kdy se klient p\u0159ipojil, zadr\u017euje spojen\u00ed, ale nic ned\u011bl\u00e1. Nach\u00e1z\u00ed se ve stavu idle. <\/p>\n

<\/p>\n

Ale existuj\u00ed \u0161patn\u00ed klienti. Nap\u0159\u00edklad, ten sam\u00fd klient se p\u0159ipojil, otev\u0159el transakci, n\u011bco provedl v datab\u00e1zi a pak ode\u0161el do k\u00f3du, \u0159ekn\u011bme, aby se obr\u00e1til na extern\u00ed zdroj nebo aby provedl zpracov\u00e1n\u00ed z\u00edskan\u00fdch dat. Ale p\u0159itom nezav\u0159el transakci. A transakce vis\u00ed v datab\u00e1zi a zadr\u017euje blokaci na \u0159\u00e1dku. To je \u0161patn\u00fd stav. A pokud se n\u00e1hodou aplikace n\u011bkde uvnit\u0159 zhrout\u00ed pomoc\u00ed v\u00fdjimky (Exception), m\u016f\u017ee z\u016fstat transakce otev\u0159en\u00e1 velmi dlouhou dobu. A to p\u0159\u00edmo ovliv\u0148uje v\u00fdkon PostgreSQL. PostgreSQL bude pracovat pomaleji. Proto je d\u016fle\u017eit\u00e9 tyto klienty sledovat a v\u010das ukon\u010dit jejich \u010dinnost. A je nutn\u00e9 optimalizovat svou aplikaci, aby se takov\u00e9 situace nevyskytovaly. <\/p>\n

<\/p>\n

Dal\u0161\u00edmi \u0161patn\u00fdmi klienty jsou \u010dekaj\u00edc\u00ed klienti. Ti se st\u00e1vaj\u00ed \u0161patn\u00fdmi kv\u016fli okolnostem. Nap\u0159\u00edklad jednoduch\u00e1 vis\u00edc\u00ed transakce: m\u016f\u017ee otev\u0159\u00edt transakci, vz\u00edt blokace na ur\u010dit\u00e9 \u0159\u00e1dky, a pak n\u011bkde v k\u00f3du zkolabuje, z\u016fstane vis\u00edc\u00ed transakce. P\u0159ijde jin\u00fd klient, po\u017e\u00e1d\u00e1 o stejn\u00e9 \u00fadaje, ale naraz\u00ed na blokaci, proto\u017ee ta vis\u00edc\u00ed transakce ji\u017e zadr\u017euje blokace na n\u011bkter\u00e9 pot\u0159ebn\u00e9 \u0159\u00e1dky. A druh\u00e1 transakce bude viset v \u010dek\u00e1n\u00ed, a\u017e prvn\u00ed transakce skon\u010d\u00ed nebo ji spr\u00e1vce n\u00e1siln\u011b uzav\u0159e. T\u00edmto zp\u016fsobem se \u010dekaj\u00edc\u00ed transakce mohou hromadit a p\u0159ekro\u010dit limit p\u0159ipojen\u00ed k datab\u00e1zi. A kdy\u017e je limit p\u0159ekro\u010den, aplikace u\u017e nem\u016f\u017ee pracovat s datab\u00e1z\u00ed. To je u\u017e havarijn\u00ed situace pro projekt. Proto je t\u0159eba \u0161patn\u00e9 klienty sledovat a v\u010das na n\u011b reagovat. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad monitorov\u00e1n\u00ed. A zde ji\u017e m\u00e1me slu\u0161n\u00fd dashboard. Zde jsou informace o p\u0159ipojen\u00edch naho\u0159e. DB connection \u2013 8 kus\u016f. A to je v\u0161e. Nem\u00e1me informace o tom, kte\u0159\u00ed klienti jsou aktivn\u00ed, kte\u0159\u00ed klienti jen ne\u010dinn\u011b \u010dekaj\u00ed, nic ned\u011blaj\u00ed. Nen\u00ed zde informace o vis\u00edc\u00edch transakc\u00edch a \u010dekaj\u00edc\u00edch p\u0159ipojen\u00edch, tj. to je \u010d\u00edslo, kter\u00e9 ukazuje po\u010det p\u0159ipojen\u00ed a to je v\u0161echno. A pak h\u00e1dejte sami.
\n\"Z\u00e1klady
\nAby tuto informaci p\u0159idali do monitorov\u00e1n\u00ed, je t\u0159eba se obr\u00e1tit na syst\u00e9mov\u00fd pohled pg_stat_activity. Pokud tr\u00e1v\u00edte hodn\u011b \u010dasu v PostgreSQL, je to velmi u\u017eite\u010dn\u00fd pohled, kter\u00fd by se m\u011bl st\u00e1t va\u0161\u00edm p\u0159\u00edtelem, proto\u017ee zobrazuje aktu\u00e1ln\u00ed aktivitu v PostgreSQL, tj. co se v n\u011bm d\u011bje. Ka\u017ed\u00fd proces m\u00e1 sv\u016fj vlastn\u00ed \u0159\u00e1dek, kter\u00fd ukazuje informace o tomto procesu: z jak\u00e9ho hosta bylo p\u0159ipojen\u00ed nav\u00e1z\u00e1no, pod jak\u00fdm u\u017eivatelsk\u00fdm jm\u00e9nem, jak\u00e9 bylo jm\u00e9no pro p\u0159ipojen\u00ed, kdy byla transakce spu\u0161t\u011bna, jak\u00fd dotaz je aktu\u00e1ln\u011b vykon\u00e1v\u00e1n a jak\u00fd dotaz byl vykon\u00e1n naposledy. A samoz\u0159ejm\u011b, stav klienta m\u016f\u017eeme posuzovat na z\u00e1klad\u011b pole stat. M\u016f\u017eeme prov\u00e9st seskupen\u00ed podle tohoto pole a z\u00edskat ty stats, kter\u00e9 aktu\u00e1ln\u011b existuj\u00ed v datab\u00e1zi a po\u010det p\u0159ipojen\u00ed, kter\u00e9 maj\u00ed tento stat v datab\u00e1zi. A ji\u017e z\u00edskan\u00e1 \u010d\u00edsla m\u016f\u017eeme zaslat do na\u0161eho monitorov\u00e1n\u00ed a vykreslit podle nich grafy.
\nJe tak\u00e9 d\u016fle\u017eit\u00e9 posuzovat trv\u00e1n\u00ed transakce. Ji\u017e jsem zmi\u0148oval, \u017ee je d\u016fle\u017eit\u00e9 posuzovat trv\u00e1n\u00ed vakuov\u00fdch proces\u016f, ale transakce se posuzuj\u00ed naprosto stejn\u011b. Existuj\u00ed pole xact_start a query_start. Ta v z\u00e1sad\u011b ukazuj\u00ed \u010das startu transakce a \u010das startu dotazu. Bereme funkci now(), kter\u00e1 ukazuje aktu\u00e1ln\u00ed \u010dasovou zna\u010dku, a ode\u010d\u00edt\u00e1me timestamp transakce a dotazu. A z\u00edsk\u00e1me trv\u00e1n\u00ed transakce, trv\u00e1n\u00ed dotazu. <\/p>\n

<\/p>\n

Pokud vid\u00edme dlouh\u00e9 transakce, m\u011bli bychom je ji\u017e ukon\u010dit. Pro OLTP zat\u00ed\u017een\u00ed jsou dlouh\u00e9 transakce takov\u00e9, kter\u00e9 trvaj\u00ed v\u00edce ne\u017e 1-2-3 minuty.<\/strong>. Pro OLAP zat\u00ed\u017een\u00ed jsou dlouh\u00e9 transakce norm\u00e1ln\u00ed, ale pokud trvaj\u00ed d\u00e9le ne\u017e dv\u011b hodiny, je to tak\u00e9 zn\u00e1mka toho, \u017ee n\u011bkde nastal probl\u00e9m.<\/strong> <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nKdy\u017e se klienti p\u0159ipoj\u00ed k datab\u00e1zi, za\u010dnou pracovat s na\u0161imi daty. Obracej\u00ed se na tabulky, obracej\u00ed se na indexy, aby z\u00edskali data z tabulky. A je d\u016fle\u017eit\u00e9 posuzovat, jak klienti s t\u011bmito daty pracuj\u00ed.<\/p>\n

<\/p>\n

To assess our workload and understand which tables are the most 'active'. For example, this is useful in situations where we want to place 'hot' tables on a fast SSD storage. For instance, some archival tables that we haven't used for a long time can be moved to a 'cold' archive on SATA disks, allowing them to reside there, and access will occur as needed. <\/p>\n

<\/p>\n

It is also useful for detecting anomalies after releases and deployments. For example, when a project rolls out a new feature, like adding new functionality for database work. If we build usage graphs for the tables, we can easily spot these anomalies on those graphs, such as spikes in updates or deletions. This will be very noticeable.<\/p>\n

<\/p>\n

Anomalies in 'drifted' statistics can also be detected. What does this mean? PostgreSQL has a very strong and effective query planner, and developers devote a lot of time to its development. How does it work? To create good plans, PostgreSQL collects statistics on data distribution in tables at certain intervals. This includes the most frequent values: the number of unique values, information about NULLs in the table, and a lot of other information. <\/p>\n

<\/p>\n

Based on this statistics, the planner builds multiple query plans, selects the most optimal one, and uses this query plan to execute the query and return the data. <\/p>\n

<\/p>\n

Sometimes, the statistics can 'drift'. The quality and quantity of data in a table may change, but the statistics might not be updated. Consequently, the generated plans may turn out to be suboptimal. If our plans are suboptimal based on the gathered monitoring data, we will be able to see these anomalies. For instance, if the data quality significantly changed and the index is replaced by a sequential scan through the table, meaning that if the query only needs to return 100 rows (with a limit of 100), a full scan will be performed, which always negatively impacts performance. <\/p>\n

<\/p>\n

A m\u016f\u017eeme to vid\u011bt v monitorov\u00e1n\u00ed. M\u016f\u017eeme se pod\u00edvat na tento dotaz, prov\u00e9st pro n\u011bj explain, shrom\u00e1\u017edit statistiky a vytvo\u0159it nov\u00fd dodate\u010dn\u00fd index. A u\u017e pak reagovat na tento probl\u00e9m. Proto je to d\u016fle\u017eit\u00e9. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad monitorov\u00e1n\u00ed. Mysl\u00edm, \u017ee mnoz\u00ed z v\u00e1s ho poznali, proto\u017ee je velmi popul\u00e1rn\u00ed. Kdo ho pou\u017e\u00edv\u00e1 ve sv\u00fdch projektech? Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Ale zde je jeden \u0161patn\u00fd detail. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Existuje n\u011bkolik graf\u016f. A jako jednotka jsou uvedeny bajty, tedy m\u00e1me 5 graf\u016f. To jsou Insert data, Update data, Delete data, Fetch data a Return data. Jako jednotka m\u011b\u0159en\u00ed jsou uvedeny bajty. Ale probl\u00e9m je v tom, \u017ee statistiky v PostgreSQL vracej\u00ed data v tuplech (\u0159\u00e1dc\u00edch). A tedy tyto grafy jsou velmi dobr\u00fd zp\u016fsob, jak sn\u00ed\u017eit va\u0161i z\u00e1t\u011b\u017e n\u011bkolikr\u00e1t, a\u017e des\u00edtkykr\u00e1t, proto\u017ee tuple nen\u00ed bajt, tuple je \u0159\u00e1dek, to je mnoho bajt\u016f a m\u00e1 v\u017edy prom\u011bnlivou d\u00e9lku. Tedy spo\u010d\u00edtat z\u00e1t\u011b\u017e v bajtech pomoc\u00ed tupel\u016f je nere\u00e1ln\u00fd \u00fakol nebo velmi slo\u017eit\u00fd. Proto, kdy\u017e pou\u017e\u00edv\u00e1te dashboard nebo integrovan\u00e9 monitorov\u00e1n\u00ed, v\u017edy je d\u016fle\u017eit\u00e9 rozum\u011bt tomu, \u017ee funguje spr\u00e1vn\u011b a vrac\u00ed v\u00e1m spr\u00e1vn\u011b ohodnocen\u00e9 \u00fadaje. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Jak z\u00edskat statistiky z t\u011bchto tabulek? K tomu m\u00e1 PostgreSQL ur\u010ditou skupinu pohled\u016f. A hlavn\u00ed pohled je pg_stat_user_tables<\/a><\/noindex>. User_tables \u2013 to znamen\u00e1, \u017ee tabulky byly vytvo\u0159eny za u\u017eivatele. Na rozd\u00edl od toho existuj\u00ed syst\u00e9mov\u00e9 pohledy, kter\u00e9 pou\u017e\u00edv\u00e1 s\u00e1m PostgreSQL. A existuje souhrnn\u00e1 tabulka Alltables, kter\u00e1 zahrnuje jak syst\u00e9mov\u00e9, tak u\u017eivatelsk\u00e9. M\u016f\u017eete se odvolat na jakoukoli z nich, kter\u00e1 se v\u00e1m nejv\u00edce l\u00edb\u00ed.<\/p>\n

<\/p>\n

Podle v\u00fd\u0161e uveden\u00fdch pol\u00ed lze hodnotit po\u010det insert\u016f, update a delete. Ten p\u0159\u00edklad dashboardu, kter\u00fd jsem pou\u017eil, pr\u00e1v\u011b pou\u017e\u00edv\u00e1 tato pole pro hodnocen\u00ed charakteristik z\u00e1t\u011b\u017ee. Proto se m\u016f\u017eeme tak\u00e9 od nich odv\u00edjet. Ale je t\u0159eba m\u00edt na pam\u011bti, \u017ee to jsou tuply, nikoli bajty, tak\u017ee nem\u016f\u017eeme vz\u00edt a ud\u011blat to v bajtech.<\/p>\n

<\/p>\n

Na z\u00e1klad\u011b t\u011bchto \u00fadaj\u016f m\u016f\u017eeme vytv\u00e1\u0159et takzvan\u00e9 TopN-tabulek. Nap\u0159\u00edklad Top-5, Top-10. A m\u016f\u017eeme sledovat ty \u201ehork\u00e9\u201c tabulky, kter\u00e9 se vyu\u017e\u00edvaj\u00ed v\u00edce ne\u017e ostatn\u00ed. Nap\u0159\u00edklad 5 \u201ehork\u00fdch\u201c tabulek pro vkl\u00e1d\u00e1n\u00ed. A podle t\u011bchto TopN-tabulek hodnot\u00edme na\u0161i z\u00e1t\u011b\u017e a m\u016f\u017eeme p\u0159edpov\u011bd\u011bt v\u00fdkyvy z\u00e1t\u011b\u017ee po r\u016fzn\u00fdch releasech, aktualizac\u00edch a nasazen\u00edch. <\/p>\n

<\/p>\n

Je tak\u00e9 d\u016fle\u017eit\u00e9 posoudit velikost tabulky, proto\u017ee n\u011bkdy v\u00fdvoj\u00e1\u0159i uvedou novou funkci a na\u0161e tabulky za\u010dnou r\u016fst na sv\u00fdch velk\u00fdch rozm\u011brech, proto\u017ee se rozhodli p\u0159idat dal\u0161\u00ed objem dat, ale nep\u0159edpov\u011bd\u011bli, jak to ovlivn\u00ed velikost datab\u00e1ze. Takov\u00e9 p\u0159\u00edpady pro n\u00e1s tak\u00e9 b\u00fdvaj\u00ed p\u0159ekvapen\u00edm. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A nyn\u00ed pro v\u00e1s m\u00e1m malou ot\u00e1zku. Jak\u00e1 ot\u00e1zka v\u00e1s napadne, kdy\u017e si v\u0161imnete zat\u00ed\u017een\u00ed na serveru s datab\u00e1z\u00ed? Jak\u00e1 dal\u0161\u00ed ot\u00e1zka v\u00e1s napadne? <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Ale ve skute\u010dnosti vyvst\u00e1v\u00e1 n\u00e1sleduj\u00edc\u00ed ot\u00e1zka. Jak\u00e9 dotazy zp\u016fsobuj\u00ed zat\u00ed\u017een\u00ed? Tedy nen\u00ed zaj\u00edmav\u00e9 sledovat procesy, kter\u00e9 zp\u016fsobuj\u00ed zat\u00ed\u017een\u00ed. Je jasn\u00e9, \u017ee pokud hostitel m\u00e1 datab\u00e1zi, tak tam b\u011b\u017e\u00ed datab\u00e1ze a je jasn\u00e9, \u017ee pouze datab\u00e1ze tam bude vyu\u017e\u00edvat prost\u0159edky. Pokud otev\u0159eme Top, uvid\u00edme tam seznam proces\u016f v PostgreSQL, kter\u00e9 n\u011bco d\u011blaj\u00ed. Z Top nebude jasn\u00e9, co d\u011blaj\u00ed. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Proto je pot\u0159eba zjistit ty dotazy, kter\u00e9 zp\u016fsobuj\u00ed nejv\u011bt\u0161\u00ed z\u00e1t\u011b\u017e, proto\u017ee lad\u011bn\u00ed dotaz\u016f obvykle p\u0159in\u00e1\u0161\u00ed v\u011bt\u0161\u00ed prosp\u011bch ne\u017e lad\u011bn\u00ed konfigurace PostgreSQL nebo opera\u010dn\u00edho syst\u00e9mu, nebo dokonce lad\u011bn\u00ed hardwaru. Podle m\u00e9ho odhadu je to p\u0159ibli\u017en\u011b 80-85-90 %. A to lze ud\u011blat mnohem rychleji. Rychleji oprav\u00edte dotaz, ne\u017e uprav\u00edte konfiguraci, napl\u00e1nujete restart, zejm\u00e9na pokud nelze restartovat datab\u00e1zi, nebo p\u0159idat hardware. Snadn\u011bji se n\u011bkde p\u0159ep\u00ed\u0161e dotaz nebo p\u0159id\u00e1 index, aby se dos\u00e1hlo lep\u0161\u00edho v\u00fdsledku z tohoto dotazu. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nProto je pot\u0159eba monitorovat dotazy a jejich adekv\u00e1tnost. Vezm\u011bme si jin\u00fd p\u0159\u00edklad monitorov\u00e1n\u00ed. A zde tak\u00e9 vypad\u00e1 skv\u011bl\u00e9 monitorov\u00e1n\u00ed. Je zde informace o replikaci, informace o propustnosti, blokac\u00edch, vyu\u017eit\u00ed zdroj\u016f. V\u0161echno je skv\u011bl\u00e9, ale chyb\u00ed informace o dotazech. Nen\u00ed jasn\u00e9, jak\u00e9 dotazy jsou prov\u00e1d\u011bny v na\u0161\u00ed datab\u00e1zi, jak dlouho trvaj\u00ed, kolik t\u011bchto dotaz\u016f je. V monitorov\u00e1n\u00ed mus\u00edme v\u017edy m\u00edt tyto informace. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

A pro z\u00edsk\u00e1n\u00ed t\u011bchto informac\u00ed m\u016f\u017eeme pou\u017e\u00edt modul pg_stat_statements. Na jeho z\u00e1klad\u011b lze vytv\u00e1\u0159et nejr\u016fzn\u011bj\u0161\u00ed grafy. Nap\u0159\u00edklad m\u016f\u017eeme z\u00edsk\u00e1vat informace o nej\u010dast\u011bj\u0161\u00edch dotazech, tedy o t\u011bch, kter\u00e9 se vykon\u00e1vaj\u00ed nej\u010dast\u011bji. Ano, po deploy\u00edch je tak\u00e9 velmi u\u017eite\u010dn\u00e9 se na n\u011bj pod\u00edvat a zjistit, zda nedo\u0161lo k n\u011bjak\u00e9mu v\u00fdkyvu v dotazech. <\/p>\n

<\/p>\n

M\u016f\u017eeme monitorovat nejdel\u0161\u00ed dotazy, tedy ty, kter\u00e9 trvaj\u00ed nejd\u00e9le. Tyto dotazy zat\u011b\u017euj\u00ed procesor a spot\u0159ebov\u00e1vaj\u00ed vstup-v\u00fdstup. To m\u016f\u017eeme tak\u00e9 hodnotit pomoci pol\u00ed total_time, mean_time, blk_write_time a blk_read_time. <\/p>\n

<\/p>\n

M\u016f\u017eeme hodnotit a monitorovat nejt\u011b\u017e\u0161\u00ed dotazy z hlediska vyu\u017eit\u00ed zdroj\u016f, ty, kter\u00e9 \u010dtou z disku nebo kter\u00e9 pracuj\u00ed s pam\u011bt\u00ed, nebo naopak vytv\u00e1\u0159ej\u00ed n\u011bjak\u00e9 z\u00e1pisov\u00e9 zat\u00ed\u017een\u00ed.<\/p>\n

<\/p>\n

M\u016f\u017eeme posoudit i nej\u0161t\u011bd\u0159ej\u0161\u00ed dotazy. Jsou to ty dotazy, kter\u00e9 vracej\u00ed velk\u00e9 mno\u017estv\u00ed \u0159\u00e1dk\u016f. Nap\u0159\u00edklad by to mohl b\u00fdt n\u011bjak\u00fd dotaz, kde zapomn\u011bli nastavit limit. A on prost\u011b vrac\u00ed cel obsah tabulky nebo dotazu v po\u017eadovan\u00fdch tabulk\u00e1ch.<\/p>\n

<\/p>\n

A tak\u00e9 m\u016f\u017eeme monitorovat dotazy, kter\u00e9 pou\u017e\u00edvaj\u00ed do\u010dasn\u00e9 soubory nebo do\u010dasn\u00e9 tabulky. <\/p>\n

<\/p>\n

\"Z\u00e1klady
\nA z\u016fstaly n\u00e1m pozad\u00ed procesy. Pozad\u00ed procesy jsou p\u0159edev\u0161\u00edm kontroln\u00ed body, nebo tak\u00e9 naz\u00fdvan\u00e9 checkpointy, autovacuum a replikace. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad monitorov\u00e1n\u00ed. Na lev\u00e9 stran\u011b je karta \u00dadr\u017eba, p\u0159ejdeme na ni a douf\u00e1me, \u017ee uvid\u00edme n\u011bco u\u017eite\u010dn\u00e9ho. Ale tady je jen doba b\u011bhu vakuov\u00e1n\u00ed a shroma\u017e\u010fov\u00e1n\u00ed statistik, nic v\u00edc. To je velmi chud\u00e9 informace, proto je v\u017edy d\u016fle\u017eit\u00e9 m\u00edt informace o tom, jak funguj\u00ed pozad\u00ed procesy v na\u0161\u00ed datab\u00e1zi a zda neexistuj\u00ed probl\u00e9my s jejich provozem. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Kdy\u017e se d\u00edv\u00e1me na kontroln\u00ed body, je t\u0159eba m\u00edt na pam\u011bti, \u017ee kontroln\u00ed body uvol\u0148uj\u00ed \"\u0161pinav\u00e9\" str\u00e1nky z oblasti sd\u00edlen\u00e9 pam\u011bti na disk, pot\u00e9 vytv\u00e1\u0159ej\u00ed kontroln\u00ed bod. A tento kontroln\u00ed bod lze d\u00e1le pou\u017e\u00edt jako ur\u010dit\u00e9 m\u00edsto p\u0159i obnov\u011b, pokud by PostgreSQL bylo neo\u010dek\u00e1van\u011b ukon\u010deno. <\/p>\n

<\/p>\n

Aby se v\u0161echny \"\u0161pinav\u00e9\" str\u00e1nky zapsaly na disk, je nutn\u00e9 prov\u00e9st ur\u010dit\u00e9 mno\u017estv\u00ed z\u00e1pisu. A jak je obvykl\u00e9, na syst\u00e9mech s velk\u00fdm objemem pam\u011bti to znamen\u00e1 velmi mnoho. Pokud se checkpointy vytv\u00e1\u0159ej\u00ed velmi \u010dasto v kr\u00e1tk\u00e9m intervalu, diskov\u00e1 v\u00fdkonost bude v\u00fdrazn\u011b klesat. Klientsk\u00e9 po\u017eadavky budou trp\u011bt nedostatkem zdroj\u016f. Budou se p\u0159etahovat o zdroje a bude jim chyb\u011bt v\u00fdkon. <\/p>\n

<\/p>\n

Pomoc\u00ed pg_stat_bgwriter podle uveden\u00fdch pol\u00ed m\u016f\u017eeme sledovat po\u010det vznikaj\u00edc\u00edch checkpoint\u016f. A pokud za n\u011bjakou dobu (10-15-20 minut, p\u016fl hodiny) dojde k velk\u00e9mu po\u010dtu checkpoint\u016f, nap\u0159\u00edklad 3-4-5, m\u016f\u017ee to ji\u017e p\u0159edstavovat probl\u00e9m. A je pot\u0159eba se pod\u00edvat do datab\u00e1ze, zkontrolovat konfiguraci, co zp\u016fsobuje takov\u00e9 mno\u017estv\u00ed checkpoint\u016f. Mo\u017en\u00e1 prob\u00edh\u00e1 n\u011bjak\u00fd velk\u00fd z\u00e1pis. Na z\u00e1klad\u011b workloadu m\u016f\u017eeme ji\u017e posoudit, proto\u017ee grafy workloadu m\u00e1me ji\u017e p\u0159idan\u00e9. M\u016f\u017eeme upravit parametry checkpoint\u016f tak, aby p\u0159\u00edli\u0161 neovliv\u0148ovaly v\u00fdkon dotaz\u016f.<\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Znovu se vrac\u00edm k autovacuum, proto\u017ee to je v\u011bc, kter\u00e1 jak jsem ji\u017e zm\u00ednil, m\u016f\u017ee snadno ovlivnit v\u00fdkon jak disk\u016f, tak dotaz\u016f, proto je v\u017edy d\u016fle\u017eit\u00e9 hodnotit po\u010det autovacuum. <\/p>\n

<\/p>\n

Po\u010det autovacuum worker\u016f v datab\u00e1zi je omezen. Ve v\u00fdchoz\u00edm nastaven\u00ed jsou t\u0159i, tak\u017ee pokud u n\u00e1s neust\u00e1le pracuj\u00ed t\u0159i workery v datab\u00e1zi, znamen\u00e1 to, \u017ee autovacuum nen\u00ed dostate\u010dn\u011b nastaveno, je t\u0159eba zv\u00fd\u0161it limity, p\u0159ehodnotit nastaven\u00ed autovacuum a zab\u00fdvat se konfigurac\u00ed.
\nJe d\u016fle\u017eit\u00e9 hodnotit, kte\u0159\u00ed workerov\u00e9 vacuumu n\u00e1m b\u011b\u017e\u00ed. Bu\u010fto je to spu\u0161t\u011bno u\u017eivatelem, DBA p\u0159i\u0161el a ru\u010dn\u011b spustil n\u011bjak\u00fd vacuum, co\u017e vytvo\u0159ilo z\u00e1t\u011b\u017e. Nebo je to po\u010det vacuum\u016f, kter\u00e9 posouvaj\u00ed \u010d\u00edta\u010d transakc\u00ed. Pro n\u011bkter\u00e9 verze PostgreSQL jsou to velmi n\u00e1ro\u010dn\u00e9 vacuums. A mohou snadno ovlivnit v\u00fdkon, proto\u017ee \u010dtou celou tabulku a proch\u00e1zej\u00ed v\u0161echny bloky v t\u00e9to tabulce. <\/p>\n

<\/p>\n

A samoz\u0159ejm\u011b trv\u00e1n\u00ed vakuov\u00fdch proces\u016f. Pokud m\u00e1me dlouh\u00e9 vakuov\u00e9 procesy, kter\u00e9 trvaj\u00ed velice dlouho, znamen\u00e1 to, \u017ee bychom se m\u011bli znovu pod\u00edvat na konfiguraci vakuov\u00e9ho procesu a mo\u017en\u00e1 p\u0159ehodnotit jeho nastaven\u00ed. M\u016f\u017ee se toti\u017e objevit situace, kdy vakuum pracuje na tabulce dlouhou dobu (3-4 hodiny), ale b\u011bhem t\u00e9to doby se v tabulce op\u011bt nashrom\u00e1\u017edil velk\u00fd objem mrtv\u00fdch \u0159\u00e1dk\u016f. A jakmile se vakuov\u00fd proces dokon\u010d\u00ed, mus\u00ed tabulku znovu vakuovat. Dost\u00e1v\u00e1me se tak do situace \u2013 nekone\u010dn\u00e9ho vakuov\u00e1n\u00ed. A v tomto p\u0159\u00edpad\u011b vakuum nezvl\u00e1d\u00e1 svou \u00falohu a tabulky za\u010d\u00ednaj\u00ed postupn\u011b nab\u00fdvat na velikosti, p\u0159i\u010dem\u017e objem u\u017eite\u010dn\u00fdch dat z\u016fst\u00e1v\u00e1 nezm\u011bn\u011bn. Proto p\u0159i dlouh\u00fdch vakuov\u00fdch procesech v\u017edy zkoum\u00e1me konfiguraci a sna\u017e\u00edme se ji optimalizovat, ale p\u0159itom tak, aby netrp\u011bla v\u00fdkonnost klientsk\u00fdch dotaz\u016f. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

V sou\u010dasnosti prakticky neexistuje instalace PostgreSQL, kter\u00e1 by nem\u011bla streamovou replikaci. Replikace je proces p\u0159enosu dat z masteru na repliku.<\/p>\n

<\/p>\n

Replikace v PostgreSQL funguje prost\u0159ednictv\u00edm protokolu transakc\u00ed. Master generuje protokol transakc\u00ed. Protokol transakc\u00ed je p\u0159en\u00e1\u0161en na repliku po s\u00ed\u0165ov\u00e9m spojen\u00ed, kde je na replice p\u0159ehr\u00e1v\u00e1n. Je to velmi jednoduch\u00e9. <\/p>\n

<\/p>\n

Pro sledov\u00e1n\u00ed zpo\u017ed\u011bn\u00ed replikace se pou\u017e\u00edv\u00e1 pohled pg_stat_replication. S n\u00edm to v\u0161ak nen\u00ed tak jednoduch\u00e9. V verzi 10 do\u0161lo k n\u011bkolika zm\u011bn\u00e1m. Za prv\u00e9, \u010d\u00e1st pol\u00ed byla p\u0159ejmenov\u00e1na. A \u010d\u00e1st pol\u00ed byla p\u0159id\u00e1na. V des\u00e1t\u00e9 verzi se objevila pole, kter\u00e1 umo\u017e\u0148uj\u00ed hodnotit zpo\u017ed\u011bn\u00ed replikace v sekund\u00e1ch. To je velmi pohodln\u00e9. P\u0159ed verz\u00ed 10 bylo mo\u017en\u00e9 hodnotit zpo\u017ed\u011bn\u00ed replikace v bajtech. Tato mo\u017enost z\u016fstala i v des\u00e1t\u00e9 verzi, to znamen\u00e1, \u017ee si m\u016f\u017eete vybrat, co v\u00e1m vyhovuje v\u00edce \u2013 hodnotit zpo\u017ed\u011bn\u00ed v bajtech nebo v sekund\u00e1ch. Mnoho lid\u00ed d\u011bl\u00e1 oboj\u00ed.<\/p>\n

<\/p>\n

Ale p\u0159esto, abychom mohli hodnotit zpo\u017ed\u011bn\u00ed replikace, mus\u00edme zn\u00e1t pozici protokolu v transakci. A tyto pozice protokolu transakc\u00ed jsou pr\u00e1v\u011b ve v\u00fdhledu pg_stat_replication. \u0158ekn\u011bme, \u017ee pomoc\u00ed funkce pg_xlog_location_diff() m\u016f\u017eeme vz\u00edt dv\u011b body v protokolu transakc\u00ed. Spo\u010d\u00edtat mezi nimi rozd\u00edl a z\u00edskat zpo\u017ed\u011bn\u00ed replikace v bajtech. Je to velmi pohodln\u00e9 a jednoduch\u00e9. <\/p>\n

<\/p>\n

V 10. verzi byla tato funkce p\u0159ejmenov\u00e1na na pg_wal_lsn_diff(). V\u0161echny funkce, pohledy a n\u00e1stroje, kde se objevovalo slovo \u201exlog\u201c, byly nahrazeny hodnotou \u201ewal\u201c. Tohle je novinka jak u pohled\u016f, tak u funkc\u00ed. <\/p>\n

<\/p>\n

Nav\u00edc v 10. verzi p\u0159ibyly \u0159\u00e1dky, kter\u00e9 konkr\u00e9tn\u011b ukazuj\u00ed zpo\u017ed\u011bn\u00ed. To jsou write lag, flush lag, replay lag. To znamen\u00e1, \u017ee tyto v\u011bci je d\u016fle\u017eit\u00e9 monitorovat. Pokud vid\u00edme, \u017ee m\u00e1me zpo\u017ed\u011bn\u00ed replikace, je nutn\u00e9 prozkoumat, pro\u010d se objevilo, odkud p\u0159i\u0161lo a odstranit probl\u00e9m. <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Se syst\u00e9mov\u00fdmi metrikami je prakticky v\u0161echno v po\u0159\u00e1dku. Kdy\u017e za\u010d\u00edn\u00e1 jak\u00e9koli monitorov\u00e1n\u00ed, za\u010d\u00edn\u00e1 se se syst\u00e9mov\u00fdmi metrikami. To je vyu\u017eit\u00ed procesor\u016f, pam\u011bti, swapu, s\u00edt\u011b a disku. Nicm\u00e9n\u011b mnoh\u00e9 parametry tam nejsou ve v\u00fdchoz\u00edm nastaven\u00ed. <\/p>\n

<\/p>\n

Pokud je s vyu\u017eit\u00edm procesoru v\u0161e v po\u0159\u00e1dku, pak jsou s vyu\u017eit\u00edm disku probl\u00e9my. Obvykle v\u00fdvoj\u00e1\u0159i monitorovac\u00edch n\u00e1stroj\u016f p\u0159id\u00e1vaj\u00ed informace o pr\u016fchodnosti. Ta m\u016f\u017ee b\u00fdt v iops nebo bajtech. Ale zapom\u00ednaj\u00ed na latenci a vyu\u017eit\u00ed diskov\u00fdch za\u0159\u00edzen\u00ed. To jsou d\u016fle\u017eit\u011bj\u0161\u00ed parametry, kter\u00e9 umo\u017e\u0148uj\u00ed posoudit, jak jsou disky zat\u00ed\u017eeny a jak zpomaluj\u00ed. Pokud m\u00e1me vysokou latenci, znamen\u00e1 to, \u017ee jsou n\u011bjak\u00e9 probl\u00e9my s disky. Pokud m\u00e1me vysok\u00e9 vyu\u017eit\u00ed, znamen\u00e1 to, \u017ee disky nezvl\u00e1daj\u00ed.<\/strong> To jsou kvalitn\u011bj\u0161\u00ed charakteristiky ne\u017e pr\u016fchodnost.<\/p>\n

<\/p>\n

I kdy\u017e tuto statistiku lze tak\u00e9 z\u00edskat z \u0444\u0430\u0439\u043b\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \/proc, jako se to d\u011bl\u00e1 pro vyu\u017eit\u00ed procesor\u016f. Pro\u010d tuto informaci nep\u0159id\u00e1vaj\u00ed do monitorovac\u00edch n\u00e1stroj\u016f, nev\u00edm. Nicm\u00e9n\u011b je d\u016fle\u017eit\u00e9 m\u00edt toto ve sv\u00e9m monitorov\u00e1n\u00ed.<\/strong> <\/p>\n

<\/p>\n

Stejn\u00e9 to je i ohledn\u011b s\u00ed\u0165ov\u00fdch rozhran\u00ed. Existuj\u00ed informace o pr\u016fchodnosti s\u00edt\u011b v paketech, v bajtech, ale st\u00e1le nen\u00ed \u017e\u00e1dn\u00e1 informace o latenci a nen\u00ed \u017e\u00e1dn\u00e1 informace o vyu\u017eit\u00ed, co\u017e je tak\u00e9 u\u017eite\u010dn\u00e1 informace.<\/strong> <\/p>\n

<\/p>\n

\"Z\u00e1klady<\/p>\n

<\/p>\n

Jak\u00e9koli monitorovac\u00ed n\u00e1stroje maj\u00ed nedostatky. A jak\u00fdkoli monitorovac\u00ed n\u00e1stroj si vezmete, v\u017edy bude v n\u011bjak\u00fdch krit\u00e9ri\u00edch nedostate\u010dn\u00fd. Nicm\u00e9n\u011b se vyv\u00edjej\u00ed, p\u0159id\u00e1vaj\u00ed se nov\u00e9 funkce, nov\u00e9 v\u011bci, proto si vyberte n\u011bco a vylep\u0161ujte to. <\/p>\n

<\/p>\n

A k tomu, abyste mohli vylep\u0161ovat, mus\u00edte m\u00edt v\u017edy p\u0159edstavu o tom, co znamen\u00e1 p\u0159ed\u00e1van\u00e1 statistika a jak s jej\u00ed pomoc\u00ed \u0159e\u0161it probl\u00e9my. <\/p>\n

<\/p>\n

A n\u011bkolik kl\u00ed\u010dov\u00fdch moment\u016f:<\/p>\n

<\/p>\n