{"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\/ro\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Fundamentele monitoriz\u0103rii PostgreSQL. Alexei Lesovschi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

V\u0103 propun s\u0103 consulta\u021bi transcrierea prezent\u0103rii lui Alexey Lesovsky de la Data Egret \"Bazele monitoriz\u0103rii PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

\u00cen aceast\u0103 prezentare, Alexey Lesovsky va discuta despre punctele cheie ale statisticilor PostgreSQL, ce \u00eenseamn\u0103 acestea \u0219i de ce ar trebui s\u0103 fie incluse \u00een monitorizare; despre ce grafice ar trebui s\u0103 existe \u00een monitorizare, cum s\u0103 le ad\u0103uga\u021bi \u0219i cum s\u0103 le interpreta\u021bi. Prezentarea va fi util\u0103 pentru administratorii de baze de date, administratorii de sistem \u0219i dezvoltatorii care sunt interesa\u021bi de troubleshooting \u00een Postgres.<\/p>\n

\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

M\u0103 numesc Alexei Lesovschi, reprezint compania Data Egret. <\/p>\n

<\/p>\n

C\u00e2teva cuvinte despre mine. Am \u00eenceput c\u00e2ndva, demult, ca administrator de sistem. <\/p>\n

<\/p>\n

Am administrat diverse Linux, m-am ocupat de diferite lucruri legate de Linux, adic\u0103 virtualizare, monitorizare, am lucrat cu proxy-uri etc. Dar, la un moment dat, am \u00eenceput s\u0103 m\u0103 ocup mai mult de baze de date, PostgreSQL. Mi-a pl\u0103cut foarte mult. \u0218i, la un moment dat, am \u00eenceput s\u0103 dedic cea mai mare parte a timpului meu de lucru PostgreSQL. \u0218i astfel, treptat, am devenit DBA PostgreSQL.<\/p>\n

<\/p>\n

\u0218i pe parcursul \u00eentregii mele cariere, am fost mereu interesat de temele statisticii, monitoriz\u0103rii \u0219i capt\u0103rii telemetriei. Iar c\u00e2nd eram administrator de sistem, m-am ocupat foarte mult de Zabbix. \u0218i am scris un set mic de scripturi sub numele de zabbix-extensions<\/a><\/noindex>. A fost destul de popular la vremea sa. \u0218i acolo puteai monitoriza diverse lucruri importante, nu doar Linux, ci \u0219i diferite componente.<\/p>\n

<\/p>\n

Acum m\u0103 ocup de PostgreSQL. Scriu acum altceva, care permite lucrul cu statisticile PostgreSQL. Se nume\u0219te pgCenter<\/a><\/noindex> (articol pe Habr \u2014 Statistica PostgreSQL f\u0103r\u0103 nervi \u0219i stres.<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

O scurt\u0103 introducere. Ce tipuri de situa\u021bii \u00eent\u00e2mpin\u0103 clien\u021bii no\u0219tri? Poate surveni o avarie legat\u0103 de baza de date. \u0218i c\u00e2nd baza de date este restaurat\u0103, managerul de departament sau managerul de dezvoltare spune: \u201eDragilor, ar trebui s\u0103 monitoriz\u0103m baza de date, pentru c\u0103 s-a \u00eent\u00e2mplat ceva r\u0103u \u0219i trebuie s\u0103 ne asigur\u0103m c\u0103 a\u0219a ceva nu se va mai \u00eent\u00e2mpla \u00een viitor.\u201d \u0218i aici \u00eencepe un proces interesant de alegere a sistemului de monitorizare sau de adaptare a sistemului de monitorizare existent, pentru a putea monitoriza baza de date \u2013 PostgreSQL, MySQL sau alte tipuri. Colegii \u00eencep s\u0103 propun\u0103: \u201eAm auzit c\u0103 exist\u0103 o astfel de baz\u0103 de date. S\u0103 o folosim.\u201d Colegii \u00eencep s\u0103 discute \u00eentre ei. \u0218i, \u00een final, alegem o baz\u0103 de date, dar monitorizarea PostgreSQL \u00een aceasta este destul de slab reprezentat\u0103, iar tot timpul trebuie s\u0103 facem ajust\u0103ri. S\u0103 lu\u0103m diferite repozitorii de pe GitHub, s\u0103 le clon\u0103m, s\u0103 adapt\u0103m scripturile, s\u0103 le configur\u0103m. \u0218i \u00een final, asta se transform\u0103 \u00eentr-o munc\u0103 manual\u0103. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

De aceea, \u00een aceast\u0103 prezentare, voi \u00eencerca s\u0103 v\u0103 ofer c\u00e2teva cuno\u0219tin\u021be despre cum s\u0103 alege\u021bi monitorizarea nu doar pentru PostgreSQL, ci \u0219i pentru baze de date. \u0218i s\u0103 ofer informa\u021biile care v\u0103 vor permite s\u0103 \u00eembun\u0103t\u0103\u021bi\u021bi monitorizarea, astfel \u00eenc\u00e2t s\u0103 ob\u021bine\u021bi un beneficiu din ea, pentru a putea monitoriza baza de date \u00een mod eficient, pentru a avertiza la timp despre posibilele situa\u021bii de avarie care pot ap\u0103rea. <\/p>\n

<\/p>\n

\u0218i ideile care vor fi prezentate \u00een aceast\u0103 expunere pot fi adaptate direct la orice baz\u0103 de date, fie c\u0103 este o SGBD sau noSQL. A\u0219adar, nu se refer\u0103 doar la PostgreSQL, ci vor exista multe re\u021bete despre cum s\u0103 se fac\u0103 acest lucru \u00een PostgreSQL. Vor fi exemple de interog\u0103ri, exemple de entit\u0103\u021bi care exist\u0103 \u00een PostgreSQL pentru monitorizare. \u0218i dac\u0103 baza dumneavoastr\u0103 de date are elemente similare, care pot fi integrate \u00een monitorizare, le pute\u021bi adapta, ad\u0103uga \u0219i va fi excelent.<\/p>\n

<\/p>\n

\"Fundamentele\u00cen prezentare, nu voi
\nvorbi despre cum s\u0103 livra\u021bi \u0219i s\u0103 stoca\u021bi metrici. Nu voi men\u021biona nimic despre procesarea ulterioar\u0103 a datelor \u0219i despre furnizarea acestora utilizatorului. \u0218i nu voi discuta despre alerte.
\nPe parcursul povestirii, voi ar\u0103ta diverse capturi de ecran ale monitoriz\u0103rilor existente \u0219i voi putea s\u0103 le critic. Totu\u0219i, voi \u00eencerca s\u0103 nu numesc branduri pentru a nu crea publicitate sau anti-publicitate acestor produse. Prin urmare, toate coinciden\u021bele sunt \u00eent\u00e2mpl\u0103toare \u0219i r\u0103m\u00e2n la latitudinea dumneavoastr\u0103.
\n\"Fundamentele
\nPentru \u00eenceput, s\u0103 ne l\u0103murim ce \u00eenseamn\u0103 monitoring. Monitoringul este un lucru foarte important de care trebuie s\u0103 dispunem. Toat\u0103 lumea \u00een\u021belege asta. Totu\u0219i, \u00een acela\u0219i timp, monitoringul nu se \u00eencadreaz\u0103 \u00een categoria produselor de afaceri \u0219i nu influen\u021beaz\u0103 direct profitul companiei, de aceea se acord\u0103 \u00eentotdeauna timp pentru monitoring \u00een mod indirect. Dac\u0103 avem timp, ne ocup\u0103m de monitoring, dac\u0103 nu, este \u00een regul\u0103, \u00eel punem \u00een backlog \u0219i ne vom \u00eentoarce la aceste sarcini c\u00e2ndva. <\/p>\n

<\/p>\n

Prin urmare, din practica noastr\u0103, atunci c\u00e2nd venim la clien\u021bi, monitoringul este adesea insuficient dezvoltat \u0219i nu are elemente interesante care s\u0103 ne ajute s\u0103 facem o munc\u0103 mai bun\u0103 cu baza de date. A\u0219adar, monitoringul trebuie mereu \u00eembun\u0103t\u0103\u021bit. <\/p>\n

<\/p>\n

Baza de date este un element complex care trebuie s\u0103 fie monitorizat, deoarece baza de date este un depozit de informa\u021bie. Informa\u021bia este foarte important\u0103 pentru companie \u0219i nu poate fi pierdut\u0103 sub nicio form\u0103. \u00cen acela\u0219i timp, bazele de date sunt pachete software foarte complexe. Ele sunt formate dintr-un num\u0103r mare de componente. Multe dintre aceste componente necesit\u0103 monitorizare. <\/p>\n

<\/p>\n

\"FundamenteleDac\u0103 discut\u0103m specific despre PostgreSQL, acesta poate fi reprezentat printr-un astfel de diagram\u0103, care este format\u0103 dintr-un num\u0103r mare de componente. Aceste componente interac\u021bioneaz\u0103 \u00eentre ele. \u00cen acela\u0219i timp, \u00een PostgreSQL exist\u0103 ceea ce se nume\u0219te sub-sistemul Stats Collector, care permite colectarea statisticilor despre activitatea acestor sub-sisteme \u0219i ofer\u0103 o interfa\u021b\u0103 administratorului sau utilizatorului, pentru a putea vizualiza aceste statistici. <\/p>\n

<\/p>\n

Aceste statistici sunt prezentate sub form\u0103 de seturi de func\u021bii \u0219i views (vizualiz\u0103ri). Acestea pot fi numite \u0219i tabele. Adic\u0103, cu ajutorul clientului psql obi\u0219nuit, v\u0103 pute\u021bi conecta la baza de date, s\u0103 face\u021bi un select asupra acestor func\u021bii \u0219i vizualiz\u0103ri \u0219i s\u0103 ob\u021bine\u021bi date concrete despre activitatea sub-sistemelor PostgreSQL. <\/p>\n

<\/p>\n

Pute\u021bi ad\u0103uga aceste date \u00een sistemul dumneavoastr\u0103 preferat de monitorizare, s\u0103 desena\u021bi grafice, s\u0103 ad\u0103uga\u021bi func\u021bii \u0219i s\u0103 ob\u021bine\u021bi analize pe termen lung. <\/p>\n

<\/p>\n

Dar \u00een acest raport nu voi examina toate aceste func\u021bii, deoarece ar putea dura o zi \u00eentreag\u0103. Voi aborda doar dou\u0103, trei sau chiar patru aspecte \u0219i voi explica cum contribuie acestea la \u00eembun\u0103t\u0103\u021birea monitoriz\u0103rii.
\n\"Fundamentele
\n\u0218i dac\u0103 vorbim despre monitorizarea bazei de date, ce trebuie s\u0103 monitoriz\u0103m? \u00cen primul r\u00e2nd, trebuie s\u0103 monitoriz\u0103m disponibilitatea, deoarece baza de date este un serviciu care ofer\u0103 acces la date clien\u021bilor, iar noi trebuie s\u0103 monitoriz\u0103m disponibilitatea, dar ofer\u0103 \u0219i anumite caracteristici calitative \u0219i cantitative. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

De asemenea, trebuie s\u0103 monitoriz\u0103m clien\u021bii care se conecteaz\u0103 la baza noastr\u0103 de date, deoarece ace\u0219tia pot fi at\u00e2t clien\u021bi normali, c\u00e2t \u0219i clien\u021bi d\u0103un\u0103tori, care pot afecta baza de date. Ace\u0219tia trebuie monitoriza\u021bi \u0219i activitatea lor trebuie urm\u0103rit\u0103.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Atunci c\u00e2nd clien\u021bii se conecteaz\u0103 la baza de date, este evident c\u0103 \u00eencep s\u0103 lucreze cu datele noastre, prin urmare, trebuie s\u0103 monitoriz\u0103m \u0219i modul \u00een care clien\u021bii lucreaz\u0103 cu datele: cu ce tabele, iar \u00eentr-o m\u0103sur\u0103 mai mic\u0103 cu ce indici. Adic\u0103 trebuie s\u0103 evalu\u0103m \u00eenc\u0103rcarea de munc\u0103 (workload) generat\u0103 de clien\u021bii no\u0219tri.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Dar \u0219i \u00eenc\u0103rcarea de munc\u0103 const\u0103, desigur, din interog\u0103ri. Aplica\u021biile se conecteaz\u0103 la baz\u0103, acceseaz\u0103 datele prin intermediul interog\u0103rilor, a\u0219a c\u0103 este important s\u0103 evalu\u0103m ce interog\u0103ri avem \u00een baza de date, s\u0103 monitoriz\u0103m adecvarea lor, s\u0103 ne asigur\u0103m c\u0103 nu sunt scrise gre\u0219it, \u0219i c\u0103 unele op\u021biuni trebuie rescrise pentru a func\u021biona mai repede \u0219i cu o performan\u021b\u0103 mai bun\u0103. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u0218i av\u00e2nd \u00een vedere c\u0103 vorbim despre baza de date, trebuie s\u0103 \u0219tim c\u0103 aceasta implic\u0103 \u00eentotdeauna procese de fundal. Procesele de fundal permit men\u021binerea performan\u021bei bazei de date la un nivel bun, de aceea func\u021bionarea lor necesit\u0103 o anumit\u0103 cantitate de resurse. \u00cen acela\u0219i timp, acestea se pot suprapune cu resursele interog\u0103rilor clien\u021bilor, a\u0219a c\u0103 o operare excesiv\u0103 a proceselor de fundal poate influen\u021ba direct performan\u021ba interog\u0103rilor clien\u021bilor. Prin urmare, acestea trebuie de asemenea monitorizate \u0219i urm\u0103rite pentru a evita eventualele abateri \u00een ceea ce prive\u0219te procesele de fundal. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u0218i asta \u00een ceea ce prive\u0219te monitorizarea bazei de date r\u0103m\u00e2ne \u00een metrica sistemului. \u00cens\u0103, av\u00e2nd \u00een vedere c\u0103 infrastructura noastr\u0103 se mut\u0103 \u00een mare parte \u00een cloud, metricile sistemului unui anumit gazd\u0103 sunt \u00eentotdeauna pe plan secund. Totu\u0219i, \u00een bazele de date, ele sunt \u00een continuare relevante, iar monitorizarea metricilor sistemului este cu siguran\u021b\u0103 necesar\u0103. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Cu metricile sistemului, lucrurile sunt \u00een general acceptabile, toate sistemele de monitorizare moderne au deja suport pentru aceste metrici, dar \u00een ansamblu, \u00eenc\u0103 mai lipsesc unele componente \u0219i trebuie ad\u0103ugate c\u00e2teva lucruri. Voi discuta despre ele, vor fi c\u00e2teva slide-uri dedicate acestora. <\/p>\n

<\/p>\n

\"Fundamentele
\nPrimul punct al planului este disponibilitatea. Ce \u00eenseamn\u0103 disponibilitatea? Disponibilitatea, din perspectiva mea, este capacitatea bazei de a gestiona conexiuni, adic\u0103 baza este activ\u0103, ea, ca serviciu, accept\u0103 conexiuni din partea clien\u021bilor. \u0218i aceast\u0103 disponibilitate poate fi evaluat\u0103 cu ajutorul unor caracteristici. Aceste caracteristici sunt foarte convenabile de afi\u0219at pe dashboard-uri. <\/p>\n

<\/p>\n

\"Fundamentele
\nToat\u0103 lumea \u0219tie ce sunt dashboard-urile. Este acel moment c\u00e2nd arunci o privire pe ecran, unde este centralizat\u0103 informa\u021bia necesar\u0103. \u0218i po\u021bi deja s\u0103 determini imediat - exist\u0103 o problem\u0103 \u00een baz\u0103 sau nu.
\nPrin urmare, disponibilitatea bazei de date \u0219i alte caracteristici cheie trebuie \u00eentotdeauna afi\u0219ate pe dashboard-uri, astfel \u00eenc\u00e2t aceast\u0103 informa\u021bie s\u0103 fie la \u00eendem\u00e2n\u0103, s\u0103 fie mereu aproape de tine. Anumite detalii suplimentare, care ajut\u0103 la investigarea incidentelor, la analiza situa\u021biilor de urgen\u021b\u0103, trebuie deja afi\u0219ate pe dashboard-uri secundare sau ascunse \u00een linkuri de tip drilldown care conduc c\u0103tre sisteme externe de monitorizare. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Un exemplu al unui sistem de monitorizare bine cunoscut. Este un sistem de monitorizare foarte avansat. Colecteaz\u0103 foarte multe date, dar din punctul meu de vedere, are o viziune ciudat\u0103 asupra dashboard-urilor. Exist\u0103 un link \u201ecreeaz\u0103 dashboard\u201d. Dar c\u00e2nd creezi un dashboard, creezi o list\u0103, format\u0103 din dou\u0103 coloane, o list\u0103 de grafice. \u0218i c\u00e2nd trebuie s\u0103 verifici ceva, \u00eencepi s\u0103 dai click cu mouse-ul, s\u0103 derulezi, s\u0103 cau\u021bi graficul dorit. \u0218i acest lucru consum\u0103 timp, adic\u0103 nu exist\u0103 dashboard-uri propriu-zise. Exist\u0103 doar liste de grafice.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Ce trebuie ad\u0103ugat pe aceste tablouri de bord? Poate \u00eencepe cu un atribut precum timpul de r\u0103spuns. \u00cen PostgreSQL exist\u0103 o vedere numit\u0103 pg_stat_statements. Implicit, aceasta este dezactivat\u0103, dar este una dintre vederea sistemic\u0103 important\u0103 care trebuie activat\u0103 \u0219i utilizat\u0103 \u00eentotdeauna. Ea stocheaz\u0103 informa\u021bii despre toate interog\u0103rile care au fost executate \u00een baza de date. <\/p>\n

<\/p>\n

Prin urmare, putem \u00eencepe de la faptul c\u0103 putem lua timpul total de execu\u021bie al tuturor interog\u0103rilor \u0219i \u00eel putem \u00eemp\u0103r\u021bi la num\u0103rul de interog\u0103ri folosind c\u00e2mpurile men\u021bionate mai sus. Dar aceasta este o temperatur\u0103 medie \u00een spital. Putem porni de la alte c\u00e2mpuri \u2013 timpul minim de execu\u021bie, timpul maxim \u0219i cel median. Chiar putem construi percentili; \u00een PostgreSQL exist\u0103 func\u021bii corespunz\u0103toare pentru asta. \u0218i putem ob\u021bine ni\u0219te cifre care caracterizeaz\u0103 timpul de r\u0103spuns al bazei noastre pentru interog\u0103rile deja executate, adic\u0103 nu execut\u0103m o interogare fals\u0103 'select 1' \u0219i observ\u0103m timpul de r\u0103spuns, ci analiz\u0103m timpii de r\u0103spuns pentru interog\u0103rile deja executate \u0219i desen\u0103m fie un singur num\u0103r, fie construim un grafic pe baza acestuia. <\/p>\n

<\/p>\n

De asemenea, este important s\u0103 monitoriz\u0103m num\u0103rul de erori generate de sistem \u00een prezent. \u0218i pentru asta putem folosi vederea pg_stat_database. Ne orient\u0103m dup\u0103 c\u00e2mpul xact_rollback. Acest c\u00e2mp arat\u0103 nu doar num\u0103rul rollback-urilor care au loc \u00een baz\u0103, ci \u0219i ia \u00een considerare num\u0103rul de erori. S\u0103 spunem, putem afi\u0219a aceast\u0103 cifr\u0103 \u00een tabloul nostru de bord \u0219i s\u0103 vedem c\u00e2te erori avem \u00een prezent. Dac\u0103 sunt multe erori, acesta este deja un motiv bun pentru a verifica jurnalele \u0219i a vedea ce fel de erori sunt \u0219i de ce apar, iar apoi s\u0103 investigh\u0103m \u0219i s\u0103 le rezolv\u0103m.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Putem ad\u0103uga un indicator, cum ar fi Tachometrul. Aceasta m\u0103soar\u0103 num\u0103rul de tranzac\u021bii pe secund\u0103 \u0219i num\u0103rul de interog\u0103ri pe secund\u0103. S\u0103 spunem c\u0103 po\u021bi folosi aceste cifre ca performan\u021ba curent\u0103 a bazei tale de date \u0219i s\u0103 observi dac\u0103 exist\u0103 v\u00e2rfuri de interog\u0103ri, v\u00e2rfuri de tranzac\u021bii sau, din contr\u0103, baza este sub\u00eenc\u0103rcat\u0103 pentru c\u0103 un anumit backend a c\u0103zut. Este important s\u0103 monitorizezi mereu aceast\u0103 cifr\u0103 \u0219i s\u0103 re\u021bii c\u0103 pentru proiectul nostru o astfel de performan\u021b\u0103 este normal\u0103, iar valorile mai mari sau mai mici sunt probleme \u0219i neclarit\u0103\u021bi, ceea ce \u00eenseamn\u0103 c\u0103 trebuie s\u0103 analiz\u0103m de ce sunt astfel de cifre.<\/p>\n

<\/p>\n

Pentru a evalua num\u0103rul de tranzac\u021bii, putem s\u0103 ne orient\u0103m din nou la vizualizarea pg_stat_database. Putem s\u0103 adun\u0103m num\u0103rul de commituri \u0219i num\u0103rul de rollbackuri pentru a ob\u021bine num\u0103rul de tranzac\u021bii pe secund\u0103. <\/p>\n

<\/p>\n

To\u021bi \u00een\u021beleg c\u0103 \u00eentr-o tranzac\u021bie pot fi incluse mai multe cereri? De aceea, TPS \u0219i QPS sunt ceva diferite. <\/p>\n

<\/p>\n

Num\u0103rul de cereri pe secund\u0103 poate fi ob\u021binut din pg_stat_statements \u0219i se poate calcula pur \u0219i simplu suma tuturor cererilor efectuate. Este clar c\u0103 compar\u0103m valoarea curent\u0103 cu cea anterioar\u0103, sc\u0103dem, ob\u021binem delta \u0219i astfel ob\u021binem num\u0103rul.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Se pot ad\u0103uga metrici suplimentare, dac\u0103 se dore\u0219te, care ajut\u0103, de asemenea, s\u0103 evalu\u0103m disponibilitatea bazei noastre \u0219i s\u0103 monitoriz\u0103m \u2013 dac\u0103 nu au fost perioade de downtime. <\/p>\n

<\/p>\n

Una dintre aceste metrici este uptime-ul. \u00cens\u0103 uptime-ul \u00een PostgreSQL este un lucru pu\u021bin complicat. Voi explica de ce. C\u00e2nd PostgreSQL a fost pornit, uptime-ul \u00eencepe s\u0103 fie m\u0103surat. Dar dac\u0103, la un moment dat, de exemplu, noaptea, se executa o sarcin\u0103, iar OOM-killer-ul a terminat for\u021bat un proces fiu al PostgreSQL, atunci \u00een acest caz PostgreSQL va \u00eenchide conexiunile tuturor clien\u021bilor, va reseta zona de memorie portionat\u0103 \u0219i va \u00eencepe recuperarea de la ultima punct de control. \u0218i \u00een timp ce aceast\u0103 recuperare de la punctul de control dureaz\u0103, baza de date nu accept\u0103 conexiuni, adic\u0103 aceast\u0103 situa\u021bie poate fi evaluat\u0103 ca downtime. Dar, \u00een acela\u0219i timp, contorul uptime-ului nu se va reseta, deoarece ia \u00een considerare timpul de pornire a postmaster-ului din cel mai timpuriu moment. De aceea, astfel de situa\u021bii pot fi omise.<\/p>\n

<\/p>\n

De asemenea, trebuie s\u0103 monitoriz\u0103m num\u0103rul de lucr\u0103tori pentru vacuum. Toat\u0103 lumea \u0219tie ce este autovacuum \u00een PostgreSQL? Este un subsistem interesant \u00een PostgreSQL. Despre el au fost scrise multe articole, au fost prezentate multe comunic\u0103ri. S-au purtat multe discu\u021bii despre vacuum, despre cum ar trebui s\u0103 func\u021bioneze acesta. Mul\u021bi \u00eel consider\u0103 un r\u0103u inevitabil. Dar a\u0219a este. Este un fel de analog al colectorului de gunoi, care cur\u0103\u021b\u0103 versiunile dep\u0103\u0219ite ale r\u00e2ndurilor, care nu sunt necesare niciuneia dintre tranzac\u021bii \u0219i elibereaz\u0103 spa\u021biu \u00een tabele, indici pentru noi r\u00e2nduri. <\/p>\n

<\/p>\n

De ce trebuie s\u0103 \u00eel monitoriz\u0103m? Pentru c\u0103 vacuumul uneori face foarte mult r\u0103u. Acesta consum\u0103 o cantitate mare de resurse, iar cererile clien\u021bilor \u00eencep s\u0103 fie afectate. <\/p>\n

<\/p>\n

Monitorizarea se face prin vizualizarea pg_stat_activity, despre care voi vorbi \u00een urm\u0103toarea sec\u021biune. Aceast\u0103 vizualizare arat\u0103 activitatea curent\u0103 \u00een baza de date. Prin intermediul acestei activit\u0103\u021bi putem urm\u0103ri num\u0103rul de opera\u021bii de vacuum care sunt \u00een curs de desf\u0103\u0219urare \u00een acest moment. Putem urm\u0103ri procesele de vacumare \u0219i putem observa c\u0103, dac\u0103 dep\u0103\u0219im limita, este un motiv s\u0103 ne uit\u0103m la set\u0103rile PostgreSQL \u0219i s\u0103 optimiz\u0103m modul \u00een care func\u021bioneaz\u0103 vacuum-ul. <\/p>\n

<\/p>\n

O alt\u0103 caracteristic\u0103 a PostgreSQL este c\u0103 acesta este foarte afectat de tranzac\u021biile lungi. \u00cen special, de tranzac\u021biile care dureaz\u0103 mult \u0219i nu fac nimic. Acestea sunt a\u0219a-numitele tranzac\u021bii idle-in-transaction. O astfel de tranzac\u021bie men\u021bine bloc\u0103rile, \u00eempiedic\u00e2nd func\u021bionarea vacuum-ului. Ca urmare, tabelele se umfl\u0103, cresc \u00een dimensiune. \u0218i interog\u0103rile care proceseaz\u0103 aceste tabele \u00eencep s\u0103 lucreze mai lent, deoarece trebuie s\u0103 procure toate vechile versiuni de r\u00e2nduri din memorie pe disc \u0219i \u00eenapoi.<\/strong> De aceea, este necesar s\u0103 monitoriz\u0103m timpul, durata celor mai lungi tranzac\u021bii \u0219i cele mai lungi interog\u0103ri de vacuum. \u0218i dac\u0103 observ\u0103m procese care func\u021bioneaz\u0103 deja foarte mult, mai mult de 10-20-30 de minute pentru o sarcin\u0103 OLTP, atunci trebuie s\u0103 ne concentr\u0103m asupra lor \u0219i s\u0103 le \u00eencheiem for\u021bat sau s\u0103 optimiz\u0103m aplica\u021bia, astfel \u00eenc\u00e2t s\u0103 nu fie apelate \u0219i s\u0103 nu r\u0103m\u00e2n\u0103 suspendate at\u00e2t de mult.<\/strong> Pentru o sarcin\u0103 analitic\u0103, 10-20-30 de minute este normal, uneori pot fi chiar mai lungi. <\/p>\n

<\/p>\n

\"Fundamentele
\nMai departe, avem varianta cu clien\u021bii conecta\u021bi. Dup\u0103 ce am format un tablou de bord, am expus pe el metrice cheie de disponibilitate, putem ad\u0103uga \u0219i informa\u021bii suplimentare despre clien\u021bii conecta\u021bi. <\/p>\n

<\/p>\n

Informa\u021biile despre clien\u021bii conecta\u021bi sunt importante deoarece, din punctul de vedere al PostgreSQL, clien\u021bii pot fi diferi\u021bi. Exist\u0103 clien\u021bi buni \u0219i clien\u021bi r\u0103i. <\/p>\n

<\/p>\n

Un exemplu simplu. Prin client \u00een\u021beleg aplica\u021bia. Aplica\u021bia s-a conectat la baza de date \u0219i \u00eencepe imediat s\u0103 trimit\u0103 cererile sale, baza de date le proceseaz\u0103 \u0219i le execut\u0103, iar rezultatele sunt returnate clientului. Ace\u0219tia sunt clien\u021bi buni \u0219i corec\u021bi. <\/p>\n

<\/p>\n

Exist\u0103 situa\u021bii \u00een care clientul s-a conectat, men\u021bine conexiunea, dar nu face nimic. El se afl\u0103 \u00eentr-o stare de idle. <\/p>\n

<\/p>\n

Dar exist\u0103 clien\u021bi r\u0103i. De exemplu, acela\u0219i client s-a conectat, a deschis o tranzac\u021bie, a f\u0103cut ceva \u00een baza de date \u0219i apoi a plecat \u00een cod, s\u0103 spunem, pentru a apela o surs\u0103 extern\u0103 sau pentru a efectua o procesare a datelor primite. \u00cens\u0103 nu a \u00eenchis tranzac\u021bia. Astfel, tranzac\u021bia r\u0103m\u00e2ne deschis\u0103 \u00een baza de date \u0219i blocheaz\u0103 o linie. Aceasta este o situa\u021bie proast\u0103. \u0218i dac\u0103 aplica\u021bia ar trebui s\u0103 se pr\u0103bu\u0219easc\u0103 din cauza unei excep\u021bii (Exception), atunci tranzac\u021bia poate r\u0103m\u00e2ne deschis\u0103 pentru o perioad\u0103 foarte lung\u0103 de timp. Acest lucru afecteaz\u0103 direct performan\u021ba PostgreSQL. PostgreSQL va func\u021biona mai lent. De aceea, este important s\u0103 identific\u0103m \u0219i s\u0103 \u00eencheiem for\u021bat activitatea acestor clien\u021bi. Este necesar s\u0103 optimiz\u0103m aplica\u021bia, astfel \u00eenc\u00e2t s\u0103 nu existe astfel de situa\u021bii. <\/p>\n

<\/p>\n

Al\u021bi clien\u021bi r\u0103i sunt clien\u021bii care a\u0219teapt\u0103. \u00cens\u0103 ei devin r\u0103i din cauza circumstan\u021belor. De exemplu, o tranzac\u021bie simpl\u0103 care st\u0103 \u00een a\u0219teptare: poate deschide o tranzac\u021bie, blocheaz\u0103 anumite linii, apoi undeva \u00een cod se pr\u0103bu\u0219e\u0219te, l\u0103s\u00e2nd o tranzac\u021bie suspendat\u0103. Un alt client vine \u0219i solicit\u0103 acelea\u0219i date, dar se confrunt\u0103 cu o blocare, pentru c\u0103 acea tranzac\u021bie suspendat\u0103 deja de\u021bine bloc\u0103ri pe anumite linii necesare. Astfel, a doua tranzac\u021bie va r\u0103m\u00e2ne suspendat\u0103 \u00een a\u0219teptarea finaliz\u0103rii primei tranzac\u021bii sau a \u00eenchiderii sale for\u021bate de c\u0103tre administrator. \u00cen acest fel, tranzac\u021biile \u00een a\u0219teptare se pot acumula \u0219i pot dep\u0103\u0219i limita de conexiuni la baza de date. \u0218i c\u00e2nd limita este dep\u0103\u0219it\u0103, aplica\u021bia nu mai poate lucra cu baza. Aceasta este o situa\u021bie de urgen\u021b\u0103 pentru proiect. De aceea, este important s\u0103 urm\u0103rim clien\u021bii r\u0103i \u0219i s\u0103 reac\u021bion\u0103m prompt. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Un alt exemplu de monitorizare. \u0218i aici avem un dashboard decent. Exist\u0103 informa\u021bii despre conexiuni \u00een partea de sus. Conexiuni DB \u2013 8 la num\u0103r. \u0218i at\u00e2t. Nu avem informa\u021bii despre care clien\u021bi sunt activi, care clien\u021bi sunt doar inactivi, f\u0103r\u0103 s\u0103 fac\u0103 nimic. Nu exist\u0103 informa\u021bii despre tranzac\u021biile suspendate \u0219i despre conexiunile a\u0219tept\u0103toare, adic\u0103 este o cifr\u0103 care arat\u0103 num\u0103rul de conexiuni \u0219i at\u00e2t. Mai departe, ghida\u021bi-v\u0103 singuri.
\n\"Fundamentele
\nPrin urmare, pentru a ad\u0103uga aceste informa\u021bii \u00een monitorizare, trebuie s\u0103 ne adres\u0103m vederii sistemice pg_stat_activity. Dac\u0103 petrece\u021bi mult timp \u00een PostgreSQL, aceasta este o vedere foarte util\u0103 care ar trebui s\u0103 devin\u0103 prietenul dumneavoastr\u0103, deoarece arat\u0103 activitatea curent\u0103 din PostgreSQL, adic\u0103 ce se petrece \u00een acesta. Fiecare proces are o linie separat\u0103 care arat\u0103 informa\u021biile despre acel proces: de pe ce gazd\u0103 s-a realizat conexiunea, sub ce utilizator, cu ce nume, c\u00e2nd a fost ini\u021biat\u0103 tranzac\u021bia, ce interogare este \u00een curs de execu\u021bie, ce interogare a fost executat\u0103 ultima dat\u0103. \u0218i, prin urmare, starea clientului o putem evalua pe baza c\u00e2mpului stat. \u00cenc\u0103 o dat\u0103, putem face o grupare pe acest c\u00e2mp \u0219i putem ob\u021bine acele statistici care exist\u0103 acum \u00een baza de date \u0219i num\u0103rul de conexiuni care au acel stat \u00een baza de date. Iar cifrele ob\u021binute le putem trimite \u00een monitorizarea noastr\u0103 \u0219i putem genera grafice pe baza lor.
\nDe asemenea, este important s\u0103 evalu\u0103m durata tranzac\u021biei. Am men\u021bionat deja c\u0103 este important s\u0103 evalu\u0103m durata vacuum-urilor, dar \u0219i tranzac\u021biile sunt evaluate la fel. Exist\u0103 c\u00e2mpurile xact_start \u0219i query_start. Acestea, dac\u0103 vre\u021bi, arat\u0103 momentul \u00eenceperii tranzac\u021biei \u0219i momentul \u00eenceperii interog\u0103rii. Folosim func\u021bia now(), care arat\u0103 marcajul de timp curent \u0219i sc\u0103dem timestamp-ul tranzac\u021biei \u0219i interog\u0103rii. \u0218i ob\u021binem durata tranzac\u021biei, durata interog\u0103rii. <\/p>\n

<\/p>\n

Dac\u0103 vedem tranzac\u021bii lungi, ar trebui s\u0103 le finaliz\u0103m. Pentru sarcini OLTP, tranzac\u021biile lungi sunt cele care dep\u0103\u0219esc 1-2-3 minute.<\/strong>. Pentru sarcini OLAP, tranzac\u021biile lungi sunt normale, dar dac\u0103 acestea dureaz\u0103 mai mult de dou\u0103 ore, acesta este un semn c\u0103 undeva avem o problem\u0103.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentele
\nC\u00e2nd clien\u021bii se conecteaz\u0103 la baza de date, ace\u0219tia \u00eencep s\u0103 lucreze cu datele noastre. Ei fac referire la tabele, acceseaz\u0103 indec\u0219ii pentru a ob\u021bine date din tabel. Este important s\u0103 evalu\u0103m cum lucreaz\u0103 clien\u021bii cu aceste date.<\/p>\n

<\/p>\n

Acest lucru este necesar pentru a evalua sarcina noastr\u0103 de lucru \u0219i a \u00een\u021belege aproximativ care dintre tabele sunt cele mai \u201efierbin\u021bi\u201d. De exemplu, este util \u00een situa\u021biile \u00een care vrem s\u0103 plas\u0103m tabelele \u201efierbin\u021bi\u201d pe un stoc rapid SSD. \u00cen schimb, unele tabele de arhiv\u0103, pe care nu le folosim de mult timp, pot fi mutate pe un \u201ecold\u201d arhiv\u0103, pe discuri SATA, l\u0103s\u00e2ndu-le s\u0103 r\u0103m\u00e2n\u0103 acolo; accesul la ele se va face doar c\u00e2nd este necesar. <\/p>\n

<\/p>\n

De asemenea, este util pentru detectarea anomaliilor dup\u0103 diverse lans\u0103ri \u0219i desf\u0103\u0219ur\u0103ri. S\u0103 presupunem c\u0103 proiectul a lansat o nou\u0103 caracteristic\u0103. De exemplu, a fost ad\u0103ugat\u0103 o nou\u0103 func\u021bionalitate pentru lucrul cu baza de date. Iar dac\u0103 construim grafice de utilizare a tabelelor, pe aceste grafice putem detecta cu u\u0219urin\u021b\u0103 aceste anomalii. De exemplu, v\u00e2rfuri de update sau v\u00e2rfuri de delete. Acest lucru va fi foarte vizibil.<\/p>\n

<\/p>\n

De asemenea, se pot detecta anomaliile \u201edeviate\u201d ale statisticilor. Ce \u00eenseamn\u0103 asta? PostgreSQL are un planificator de interog\u0103ri foarte puternic \u0219i bun. Iar dezvoltatorii dedic\u0103 mult timp dezvolt\u0103rii acestuia. Cum func\u021bioneaz\u0103? Pentru a construi planuri bune, PostgreSQL colecteaz\u0103, la intervale de timp specifice, statistici despre distribu\u021bia datelor \u00een tabele. Acestea includ cele mai frecvente valori: num\u0103rul de valori unice, informa\u021bii despre NULL \u00een tabel, foarte multe informa\u021bii. <\/p>\n

<\/p>\n

Pe baza acestor statistici, planificatorul construie\u0219te mai multe interog\u0103ri, alege cea mai optim\u0103 \u0219i folose\u0219te acest plan de interogare pentru a executa efectiv interogarea \u0219i a returna datele. <\/p>\n

<\/p>\n

Se \u00eent\u00e2mpl\u0103 ca statisticile s\u0103 \u201edeviate\u201d. Calitatea \u0219i cantitatea datelor s-au schimbat \u00een tabel, dar statisticile nu au fost actualizate. Iar planurile formate pot deveni suboptimale. Dac\u0103 planurile noastre devin suboptime \u00een urma monitoriz\u0103rii, pe tabele, vom putea vedea aceste anomalii. De exemplu, undeva calitativ s-au schimbat datele \u0219i, \u00een loc de utilizarea unui index, s-a \u00eenceput utilizarea unei treceri secven\u021biale prin tabel; astfel, dac\u0103 interogarea trebuie s\u0103 returneze doar 100 de r\u00e2nduri (exist\u0103 o limit\u0103 de 100), atunci pentru aceast\u0103 interogare va fi efectuat\u0103 o c\u0103utare complet\u0103. \u0218i acest lucru are \u00eentotdeauna un impact negativ asupra performan\u021bei. <\/p>\n

<\/p>\n

\u0218i vom putea vedea acest lucru \u00een monitorizare. Deja putem verifica aceast\u0103 interogare, face un explain pentru ea, aduna statistica, construi un nou index suplimentar. \u0218i putem reac\u021biona la aceast\u0103 problem\u0103. Din acest motiv este important. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Un alt exemplu de monitorizare. Cred c\u0103 mul\u021bi l-au recunoscut, deoarece este foarte popular. Cine \u00eel folose\u0219te \u00een proiectele sale 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. Dar aici exist\u0103 un detaliu nepl\u0103cut. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Exist\u0103 c\u00e2teva grafice. \u0218i ca unitate sunt indicate byte-urile, adic\u0103 sunt 5 grafice. Acestea sunt Insert data, Update data, Delete data, Fetch data \u0219i Return data. Ca unitate de m\u0103sur\u0103 sunt indicate byte-urile. Problema este c\u0103 statistica din PostgreSQL returneaz\u0103 datele \u00een tuple (\u00een r\u00e2nduri). \u0218i, prin urmare, aceste grafice sunt o modalitate foarte bun\u0103 de a subestima sarcina de lucru de mai multe ori, zeci de ori, deoarece tuple-urile nu sunt byte-uri, tuple-urile sunt r\u00e2nduri, adic\u0103 multe byte-uri \u0219i au \u00eentotdeauna lungime variabil\u0103. A\u0219adar, a calcula sarcina de lucru \u00een byte-uri folosind tuple-uri este o sarcin\u0103 nerealizabil\u0103 sau foarte complicat\u0103. De aceea, c\u00e2nd folose\u0219ti un dashboard sau monitorizarea \u00eencorporat\u0103, este \u00eentotdeauna important s\u0103 \u00een\u021belegi c\u0103 acesta func\u021bioneaz\u0103 corect \u0219i \u00ee\u021bi returneaz\u0103 datele evaluate corect. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Cum se ob\u021bine statistica pentru aceste tabele? Pentru aceasta, \u00een PostgreSQL exist\u0103 un anumit grup de vizualiz\u0103ri. Iar vizualizarea principal\u0103 este pg_stat_user_tables<\/a><\/noindex>. User_tables \u00eenseamn\u0103 c\u0103 tabelele sunt create \u00een numele utilizatorului. Spre deosebire de vizualiz\u0103rile sistemice, care sunt folosite de PostgreSQL \u00eensu\u0219i. \u0218i exist\u0103 un tabel sumar numit Alltables, care include at\u00e2t vizualiz\u0103rile sistemice, c\u00e2t \u0219i cele ale utilizatorilor. Po\u021bi s\u0103 te bazezi pe oricare dintre ele, care \u00ee\u021bi place cel mai mult.<\/p>\n

<\/p>\n

Pe baza c\u00e2mpurilor men\u021bionate mai sus, se poate evalua num\u0103rul de inserturi, update-uri \u0219i \u0219tergeri. Exemplul de dashboard pe care l-am folosit folose\u0219te exact aceste c\u00e2mpuri pentru evaluarea caracteristicilor sarcinii de lucru. De aceea, putem s\u0103 ne baz\u0103m \u0219i pe ele. Dar trebuie s\u0103 \u021binem cont c\u0103 acestea sunt tuple-uri, nu byte-uri, a\u0219a c\u0103 nu putem lua \u0219i face asta \u00een byte-uri.<\/p>\n

<\/p>\n

Pe baza acestor date putem construi a\u0219a-numitele tabele TopN. De exemplu, Top-5, Top-10. \u0218i putem monitoriza acele tabele \u201efierbin\u021bi\u201d care sunt utilizate mai mult dec\u00e2t altele. De exemplu, 5 tabele \u201efierbin\u021bi\u201d pentru inser\u021bii. \u0218i pe baza acestor tabele TopN evalu\u0103m sarcina noastr\u0103 de lucru \u0219i putem evalua v\u00e2rfurile de sarcin\u0103 de lucru dup\u0103 diverse lans\u0103ri, actualiz\u0103ri \u0219i desf\u0103\u0219ur\u0103ri. <\/p>\n

<\/p>\n

De asemenea, este important s\u0103 evalu\u0103m dimensiunile tabelului, deoarece uneori dezvoltatorii lanseaz\u0103 o nou\u0103 caracteristic\u0103 \u0219i tabelele \u00eencep s\u0103 creasc\u0103 \u00een dimensiuni mari, deoarece decidem s\u0103 ad\u0103ug\u0103m un volum suplimentar de date, dar nu am prev\u0103zut cum va afecta acest lucru dimensiunea bazei de date. Astfel de cazuri ne surprind uneori. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u0218i acum o \u00eentrebare pentru voi. Ce \u00eentrebare v\u0103 vine \u00een minte atunci c\u00e2nd observa\u021bi o \u00eenc\u0103rcare pe serverul cu baza de date? Care este urm\u0103toarea \u00eentrebare pe care o ave\u021bi? <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Dar, de fapt, urm\u0103toarea \u00eentrebare este. Ce interog\u0103ri genereaz\u0103 aceast\u0103 \u00eenc\u0103rcare? Adic\u0103, nu este interesant s\u0103 vedem procesele care genereaz\u0103 aceast\u0103 \u00eenc\u0103rcare. Este clar c\u0103 dac\u0103 exist\u0103 un host cu baza de date, atunci acolo este lansat\u0103 baza de date \u0219i e normal ca doar bazele de date s\u0103 consume resurse. Dac\u0103 deschidem Top, vom vedea acolo o list\u0103 de procese \u00een PostgreSQL care fac ceva. Din Top nu va fi clar ce fac. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Prin urmare, trebuie s\u0103 identific\u0103m acele interog\u0103ri care genereaz\u0103 cea mai mare \u00eenc\u0103rcare, deoarece optimizarea interog\u0103rilor, de regul\u0103, ofer\u0103 mai mult profit dec\u00e2t optimizarea configura\u021biei PostgreSQL sau a sistemului de operare, sau chiar optimizarea hardware-ului. Pot s\u0103 spun c\u0103 este \u00een jur de 80-85-90%. \u0218i se face mult mai repede. Este mai rapid s\u0103 corect\u0103m o interogare dec\u00e2t s\u0103 corect\u0103m configura\u021bia, s\u0103 planific\u0103m o repornire, mai ales dac\u0103 baza nu poate fi repornit\u0103 sau dac\u0103 trebuie s\u0103 ad\u0103ug\u0103m hardware. Este mai simplu s\u0103 rescriem o interogare sau s\u0103 ad\u0103ug\u0103m un index pentru a ob\u021bine deja un rezultat mai bun de la acea interogare. <\/p>\n

<\/p>\n

\"Fundamentele
\nPrin urmare, trebuie s\u0103 monitoriz\u0103m interog\u0103rile \u0219i adecvarea lor. S\u0103 lu\u0103m un alt exemplu de monitorizare. \u0218i aici pare s\u0103 existe o monitorizare excelent\u0103. Exist\u0103 informa\u021bii despre replicare, informa\u021bii despre l\u0103\u021bimea de band\u0103, blocaje, utilizarea resurselor. Totul este perfect, dar nu exist\u0103 informa\u021bii despre interog\u0103ri. Nu este clar ce interog\u0103ri sunt executate \u00een baza noastr\u0103 de date, c\u00e2t dureaz\u0103 executarea lor, c\u00e2te astfel de interog\u0103ri sunt. Avem nevoie ca monitorizarea s\u0103 ne ofere \u00eentotdeauna aceste informa\u021bii. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u0218i pentru a ob\u021bine aceste informa\u021bii, putem utiliza modulul pg_stat_statements. Pe baza acestuia, putem construi cele mai diferite grafice. De exemplu, putem ob\u021bine informa\u021bii despre cele mai frecvente interog\u0103ri, adic\u0103 despre cele care sunt executate cel mai des. Da, dup\u0103 deploy-uri este de asemenea foarte util s\u0103 ne uit\u0103m la el \u0219i s\u0103 \u00een\u021belegem dac\u0103 exist\u0103 o cre\u0219tere a interog\u0103rilor. <\/p>\n

<\/p>\n

Putem monitoriza cele mai \u00eendelungate interog\u0103ri, adic\u0103 acelea care dureaz\u0103 cel mai mult. Ele lucreaz\u0103 pe procesor, consum\u0103 I\/O. Putem evalua aceasta \u0219i pe baza c\u00e2mpurilor total_time, mean_time, blk_write_time \u0219i blk_read_time. <\/p>\n

<\/p>\n

Putem evalua \u0219i monitoriza cele mai grele interog\u0103ri \u00een ceea ce prive\u0219te utilizarea resurselor, cele care citesc de pe disc, care lucreaz\u0103 cu memorie sau, din contr\u0103, genereaz\u0103 o anumit\u0103 sarcin\u0103 de scriere.<\/p>\n

<\/p>\n

Putem evalua cele mai generoase interog\u0103ri. Acestea sunt cele care returneaz\u0103 un num\u0103r mare de r\u00e2nduri. De exemplu, poate fi o interogare unde s-a uitat s\u0103 se pun\u0103 un limit. \u0218i pur \u0219i simplu returneaz\u0103 tot con\u021binutul tabelului sau al interog\u0103rilor din tabelele solicitate.<\/p>\n

<\/p>\n

De asemenea, putem monitoriza interog\u0103rile care folosesc fi\u0219iere temporare sau tabele temporare. <\/p>\n

<\/p>\n

\"Fundamentele
\n\u0218i ne-au mai r\u0103mas procesele de fundal. Procesele de fundal sunt \u00een primul r\u00e2nd checkpoint-urile sau, cum mai sunt numite, punctele de control, autovacuum-ul \u0219i replicarea. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Un alt exemplu de monitorizare. Exist\u0103 tab-ul Maintenance \u00een st\u00e2nga, ne mut\u0103m pe el \u0219i sper\u0103m s\u0103 vedem ceva util. Dar aici este doar timpul de func\u021bionare al vacum-ului \u0219i colect\u0103rii statisticilor, nimic mai mult. Aceasta este o informa\u021bie foarte s\u0103r\u0103c\u0103cioas\u0103, a\u0219a c\u0103 trebuie s\u0103 avem \u00eentotdeauna informa\u021bii despre modul \u00een care func\u021bioneaz\u0103 procesele de fundal \u00een baza noastr\u0103 de date \u0219i dac\u0103 nu exist\u0103 probleme din cauza activit\u0103\u021bii lor. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Atunci c\u00e2nd examin\u0103m punctele de control, trebuie s\u0103 ne amintim c\u0103 punctele de control resetau paginile \u201emurdare\u201d din zona de memorie shard-at\u0103 pe disc, apoi creeaz\u0103 un punct de control. \u0218i acest punct de control poate fi folosit mai departe ca un fel de loc la recuperare, \u00een cazul \u00een care PostgreSQL s-a \u00eencheiat brusc. <\/p>\n

<\/p>\n

A\u0219adar, pentru a salva toate paginile \u201emurdare\u201d pe disc, este necesar s\u0103 se efectueze un anumit volum de scriere. \u0218i, de obicei, pe sistemele cu o memorie mare \u2013 acest volum este foarte mare. Iar dac\u0103 avem checkpoint-uri efectuate foarte des \u00eentr-un interval scurt, atunci performan\u021ba discului va sc\u0103dea semnificativ. Iar cererile clien\u021bilor vor suferi din cauza lipsei de resurse. Ele vor lupta pentru resurse \u0219i le va lipsi performan\u021ba. <\/p>\n

<\/p>\n

Astfel, prin pg_stat_bgwriter, putem monitoriza num\u0103rul de checkpoint-uri care au loc \u00een func\u021bie de c\u00e2mpurile specificate. \u0218i dac\u0103 avem, \u00eentr-un anumit interval de timp (de 10-15-20 de minute, de jum\u0103tate de or\u0103), foarte multe checkpoint-uri, de exemplu, 3-4-5, aceasta poate fi deja o problem\u0103. \u0218i trebuie s\u0103 ne uit\u0103m \u00een baza de date, s\u0103 verific\u0103m configura\u021bia, pentru a \u00een\u021belege ce cauzeaz\u0103 un astfel de num\u0103r mare de checkpoint-uri. Poate c\u0103 se efectueaz\u0103 o scriere mare. Pe baza \u00eenc\u0103rc\u0103rii de lucru putem evalua deja, pentru c\u0103 graficele de \u00eenc\u0103rcare sunt deja ad\u0103ugate. Putem ajusta deja parametrii pentru checkpoint-uri \u0219i s\u0103 facem astfel \u00eenc\u00e2t acestea s\u0103 nu afecteze semnificativ performan\u021ba cererilor.<\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Revin din nou la autovacuum, pentru c\u0103 aceasta este o problem\u0103, a\u0219a cum am mai spus, care poate afecta semnificativ at\u00e2t performan\u021ba discurilor, c\u00e2t \u0219i a cererilor; de aceea este \u00eentotdeauna important s\u0103 evalu\u0103m num\u0103rul de autovacuum-uri. <\/p>\n

<\/p>\n

Num\u0103rul de lucr\u0103tori autovacuum \u00een baza de date este limitat. \u00cen mod implicit, exist\u0103 trei, a\u0219adar, dac\u0103 avem tot timpul trei lucr\u0103tori activi \u00een baz\u0103, \u00eenseamn\u0103 c\u0103 autovacuum-ul nu este configurat corespunz\u0103tor, este necesar s\u0103 cre\u0219tem limitele, s\u0103 revizuim set\u0103rile autovacuum \u0219i s\u0103 intervenim \u00een configura\u021bie.
\nEste important s\u0103 evalu\u0103m care dintre lucr\u0103torii de vacuum sunt activi. Fie c\u0103 este vorba despre un vacuum lansat de un utilizator, un DBA care a venit \u0219i a lansat manual un anumit vacuum, ceea ce a generat o \u00eenc\u0103rcare. A ap\u0103rut o problem\u0103. Fie c\u0103 este vorba despre num\u0103rul vacuum-urilor care descompun contorul de tranzac\u021bii. Pentru unele versiuni PostgreSQL \u2013 aceste vacuum-uri sunt foarte solicitante. \u0218i ele pot afecta semnificativ performan\u021ba, deoarece citesc \u00eentreaga tabel\u0103 \u00een \u00eentregime, scaneaz\u0103 toate blocurile din acea tabel\u0103. <\/p>\n

<\/p>\n

\u0218i, desigur, durata vacuumului. Dac\u0103 avem vacuumuri lungi, care func\u021bioneaz\u0103 pentru o perioad\u0103 \u00eendelungat\u0103, atunci este cazul s\u0103 ne reorient\u0103m aten\u021bia asupra configura\u021biei vacuumului \u0219i, poate, s\u0103 ne revizuim set\u0103rile. Deoarece poate ap\u0103rea situa\u021bia \u00een care vacuumul lucreaz\u0103 pe o tabel\u0103 o perioad\u0103 lung\u0103 de timp (3-4 ore), dar \u00een acel interval de timp, pe tabel\u0103 au acumulat din nou un volum mare de linii moarte. \u0218i de \u00eendat\u0103 ce vacuumul se termin\u0103, trebuie din nou s\u0103 fac\u0103 vacuum pe aceast\u0103 tabel\u0103. \u0218i ajungem la o situa\u021bie de vacuum infinit. \u00centr-un astfel de caz, vacuumul nu \u00ee\u0219i \u00eendepline\u0219te func\u021bia, iar tabelele \u00eencep treptat s\u0103 se umfle \u00een dimensiuni, de\u0219i volumul de date utile r\u0103m\u00e2ne acela\u0219i. A\u0219adar, \u00een cazul vacuumurilor lungi, \u00eentotdeauna ne uit\u0103m la configura\u021bie \u0219i \u00eencerc\u0103m s\u0103 o optimiz\u0103m, dar astfel \u00eenc\u00e2t s\u0103 nu fie afectat\u0103 performan\u021ba cererilor clien\u021bilor. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u00cen prezent, aproape nu exist\u0103 instal\u0103ri PostgreSQL f\u0103r\u0103 replicare \u00een flux. Replicarea este procesul de transfer al datelor de la master la replic\u0103.<\/p>\n

<\/p>\n

Replicarea \u00een PostgreSQL se desf\u0103\u0219oar\u0103 prin jurnalul de tranzac\u021bii. Masterul genereaz\u0103 jurnalul de tranzac\u021bii. Acest jurnal de tranzac\u021bii este transmis prin conexiune de re\u021bea la replic\u0103, iar mai departe, pe replic\u0103, acesta se reproduce. Totul este simplu. <\/p>\n

<\/p>\n

Prin urmare, pentru monitorizarea \u00eent\u00e2rzierii replic\u0103rii se folose\u0219te vizualizarea pg_stat_replication. Dar nu este chiar simplu. \u00cen versiunea 10, vizualizarea a suferit c\u00e2teva modific\u0103ri. \u00cen primul r\u00e2nd, o parte din c\u00e2mpuri a fost redenumit\u0103. \u0218i s-au ad\u0103ugat c\u00e2teva c\u00e2mpuri. \u00cen versiunea 10 au ap\u0103rut c\u00e2mpuri care permit evaluarea \u00eent\u00e2rzierii replic\u0103rii \u00een secunde. Este foarte convenabil. P\u00e2n\u0103 la versiunea 10, existase posibilitatea de a evalua \u00eent\u00e2rzierea replic\u0103rii \u00een octe\u021bi. Aceast\u0103 posibilitate a r\u0103mas \u0219i \u00een versiunea 10, adic\u0103 pute\u021bi alege ce v\u0103 este mai convenabil - s\u0103 evalua\u021bi \u00eent\u00e2rzierea \u00een octe\u021bi sau \u00een secunde. Multe persoane fac ambele.<\/p>\n

<\/p>\n

Dar, totu\u0219i, pentru a evalua \u00eent\u00e2rzierea replic\u0103rii, trebuie s\u0103 cunoa\u0219tem pozi\u021bia jurnalului \u00een tranzac\u021bie. \u0218i aceste pozi\u021bii ale jurnalului de tranzac\u021bii sunt tocmai \u00een vizualizarea pg_stat_replication. A\u0219adar, putem folosi func\u021bia pg_xlog_location_diff() pentru a lua dou\u0103 puncte din jurnalul de tranzac\u021bii. S\u0103 calcul\u0103m \u00eentre ele delta \u0219i s\u0103 ob\u021binem \u00eent\u00e2rziera replic\u0103rii \u00een octe\u021bi. Este foarte convenabil \u0219i simplu. <\/p>\n

<\/p>\n

\u00cen versiunea 10, aceast\u0103 func\u021bie a fost redenumit\u0103 \u00een pg_wal_lsn_diff(). Practic, \u00een toate func\u021biile, vizualiz\u0103rile, utilit\u0103rile unde a fost \u00eent\u00e2lnit cuv\u00e2ntul \u201exlog\u201d, acesta a fost \u00eenlocuit cu valoarea \u201ewal\u201d. Acest lucru se aplic\u0103 at\u00e2t vizualiz\u0103rilor, c\u00e2t \u0219i func\u021biilor. Este o astfel de inova\u021bie. <\/p>\n

<\/p>\n

De asemenea, \u00een versiunea 10 au fost ad\u0103ugate r\u00e2nduri care arat\u0103 \u00een mod specific laten\u021ba. Este vorba despre write lag, flush lag, replay lag. Adic\u0103 aceste aspecte trebuie monitorizate. Dac\u0103 observ\u0103m c\u0103 exist\u0103 o laten\u021b\u0103 a replic\u0103rii, trebuie s\u0103 investig\u0103m de ce a ap\u0103rut, de unde provine \u0219i s\u0103 remediem problema. <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

\u00cen ceea ce prive\u0219te metricele sistemului, aproape totul este \u00een ordine. C\u00e2nd se dezvolt\u0103 orice monitorizare, aceasta \u00eencepe cu metricele sistemului. Este vorba despre utilizarea CPU-ului, memoriei, swap-ului, re\u021belei \u0219i discului. Cu toate acestea, multe dintre parametrii lipsesc implicit. <\/p>\n

<\/p>\n

Dac\u0103 utilizarea procesorului este \u00een regul\u0103, atunci exist\u0103 probleme cu utilizarea discului. De obicei, dezvoltatorii de monitoriz\u0103ri adaug\u0103 informa\u021bii despre l\u0103\u021bimea de band\u0103. Aceasta poate fi \u00een IOPS sau bytes. Dar uit\u0103 de laten\u021b\u0103 \u0219i utilizarea dispozitivelor de stocare. Acestea sunt parametrii mai importan\u021bi, care permit evaluarea gradului de \u00eenc\u0103rcare a discurilor \u0219i gradul \u00een care acestea \u00eent\u00e2mpin\u0103 probleme. Dac\u0103 avem o laten\u021b\u0103 mare, \u00eenseamn\u0103 c\u0103 exist\u0103 probleme cu discurile. Dac\u0103 avem o utilizare mare, \u00eenseamn\u0103 c\u0103 discurile nu fac fa\u021b\u0103.<\/strong> Acestea sunt caracteristici de calitate mai \u00eenalt\u0103 dec\u00e2t l\u0103\u021bimea de band\u0103.<\/p>\n

<\/p>\n

Av\u00e2nd \u00een vedere c\u0103 aceste statistici pot fi ob\u021binute \u0219i din sistemul de fi\u0219iere \/proc, a\u0219a cum se face pentru utilizarea procesorului. Nu \u0219tiu de ce aceste informa\u021bii nu sunt incluse \u00een monitoriz\u0103ri. Cu toate acestea, este important s\u0103 ai aceste informa\u021bii \u00een monitorizarea ta.<\/strong> <\/p>\n

<\/p>\n

La fel se aplic\u0103 \u0219i pentru interfe\u021bele de re\u021bea. Exist\u0103 informa\u021bii despre l\u0103\u021bimea de band\u0103 a re\u021belei \u00een pachete, \u00een bytes, dar cu toate acestea nu exist\u0103 informa\u021bii despre laten\u021b\u0103 \u0219i nu exist\u0103 informa\u021bii despre utilizare, de\u0219i acestea sunt informa\u021bii utile.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentele<\/p>\n

<\/p>\n

Toate monitoriz\u0103rile au dezavantaje. \u0218i orice monitorizare ai alege, ea va comporta \u00eentotdeauna anumite neconformit\u0103\u021bi cu diverse criterii. Totu\u0219i, acestea se dezvolt\u0103, se adaug\u0103 noi caracteristici, a\u0219a c\u0103 alege ceva \u0219i \u00eembun\u0103t\u0103\u021be\u0219te-l. <\/p>\n

<\/p>\n

\u0218i pentru a \u00eembun\u0103t\u0103\u021bi, trebuie s\u0103 ai \u00eentotdeauna o idee despre ce \u00eenseamn\u0103 statisticile furnizate \u0219i cum pot fi utilizate pentru a rezolva probleme. <\/p>\n

<\/p>\n

\u0218i c\u00e2teva puncte cheie:<\/p>\n

<\/p>\n