{"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\/et\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"PostgreSQL j\u00e4lgimise p\u00f5hit\u00f5ed. Aleksei Lesovski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 \u0438\u0437 Data Egret "\u041e\u0441\u043d\u043e\u0432\u044b \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 PostgreSQL"<\/strong><\/p>\n

<\/p>\n

\u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041b\u0435\u0441\u043e\u0432\u0441\u043a\u0438\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043a\u043b\u044e\u0447\u0435\u0432\u044b\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u0430\u0445 \u043f\u043e\u0441\u0442\u0433\u0440\u0435\u0441\u043e\u0432\u043e\u0439 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u043a\u0438, \u0447\u0442\u043e \u043e\u043d\u0438 \u043e\u0437\u043d\u0430\u0447\u0430\u044e\u0442, \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u043f\u0440\u0438\u0441\u0443\u0442\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435; \u043e \u0442\u043e\u043c, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0444\u0438\u043a\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u0442\u044c \u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0435, \u043a\u0430\u043a \u0438\u0445 \u0434\u043e\u0431\u0430\u0432\u0438\u0442\u044c \u0438 \u043a\u0430\u043a \u0438\u043d\u0442\u0435\u0440\u043f\u0440\u0435\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c. \u0414\u043e\u043a\u043b\u0430\u0434 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445, \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430\u043c \u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0435\u043d \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433 Postgres’\u0430.<\/p>\n

\n

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

\"PostgreSQL<\/p>\n

<\/p>\n

Minu nimi on Aleksei Lesovski, esindan ettev\u00f5tet Data Egret. <\/p>\n

<\/p>\n

Natuke s\u00f5nu enda kohta. Alustasin kunagi ammu s\u00fcsteemiadministraatorina. <\/p>\n

<\/p>\n

Haldasin erinevaid Linuxe, tegelesin erinevate Linuxiga seotud asjadega, st virtualiseerimise, j\u00e4lgimisega, t\u00f6\u00f6tasin proksiga jne. Kuid mingil hetkel hakkasin rohkem tegelema andmebaasidega, PostgreSQLiga. See meeldis mulle v\u00e4ga. Ja mingil hetkel hakkasin PostgreSQLile p\u00fchendama oma t\u00f6\u00f6ajast suurema osa. Nii ma slowly muutusin PostgreSQL DBA-ks.<\/p>\n

<\/p>\n

Ja on olnud minu karj\u00e4\u00e4ri v\u00e4ltel pidev huvi statistika, j\u00e4lgimise ja telemeetriaga seotud teemade \u00fcle. Kui olin s\u00fcsteemiadministraator, tegelesin ma Zabbixiga v\u00e4ga p\u00f5hjalikult. Kirjutasin ka v\u00e4ikese komplekti skripte, mis zabbix-extensions<\/a><\/noindex>. See oli oma ajal \u00fcsna populaarne. Seal sai j\u00e4lgida v\u00e4ga erinevaid olulisi asju, mitte ainult Linuxit, vaid ka muid komponente.<\/p>\n

<\/p>\n

Praegu tegeleme PostgreSQL-iga. Kirjutan juba midagi muud, mis v\u00f5imaldab t\u00f6\u00f6tada PostgreSQL-i statistikaga. Selle nimi on pgCenter<\/a><\/noindex> (artikkel Habrisse \u2014 PostgreSQL statistika ilma n\u00e4rvide ja pingeteta<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

L\u00fchike sissejuhatus. Millised on meie tellijate ja klientide olukorrad? Juhtunud on m\u00f5ni probleem, mis on seotud andmebaasiga. Ja kui andmebaas on juba taastatud, tuleb osakonnajuhataja v\u00f5i arenduse juhataja ja \u00fctleb: \u00abS\u00f5brad, peaksime andmebaasi j\u00e4lgima, sest midagi halba juhtus ja tulevikus ei tohi sellist asja juhtuda\u00bb. Siit algab huvitav protsess j\u00e4lgimiss\u00fcsteemi valimise v\u00f5i olemasoleva j\u00e4lgimiss\u00fcsteemi kohandamise osas, et saaksime j\u00e4lgida oma andmebaasi \u2013 PostgreSQL, MySQL v\u00f5i m\u00f5ni muu. Ja kolleegid hakkavad \u00fcksteisele soovitama: \u00abOlen kuulnud, et on olemas selline andmebaas. Kasutame seda\u00bb. Kolleegid hakkavad omavahel vaidlema. Ja l\u00f5ppkokkuv\u00f5ttes selgub, et valime m\u00f5ne andmebaasi, aga PostgreSQL j\u00e4lgimine on selles \u00fcsna n\u00f5rk ja peame ikkagi midagi kohandama. Korjame GitHubist m\u00f5ningaid hoidlaid, kloonime neid, kohandame skripte, seadistame neid veelgi. Ja l\u00f5puks osutub see k\u00e4sit\u00f6\u00f6ks. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Seet\u00f5ttu p\u00fc\u00fcan selles ettekandes anda m\u00f5ned teadmised, kuidas valida monitooring mitte ainult PostgreSQL-i, vaid ka teiste andmebaaside jaoks. Samuti pakun teadmisi, mis v\u00f5imaldavad teil t\u00e4iustada oma monitooringut, et saada sellest t\u00f5eliselt kasu, v\u00f5imaldades oma andmebaasi j\u00e4lgida ja ennetada v\u00f5imalikke avariisid, mis v\u00f5ivad tekkida. <\/p>\n

<\/p>\n

Ja need ideed, mis ettekandes k\u00e4sitleme, on otse t\u00f5lgendatavad igasuguste andmebaaside, olgu need relatsioonilised andmebaasid v\u00f5i noSQL, jaoks. Seet\u00f5ttu ei k\u00e4sitle me siin ainult PostgreSQL-i, vaid pakume ka palju retsepte, kuidas seda PostgreSQL-is rakendada. Olemas on p\u00e4ringute n\u00e4ited, n\u00e4ited entiteetidest, mis on PostgreSQL-is monitooringuks olemas. Ja kui teie andmebaasis on sarnaseid komponente, mida saab monitooringusse lisada, saate neid ka kohandada ja see on hea.<\/p>\n

<\/p>\n

\"PostgreSQLEttekandes ma ei hakka
\nr\u00e4\u00e4kima sellest, kuidas saata ja salvestada m\u00f5\u00f5dikuid. Ma ei r\u00e4\u00e4gi midagi andmete j\u00e4rel t\u00f6\u00f6tlemisest ja nende kasutajale esitamisest. Samuti ei k\u00e4sitle ma midagi h\u00e4ires\u00fcsteemidest.
\nKuna ma r\u00e4\u00e4gin, n\u00e4itan ma erinevaid olemasolevaid j\u00e4lgimise ekraanipilte ja kritiseerime neid. Siiski p\u00fc\u00fcan ma mitte nimetada br\u00e4nde, et mitte luua reklaame ega vastureklaame nendele toodetele. Seega k\u00f5ik kokkusattumised on juhuslikud ja j\u00e4\u00e4vad teie fantaasiale.
\n\"PostgreSQL
\nAlustame sellest, mis on j\u00e4lgimine. J\u00e4lgimine on v\u00e4ga oluline asi, mis peab olema olemas. Seda m\u00f5istavad k\u00f5ik. Kuid samas ei kuulu j\u00e4lgimine \u00e4riproduktsi hulka ega m\u00f5juta otseselt ettev\u00f5tte kasumit, mist\u00f5ttu p\u00f6\u00f6ratakse j\u00e4lgimisele alati t\u00e4helepanu alles siis, kui aega j\u00e4\u00e4b. Kui meil on aega, tegeleme j\u00e4lgimisega, kui aega ei ole, siis OK, paneme selle backlogi ja tuleb kunagi tagasi nende \u00fclesannete juurde. <\/p>\n

<\/p>\n

Seet\u00f5ttu on meie praktikas, kui me tuleme klientide juurde, j\u00e4lgimine sageli alahinnatud ja tal puuduvad huvitavad asjad, mis aitaksid meil andmebaasiga paremini t\u00f6\u00f6tada. Seep\u00e4rast tuleb j\u00e4lgimist alati t\u00e4iustada. <\/p>\n

<\/p>\n

Andmebaasid on keerulised asjad, mida tuleb ka j\u00e4lgida, sest andmebaasid on teabehoidlad. Teave on ettev\u00f5tte jaoks v\u00e4ga oluline ja seda ei tohi mingil juhul kaotada. Samas on andmebaasid v\u00e4ga keerulised tarkvara t\u00fckid, mis koosnevad paljusid komponente. Paljusid neist komponentidest tuleb j\u00e4lgida. <\/p>\n

<\/p>\n

\"PostgreSQLKui r\u00e4\u00e4gime konkreetselt PostgreSQL-ist, siis seda v\u00f5ib kujutada nagu skeemi, mis koosneb paljusid komponente, mis omavahel suhtlevad. Samuti on PostgreSQL-is nn Stats Collector all\u00fcksus, mis v\u00f5imaldab koguda statistikat nende all\u00fcksuste t\u00f6\u00f6 kohta ja pakkuda administraatorile v\u00f5i kasutajale liidest, mille abil nad saavad seda statistikat vaadata. <\/p>\n

<\/p>\n

See statistika on esitatud teatud funktsioonide ja vaadete (view) kogumina. Neid v\u00f5ib ka tabeliteks nimetada. See t\u00e4hendab, et tavap\u00e4rase psql kliendi kaudu saate \u00fchendust luua andmebaasiga, teha nende funktsioonide ja vaadete suhtes valiku ning saada juba konkreetseid numbreid PostgreSQL all\u00fcksuste t\u00f6\u00f6 kohta. <\/p>\n

<\/p>\n

Saate need numbrid lisada oma lemmik j\u00e4lgimiss\u00fcsteemi, joonistada graafikud, lisada funktsioone ja saada pikaajalist anal\u00fc\u00fcsi. <\/p>\n

<\/p>\n

Kuid sel teema ma ei k\u00e4sitle k\u00f5iki neid funktsioone, sest see v\u00f5iks v\u00f5tta terve p\u00e4eva. R\u00e4\u00e4gin vaid paarist-kolmest-neljast asjast ja sellest, kuidas need aitavad j\u00e4lgimist paremaks muuta.
\n\"PostgreSQL
\nJa kui r\u00e4\u00e4kida andmebaasi j\u00e4lgimisest, siis mida tuleb j\u00e4lgida? Esiteks tuleb j\u00e4lgida k\u00e4ttesaadavust, sest andmebaas on teenus, mis pakkub klientidele juurdep\u00e4\u00e4su andmetele, ning peame j\u00e4lgima selle k\u00e4ttesaadavust, samuti m\u00f5ningaid selle kvaliteedi- ja kvantitatiive omadusi. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Samuti tuleb j\u00e4lgida kliente, kes meie andmebaasiga \u00fchendust v\u00f5tavad, sest nad v\u00f5ivad olla nii normaalsed kui ka kahjulikud kliendid, kes v\u00f5ivad andmebaasile kahju teha. Neid tuleb samuti j\u00e4lgida ja nende tegevust j\u00e4lgida.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kui kliendid liituvad andmebaasiga, on selge, et nad hakkavad t\u00f6\u00f6tama meie andmete kallal, seega peame j\u00e4lgima ka seda, kuidas kliendid andmetega t\u00f6\u00f6tavad: milliste tabelitega, v\u00e4hemal m\u00e4\u00e4ral milliste indeksitega. See t\u00e4hendab, et me peame hindama koormust, mida meie kliendid tekitavad.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Aga ka koormus koosneb muidugi p\u00e4ringutest. Rakendused \u00fchenduvad andmebaasi, p\u00f6\u00f6rdudes andmete poole p\u00e4ringute kaudu, seega on oluline hinnata, millised p\u00e4ringud meil andmebaasis on, j\u00e4lgida nende adekvaatsust, et need ei oleks halvasti kirjutatud ning et m\u00f5ned valikud tuleks \u00fcmber kirjutada ja muuta nii, et need t\u00f6\u00f6taksid kiiremini ja parema tootlikkusega. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja kui me r\u00e4\u00e4gime andmebaasist, siis andmebaas \u2013 see on alati taustaprotsessid. Taustaprotsessid aitavad hoida andmebaasi j\u00f5udlust heas seisundis, seet\u00f5ttu vajavad nad oma t\u00f6\u00f6ks teatud hulga ressursse. Samuti v\u00f5ivad nad kattuda kliendi p\u00e4ringute ressurssidega, seet\u00f5ttu v\u00f5ib taustaprotsesside ahne t\u00f6\u00f6 otseselt m\u00f5jutada kliendi p\u00e4ringute j\u00f5udlust. Seet\u00f5ttu tuleb neid samuti j\u00e4lgida ja j\u00e4lgida, et taustaprotsesside osas ei tekiks mingisuguseid ebat\u00e4psusi. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja k\u00f5ik see, mis puudutab andmebaasi j\u00e4lgimist, j\u00e4\u00e4b s\u00fcsteemse metrikaga seotuks. Kuid arvestades, et suurem osa meie infrastruktuurist liigub pilve, j\u00e4\u00e4vad \u00fcksiku hosti s\u00fcsteemsed metrikad alati teisej\u00e4rgulisteks. Kuid andmebaasides on need endiselt olulised ja s\u00fcsteemsete metrikate j\u00e4lgimine on muidugi samuti vajalik. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

S\u00fcsteemsete metrikatega on enam-v\u00e4hem k\u00f5ik h\u00e4sti, k\u00f5ik t\u00e4nap\u00e4eva j\u00e4lgimisse s\u00fcsteemid toetavad neid meetrikaid, kuid \u00fcldiselt on ikka veel m\u00f5ningaid komponente puudu ning teatud asju tuleb lisada. Nendest r\u00e4\u00e4gin ka, m\u00f5ned slaidid on nende kohta. <\/p>\n

<\/p>\n

\"PostgreSQL
\nEsimese plaani punkt on k\u00e4ttesaadavus. Mis on k\u00e4ttesaadavus? K\u00e4ttesaadavus minu m\u00f5istes t\u00e4hendab, et andmebaas suudab teenindada \u00fchendusi, st andmebaas on \u00fcles t\u00f5stetud ja see aktsepteerib \u00fchendusi klientidelt. Ja seda k\u00e4ttesaadavust saab hinnata mitmete omadustega. Need omadused on v\u00e4ga mugav tuua juhtpaneelidele. <\/p>\n

<\/p>\n

\"PostgreSQL
\nK\u00f5ik teavad, mis on juhtpaneelid. See on siis, kui sa heidad \u00fche pilgu ekraanile, kus on koondatud vajalik teave. Ja sa saad kohe m\u00e4\u00e4rata \u2013 kas andmebaasis on probleem v\u00f5i mitte.
\nSeega tuleb andmebaasi k\u00e4ttesaadavus ja teised v\u00f5tmeomadused alati tuua juhtpaneelidele, et see teave oleks k\u00e4ep\u00e4rast, alati l\u00e4hedal. M\u00f5ned t\u00e4iendavad \u00fcksikasjad, mis aitavad \u00f5nnetuste uurimisel, tuleks juba tuua sekundaarsetele juhtpaneelidele v\u00f5i peita drilldown-linkidesse, mis viivad v\u00e4liste j\u00e4lgimisse s\u00fcsteemidesse. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dcks tuntud seire s\u00fcsteemide n\u00e4ide. See on t\u00f5eliselt vinged seire s\u00fcsteem. See kogub palju andmeid, kuid minu arvates on sellel kummaline arusaam juhtpaneelidest. Seal on link \"loo juhtpaneel\". Kuid kui te loote juhtpaneeli, siis loote te teatud loendi, mis koosneb kahest veerust, teatud graafikute loendi. Ja kui peate midagi vaatama, hakkate hiirega kl\u00f5psima, kerima, otsima vajalikku graafikut. Sellele kulub aega, st juhtpaneele, nagu selliseid, ei ole. On ainult graafikute loendid.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Mida tuleks nendele juhtpaneelidele lisada? V\u00f5ib alustada sellisest omadusest nagu reageerimisaeg. PostgreSQL-is on vaade pg_stat_statements. Vaikimisi on see keelatud, kuid see on \u00fcks t\u00e4htsamaid s\u00fcsteemivaateid, mida tuleb alati lubada ja kasutada. See salvestab teavet k\u00f5ikide toimingus olevate p\u00e4ringute kohta, mis andmebaasis on t\u00e4idetud. <\/p>\n

<\/p>\n

\u0421\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043e\u0442\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u0441\u044f \u043e\u0442 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u0432\u0437\u044f\u0442\u044c \u0441\u0443\u043c\u043c\u0430\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0432\u0441\u0435\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0438 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c \u043d\u0430 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u044b\u0448\u0435\u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043d\u043d\u044b\u0445 \u043f\u043e\u043b\u0435\u0439. \u041d\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u0430\u044f \u0441\u0440\u0435\u0434\u043d\u044f\u044f \u0442\u0435\u043c\u043f\u0435\u0440\u0430\u0442\u0443\u0440\u0430 \u043f\u043e \u0431\u043e\u043b\u044c\u043d\u0438\u0446\u0435. \u041c\u044b \u043c\u043e\u0436\u0435\u043c \u043e\u0442\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u0441\u044f \u043e\u0442 \u0434\u0440\u0443\u0433\u0438\u0445 \u043f\u043e\u043b\u0435\u0439 \u2013 \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0435 \u0438 \u043c\u0435\u0434\u0438\u0430\u043d\u043d\u043e\u0435. \u0418 \u0434\u0430\u0436\u0435 \u043c\u043e\u0436\u0435\u043c \u0441\u0442\u0440\u043e\u0438\u0442\u044c \u043f\u0435\u0440\u0446\u0435\u043d\u0442\u0438\u043b\u0438, \u0432 PostgreSQL \u0435\u0441\u0442\u044c \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u0434\u043b\u044f \u044d\u0442\u043e\u0433\u043e. \u0418 \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a\u0430\u043a\u0438\u0435-\u0442\u043e \u0446\u0438\u0444\u0440\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0437\u0443\u044e\u0442 \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u043a\u043b\u0438\u043a\u0430 \u043d\u0430\u0448\u0435\u0439 \u0431\u0430\u0437\u044b \u043f\u043e \u0443\u0436\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u043d\u044b\u043c \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u043c, \u0442. \u0435. \u043c\u044b \u043d\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u043c \u0444\u0435\u0439\u043a\u043e\u0432\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 ‘select 1’\u00a0\u0438 \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u043a\u043b\u0438\u043a\u0430, \u0430 \u043c\u044b \u0430\u043d\u0430\u043b\u0438\u0437\u0438\u0440\u0443\u0435\u043c \u0432\u0440\u0435\u043c\u044f \u043e\u0442\u0432\u0435\u0442\u043e\u0432 \u043f\u043e \u0443\u0436\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u043d\u044b\u043c \u0437\u0430\u043f\u0440\u043e\u0441\u0430\u043c \u0438 \u0440\u0438\u0441\u0443\u0435\u043c \u043b\u0438\u0431\u043e \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0446\u0438\u0444\u0440\u043e\u0439, \u043b\u0438\u0431\u043e \u0441\u0442\u0440\u043e\u0438\u043c \u043f\u043e \u043d\u0435\u0439 \u0433\u0440\u0430\u0444\u0438\u043a. <\/p>\n

<\/p>\n

Samuti on oluline j\u00e4lgida s\u00fcsteemi genereeritavate vigade arvu hetkel. Selleks saab kasutada pg_stat_database vaadet. Me j\u00e4lgime xact_rollback v\u00e4lja. See v\u00e4li n\u00e4itab mitte ainult tagasiv\u00f5tmiste arvu, mis andmebaasis toimub, vaid arvestab ka vigade arvu. \u00dctleme, et saame selle numbri meie juhtpaneelile kuvada ja j\u00e4lgida, kui palju vigu meil hetkel on. Kui vigu on palju, on see juba hea p\u00f5hjus vaadata logisid ja uurida, millised need vead on ja miks need esinevad, ning seej\u00e4rel juba uurida ja lahendada need.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Saame lisada sellise asja nagu tahhograaf. See on tehingute arv sekundis ja p\u00e4ringute arv sekundis. \u00dctleme nii, et saate neid numbreid kasutada oma andmebaasi praeguse j\u00f5udluse j\u00e4lgimiseks ja vaadata, kas on p\u00e4ringute, tehingute tippe, v\u00f5i vastupidi, andmebaas on alakoormatud, kuna m\u00f5ni taustaprogramm on v\u00e4ljas. Seda numbrit on oluline pidevalt j\u00e4lgida ja meeles pidada, et meie projekti jaoks on selline j\u00f5udlus normaalne, samas kui k\u00f5rgemad ja madalamad v\u00e4\u00e4rtused on probleemsed ja arusaamatud, seega tuleb vaadata, miks sellised numbrid.<\/p>\n

<\/p>\n

Kuna me peame hindama tehingute arvu, saame taas p\u00f6\u00f6rduda pg_stat_database vaate poole. Saame liita commit arvu ja rollback arvu ning saada tehingute arvu sekundis. <\/p>\n

<\/p>\n

K\u00f5ik m\u00f5istavad, et \u00fchte tehingusse v\u00f5ib mahtuda mitmeid p\u00e4ringuid? Seet\u00f5ttu on TPS ja QPS veidi erinevad. <\/p>\n

<\/p>\n

P\u00e4ringute arvu sekundis saab hankida pg_stat_statements'i kaudu ja lihtsalt arvutada k\u00f5igi tehtud p\u00e4ringute summa. On selge, et me v\u00f5rdleme praegust v\u00e4\u00e4rtust eelmisega, lahutame, saame delfi ja saame arvu.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Soovides on v\u00f5imalik lisada ka t\u00e4iendavaid m\u00f5\u00f5dikuid, mis aitavad hinnata meie andmebaasi k\u00e4ttesaadavust ja j\u00e4lgida, kas on olnud m\u00f5ningaid seisu aegu. <\/p>\n

<\/p>\n

\u00dcks selline m\u00f5\u00f5dik on k\u00e4ttesaadavus (uptime). Kuid PostgreSQL-i k\u00e4ttesaadavus on veidi petlik. Selgitan, miks. Kui PostgreSQL k\u00e4ivitatakse, algab k\u00e4ttesaadavuse arvestamine. Kuid kui n\u00e4iteks \u00f6\u00f6sel toimub mingi protsess ja OOM-killer l\u00f5petab PostgreSQL-i alamprotsessi, siis PostgreSQL katkestab k\u00f5igi klientide \u00fchendused, nullib jagatud m\u00e4lu ja alustab taastamist viimase kontrollpunkti p\u00f5hjal. Ja kuni see taastamine kestab, ei aktsepteeri andmebaas uusi \u00fchendusi, nii et seda olukorda saab hinnata kui seisu aega. Kuid k\u00e4ttesaadavuse arvestus ei nulli, sest see arvestab postmasteri k\u00e4ivitamisest alates esimesest hetkest. Seet\u00f5ttu v\u00f5ib selliseid olukordi \u00fcle vaadata.<\/p>\n

<\/p>\n

Samuti tuleks j\u00e4lgida t\u00fchjendajate (vacuum) arvu. Kas k\u00f5ik teavad, mis on autovacuum PostgreSQL-is? See on huvitav alams\u00fcsteem PostgreSQL-is. Selle kohta on kirjutatud palju artikleid, palju on tehtud ettekandeid. T\u00fchjendamise kohta on palju arutelusid, kuidas see peaks t\u00f6\u00f6tama. Paljud peavad seda v\u00e4ltimatuks kurjuseks. Kuid see on t\u00f5si. See on mingis m\u00f5ttes pr\u00fcgikorjamise analoog, mis puhastab aegunud rea versioonid, mis ei ole enam \u00fchegi tehingu jaoks vajalikud, ja vabastab ruumi tabelites, indeksites uute ridade jaoks. <\/p>\n

<\/p>\n

Miks on vaja seda j\u00e4lgida? Sest t\u00fchjendamine v\u00f5ib m\u00f5nikord teha suure kahju. See s\u00f6\u00f6b palju ressursse ja kliendi p\u00e4ringud kannatavad selle t\u00f5ttu. <\/p>\n

<\/p>\n

Ja seda tuleks j\u00e4lgida pg_stat_activity vaate kaudu, millest ma r\u00e4\u00e4gin j\u00e4rgmises osas. See vaade n\u00e4itab praegust aktiivsust andmebaasis. Selle aktiivsuse kaudu saame j\u00e4lgida, kui palju t\u00fchjendusi on praegu t\u00f6\u00f6s. Me saame j\u00e4lgida t\u00fchjendusi ja n\u00e4ha, et kui meie limiit on \u00fcletatud, siis see on p\u00f5hjus, miks uurida PostgreSQL seadeid ja proovida t\u00fchjendamise t\u00f6\u00f6d optimeerida. <\/p>\n

<\/p>\n

Teine PostgreSQL-i omadus on see, et PostgreSQL kannatab pikaajaliste tehingute all. Eriti tehingute, mis kauem p\u00fcsivad ja midagi ei tee. Need on nn stat idle-in-transaction. Selline tehing hoiab kinni lukud, takistab vakuumi t\u00f6\u00f6d. Ja tagaj\u00e4rjena - tabelid paisuvad, nende suurus suureneneb. Ja p\u00e4ringud, mis t\u00f6\u00f6tavad nende tabelitega, hakkavad aeglasemalt t\u00f6\u00f6tama, sest tuleb igasuguseid vanu rea versioone m\u00e4lust kettale ja tagasi eksponeerida.<\/strong> Seet\u00f5ttu tuleb j\u00e4lgida ka k\u00f5ige pikemaid tehingute ja vakuumi p\u00e4ringute aega. Ja kui me n\u00e4eme m\u00f5ningaid protsesse, mis on juba v\u00e4ga kaua t\u00f6\u00f6tanud, rohkem kui 10-20-30 minutit OLTP koormuse korral, siis tuleks neile t\u00e4helepanu p\u00f6\u00f6rata ja nad sundida l\u00f5petama v\u00f5i optimeerida rakendust, et neid ei kutsutaks esile ja nad ei ripuks nii kaua.<\/strong> Anal\u00fc\u00fctilise koormuse puhul on 10-20-30 minutit normaalne, seal on m\u00f5nikord isegi pikemaid. <\/p>\n

<\/p>\n

\"PostgreSQL
\nEdasi liigume variandi juurde, kus on \u00fchendatud kliendid. Kui oleme juba koostanud juhtpaneeli ja avaldanud seal olulised k\u00e4ttesaadavuse meetrid, v\u00f5ime sinna lisada ka t\u00e4iendavat teavet \u00fchendatud klientide kohta. <\/p>\n

<\/p>\n

Teave \u00fchendatud klientide kohta on oluline, kuna PostgreSQLi vaatepunktist on kliendid erinevad. On head kliente ja on ka halbu kliente. <\/p>\n

<\/p>\n

Lihtne n\u00e4ide. Klienti m\u00f5istan rakendusena. Rakendus on \u00fchendatud andmebaasiga ja hakkab kohe saatma sinna oma p\u00e4ringuid, andmebaas t\u00f6\u00f6tleb neid ja t\u00e4idab, tulemused saadetakse kliendile tagasi. Need on head ja \u00f5iged kliendid. <\/p>\n

<\/p>\n

On olukordi, kus klient on \u00fchendatud, hoiab \u00fchendust, kuid ei tee samas midagi. Ta on idle olekus. <\/p>\n

<\/p>\n

Kuid on ka halbu kliente. N\u00e4iteks, sama klient \u00fchendas end, avas tehingu, tegi andmebaasis midagi ja seej\u00e4rel l\u00e4ks koodi, et p\u00f6\u00f6rduda v\u00e4lise allika poole v\u00f5i andmete t\u00f6\u00f6tlemiseks. Kuid ta ei sulgenud tehingut. Ja tehing j\u00e4\u00e4b andmebaasi ja hoiab rida lukus. See on halb olukord. Ja kui \u00e4kki rakendus kuskil oma sees katkeb erandi (Exception) t\u00f5ttu, v\u00f5ib tehing j\u00e4\u00e4da avatuks v\u00e4ga pikaks ajaks. Ja see m\u00f5jutab otseselt PostgreSQL-i j\u00f5udlust. PostgreSQL t\u00f6\u00f6tab aeglasemalt. Seet\u00f5ttu on selliseid kliente oluline \u00f5igeaegselt j\u00e4lgida ja sundida nende t\u00f6\u00f6 l\u00f5petamist. Samuti tuleb optimeerida oma rakendusest, et selliseid olukordi ei tekiks. <\/p>\n

<\/p>\n

Teised halvad kliendid on ootej\u00e4rjekorras olevad kliendid. Kuid nad muutuvad halbadeks olukordade t\u00f5ttu. N\u00e4iteks lihtsalt seisev tehing: v\u00f5ib avada tehingu, lukustada m\u00f5ned read ja siis kuskil koodi sees see katkeb, j\u00e4ttes rippuma tehingu. Tuleb teine klient, kes k\u00fcsib samu andmeid, kuid ta peab silmitsi seisma lukustusega, sest see rippuv tehing hoiab juba lukustusi m\u00f5nes vajalikus reaas. Ja teine tehing j\u00e4\u00e4b ootele, kuni esimene tehing l\u00f5petatakse v\u00f5i selle administraator sunnib seda sulgema. Nii v\u00f5ivad ootavad tehingud koguneda ja \u00fcletada andmebaasi \u00fchenduste limiiti. Ja kui limiit \u00fcletatakse, siis rakendus ei saa enam andmebaasiga t\u00f6\u00f6tada. See on juba kriitiline olukord projekti jaoks. Seet\u00f5ttu on halbu kliente vaja j\u00e4lgida ja nendele \u00f5igeaegselt reageerida. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine n\u00e4ide j\u00e4lgimisest. Siin on juba korralik armatuurlaud. \u00dclal on teavet \u00fchenduste kohta. DB-\u00fchendused \u2013 8 t\u00fckki. Ja see on k\u00f5ik. Meil pole teavet selle kohta, millised kliendid on aktiivsed, millised kliendid lihtsalt ootavad, mitte midagi ei tee. Pole teavet ummistunud tehingute ja oote\u00fchenduste kohta, st see n\u00e4it on lihtsalt numbrina, mis n\u00e4itab \u00fchenduste arvu ja see on k\u00f5ik. Edasi m\u00f5elge ise.
\n\"PostgreSQL
\nSeet\u00f5ttu, et seda teavet j\u00e4lgimisele lisada, tuleb p\u00f6\u00f6rduda s\u00fcsteemi vaate pg_stat_activity poole. Kui veedate palju aega PostgreSQL-is, siis see vaade on t\u00f5eliselt v\u00e4\u00e4rtuslik ning see peaks muutuma teie s\u00f5braks, kuna see n\u00e4itab praegust aktiivsust PostgreSQL-is, st mis seal toimub. Iga protsessi kohta on eraldi rida, mis n\u00e4itab teavet selle protsessi kohta: milliselt hostilt \u00fchendus on loodud, millise kasutaja all, millise nimega, millal tehing k\u00e4ivitati, milline on praegu k\u00e4ivitatav p\u00e4ring ja milline p\u00e4ring oli eelmine. Seega saame kliendi olekut hinnata stat v\u00e4lja j\u00e4rgi. Teisis\u00f5nu, saame selle v\u00e4lja alusel grupeerida ja saada need statsid, mis praegu andmebaasis on ning \u00fchenduste arvu, mis on sellega statsiga andmebaasis. Ja juba saadud numbrid saame saata meie j\u00e4lgimisele ja nende p\u00f5hjal graafikuid joonistada.
\nSamuti on oluline hinnata tehingu kestust. Olen juba r\u00e4\u00e4kinud, et on t\u00e4htis hinnata vaakumite kestust, kuid tehingud on samuti t\u00e4pselt nii hinnatavad. On v\u00e4ljad xact_start ja query_start. Need n\u00e4itavad, \u00fctleme nii, tehingu algus- ja p\u00e4ringu algusaega. Me v\u00f5tame funktsiooni now(), mis n\u00e4itab praegust ajam\u00e4rki ja lahutame sellest tehingu ja p\u00e4ringu ajatempli. Ja saame tehingu kestuse, p\u00e4ringu kestuse. <\/p>\n

<\/p>\n

Kui n\u00e4eme pikki tehinguid, peame need juba l\u00f5petama. OLTP-koormuse jaoks peetakse pikki tehinguid selliseks, mis kestab \u00fcle 1-2-3 minuti.<\/strong>. OLAP-koormuse puhul on pikad tehingud normaalsed, kuid kui need kestavad rohkem kui kaks tundi, siis on see samuti m\u00e4rk sellest, et kuskil on meil tasakaaluh\u00e4ire.<\/strong> <\/p>\n

<\/p>\n

\"PostgreSQL
\nKui kliendid on andmebaasi sisse loginud, hakkavad nad meie andmetega t\u00f6\u00f6d tegema. Nad p\u00f6\u00f6rduvad tabelite poole, nad p\u00f6\u00f6rduvad indeksite poole, et saada andmeid tabelist. Oluline on hinnata, kuidas kliendid nende andmetega t\u00f6\u00f6tavad.<\/p>\n

<\/p>\n

See on vajalik, et hinnata meie t\u00f6\u00f6koormust ja umbkaudu m\u00f5ista, millised tabelid on meie jaoks k\u00f5ige \u00abkuumemad\u00bb. N\u00e4iteks vajame seda olukordades, kus soovime \u00abkuumad\u00bb tabelid paigutada kiiresti SSD-salvestusse. N\u00e4iteks v\u00f5ime arhiivi tabelid, mida me juba ammu ei kasuta, viia \u00abk\u00fclma\u00bb arhiivi SATA-kettale ja lasta neil seal elada, nendele p\u00e4\u00e4semine toimub vastavalt vajadusele. <\/p>\n

<\/p>\n

Samuti on see kasulik anomaaliate avastamiseks erinevate v\u00e4ljaandmiste ja juurutamiste j\u00e4rel. Oletame, et projekt k\u00e4ivitas uue funktsiooni. N\u00e4iteks lisati uus funktsionaalsus andmebaasi haldamiseks. Ja kui me joonistame v\u00e4lja tabelite kasutamise graafikud, saame nendel graafikutel kergesti avastada neid anomaaliaid. N\u00e4iteks uuenduste v\u00f5i kustutuste \u00e4kilised t\u00f5usud. See on v\u00e4ga h\u00e4sti n\u00e4htav.<\/p>\n

<\/p>\n

Samuti on v\u00f5imalik avastada \"sulgunud\" statistika anomaaliaid. Mida see t\u00e4hendab? PostgreSQL-l on v\u00e4ga tugev ja hea p\u00e4ringute planeerija. Arendajad kulutavad palju aega selle arendamisele. Kuidas see t\u00f6\u00f6tab? Heade plaanide koostamiseks kogub PostgreSQL teatud ajavahemike j\u00e4rel statistikat tabelites andmete jaotumise kohta. Need on k\u00f5ige sagedasemad v\u00e4\u00e4rtused: ainulaadsete v\u00e4\u00e4rtuste arv, teave NULL-e kohta tabelis, palju teavet. <\/p>\n

<\/p>\n

Selle statistika p\u00f5hjal koostab planeerija mitu p\u00e4ringut, valib k\u00f5ige optimaalsema ja kasutab seda p\u00e4ringu plaani p\u00e4ringu t\u00e4itmiseks ja andmete tagastamiseks. <\/p>\n

<\/p>\n

Kord, kui statistika \"ujub\". Andmete kvaliteet ja hulk on mingil moel tabelis muutunud, kuid statistika ei kogunenud. Ja loodud plaanid v\u00f5ivad osutuda mitteoptimaalseteks. Kui meie plaanid osutuvad kogutud j\u00e4lgimise ja tabelite j\u00e4rgi mitteoptimaalseteks, saame neid anomaaliaid n\u00e4ha. N\u00e4iteks, kui andmed on kvaliteetselt muutunud ja koondindeks hakkas kasutama j\u00e4rjestikust l\u00e4bit\u00f6\u00f6tamist tabelis, st kui p\u00e4ringul on vaja tagastada vaid 100 rida (piirang on limit 100), siis selle p\u00e4ringu jaoks tehakse t\u00e4iuslik l\u00e4bimine. Ja see avaldab alati v\u00e4ga halba m\u00f5ju j\u00f5udlusele. <\/p>\n

<\/p>\n

Ja me saame seda n\u00e4ha j\u00e4lgimises. V\u00f5ime juba vaadata seda p\u00e4ringut, sooritada explain, koguda statistikat, ehitada uus t\u00e4iendav indeks. Ja juba reageerida sellele probleemile. Seet\u00f5ttu on see oluline. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine n\u00e4ide j\u00e4lgimisest. Ma arvan, et paljud on selle \u00e4ra tundnud, kuna see on v\u00e4ga populaarne. Kes kasutab seda oma projektides 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. Kuid siin on \u00fcks halb detail. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

On mitmeid graafikuid. \u00dchtsuse m\u00f5\u00f5tmena on n\u00e4idatud baidid, st seal on 5 graafikut: Insert data, Update data, Delete data, Fetch data ja Return data. Kuid m\u00f5\u00f5t\u00fchikute puhul on n\u00e4idatud baidid. Probleem seisneb aga selles, et PostgreSQL statsitikast tagastavad andmed tuple'itena (rea kujul). Seega on need graafikud v\u00e4ga hea viis teie t\u00f6\u00f6koormuse v\u00e4hendamiseks mitme korra v\u00f5rra, k\u00fcmnete kordade v\u00f5rra, kuna tuple ei ole bait, tuple on rida, see on palju baite ja see on alati muutuva pikkusega. Seega, koormuse arvutamine baidides kasutades tuple'e on pea v\u00f5imatu \u00fclesanne v\u00f5i v\u00e4ga keeruline. Seet\u00f5ttu on alati oluline m\u00f5ista, et kui kasutate armatuurlauda v\u00f5i sisseehitatud j\u00e4lgimist, teeb see seda \u00f5igesti ja tagastab teile \u00f5igesti hinnatud andmed. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kuidas saada statistikat nende tabelite kohta? Selleks on PostgreSQL-s olemas teatud hulk vaateid. Ja peamine vaade on pg_stat_user_tables<\/a><\/noindex>. User_tables \u2013 see t\u00e4hendab, et tabelid, mis on loodud kasutaja nimel. Vastupidiselt on s\u00fcsteemi vaated, mida PostgreSQL ise kasutab. Ja on kokkuv\u00f5tte tabel Alltables, mis sisaldab nii s\u00fcsteemi- kui ka kasutajate tabeleid. Saate tugineda \u00fcksk\u00f5ik kummale, mis teile rohkem meeldib.<\/p>\n

<\/p>\n

\u00dclaltoodud v\u00e4ljade p\u00f5hjal on v\u00f5imalik hinnata sisestuste, v\u00e4rskenduste ja kustutuste arvu. See paneel, mida ma kasutasin, kasutab neid v\u00e4lju t\u00f6\u00f6koormuse omaduste hindamiseks. Seet\u00f5ttu saame samuti neile tugineda. Kuid tasub meeles pidada, et need on tuples, mitte baitid, seega ei saa me lihtsalt v\u00f5tta ja muuta neid baitideks.<\/p>\n

<\/p>\n

Nende andmete p\u00f5hjal saame koostada nn TopN-tabeleid. N\u00e4iteks Top-5, Top-10. Ja on v\u00f5imalik j\u00e4lgida neid kuumi tabeleid, mida kasutatakse rohkem kui teisi. N\u00e4iteks 5 \u00abkuuma\u00bb tabelit sisestamise osas. Ja nende TopN-tabelite p\u00f5hjal hindame meie t\u00f6\u00f6koormust ning saame j\u00e4lgida t\u00f6\u00f6koormuse piike p\u00e4rast igasuguseid avalikustamisi, v\u00e4rskendusi ja juurdep\u00e4\u00e4se. <\/p>\n

<\/p>\n

Samuti on oluline hinnata tabeli suurusi, kuna m\u00f5nikord arendajad lisavad uut funktsiooni ja meie tabelid hakkavad suurendama oma suuri m\u00f5\u00f5tmeid, kuna otsustatakse lisada t\u00e4iendav andmemaht, kuid ei prognoosita, kuidas see m\u00f5jutab andmebaasi suurust. Sellised juhud v\u00f5ivad samuti olla meie jaoks \u00fcllatuseks. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja n\u00fc\u00fcd v\u00e4ike k\u00fcsimus teile. Milline k\u00fcsimus tekib, kui m\u00e4rkate andmebaasi serveris koormust? Milline on j\u00e4rgmine k\u00fcsimus, mis teil tekib? <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kuid tegelikult tekib j\u00e4rgmine k\u00fcsimus. Milliseid p\u00e4ringuid koormus kutsub esile? St ei ole huvitav vaadata protsesse, mis koormust p\u00f5hjustavad. On selge, et kui host on andmebaas, siis seal t\u00f6\u00f6tab andmebaas ja on selge, et ainult andmebaasid seal ka t\u00f6\u00f6tavad. Kui avame Topi, n\u00e4eme seal PostgreSQL protsesside nimekirja, mis midagi teevad. Topist ei selgu, mida nad teevad. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Seega on vaja tuvastada need p\u00e4ringud, mis p\u00f5hjustavad suurima koormuse, sest p\u00e4ringute h\u00e4\u00e4lestamine toob tavaliselt rohkem kasu kui PostgreSQL v\u00f5i operatsioonis\u00fcsteemi h\u00e4\u00e4lestamine v\u00f5i isegi riistvara h\u00e4\u00e4lestamine. Minu hinnangul on see umbes 80-85-90%. Ja seda tehakse palju kiiremini. P\u00e4ringu parandamine v\u00f5tab v\u00e4hem aega kui konfiguratsiooni korrigeerimine, taask\u00e4ivitamise planeerimine, eriti juhul, kui andmebaasi ei saa taask\u00e4ivitada v\u00f5i riistvara lisada. Lihtsam on kuskil p\u00e4ringut \u00fcmber kirjutada v\u00f5i lisada indeks, et saada juba paremat tulemust sellest p\u00e4ringust. <\/p>\n

<\/p>\n

\"PostgreSQL
\nSeega tuleb j\u00e4lgida p\u00e4ringute sisu ja nende adekvaatsust. Vaatame teisi j\u00e4lgimise n\u00e4iteid. Siin on samuti n\u00e4iliselt suurep\u00e4rane j\u00e4lgimine. On teavet replikatsiooni, l\u00e4bilaskev\u00f5ime, lukustuste ja ressursside kasutamise kohta. K\u00f5ik on suurep\u00e4rane, kuid puudub teave p\u00e4ringute kohta. Pole selge, millised p\u00e4ringud meie andmebaasis k\u00e4ivitatakse, kui kaua need kestavad ja kui palju neid on. Me peame j\u00e4lgimisel alati seda teavet omama. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja selle teabe saamiseks saame kasutada pg_stat_statements moodulit. Selle alusel saab koostada erinevaid diagramme. N\u00e4iteks saame saada teavet k\u00f5ige sagedamini esitatavate p\u00e4ringute kohta, s.t. nende p\u00e4ringute kohta, mis t\u00e4idetakse k\u00f5ige rohkem. Jah, ka p\u00e4rast v\u00e4ljat\u00f5mmete tegemist on v\u00e4ga kasulik sellele pilk heita ja m\u00f5ista, kas p\u00e4ringute arv on suurenenud. <\/p>\n

<\/p>\n

Saame j\u00e4lgida k\u00f5ige aeglasemaid p\u00e4ringuid, s.t. neid p\u00e4ringuid, mis t\u00e4idetakse k\u00f5ige kauem. Need kasutavad protsessorit, nad tarbivad sisendi-v\u00e4ljundi ressursse. Saame seda hinnata ka total_time, mean_time, blk_write_time ja blk_read_time v\u00e4ljade kaudu. <\/p>\n

<\/p>\n

Saame hinnata ja j\u00e4lgida k\u00f5ige ressursimahukamaid p\u00e4ringuid, neid, mis loevad kettalt, t\u00f6\u00f6tavad m\u00e4luga v\u00f5i vastupidi, genereerivad kirjutamiskoormust.<\/p>\n

<\/p>\n

Saame hinnata k\u00f5ige arvukamaid p\u00e4ringuid. Need on p\u00e4ringud, mis tagastavad suure hulga ridu. N\u00e4iteks v\u00f5ib see olla p\u00e4ring, kus unustati limiit panna. Ja see tagastab lihtsalt kogu tabeli sisu v\u00f5i midagi, mis on n\u00f5utud tabelite kohta.<\/p>\n

<\/p>\n

Saame ka j\u00e4lgida p\u00e4ringuid, mis kasutavad ajutisi faile v\u00f5i ajutisi tabeleid. <\/p>\n

<\/p>\n

\"PostgreSQL
\nMeil on ka taustaprosessid. Taustaprosessid on eelk\u00f5ige kontrollpunktid, mida nimetatakse ka kontrollpunktideks, autovacuum ja replikatsioon. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine n\u00e4ide j\u00e4lgimisest. Vasakul on vahekaart Maintenance, liikuge sinna ja loodame n\u00e4ha midagi kasulikku. Kuid siin on ainult vakumite ja statistika kogumise t\u00f6\u00f6aeg, rohkem mitte midagi. See on v\u00e4ga napp teave, seet\u00f5ttu on alati oluline teada, kuidas meie andmebaasis taustaprosessid t\u00f6\u00f6tavad ja kas nende tegevusest on probleeme. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kontrollpunkte k\u00e4sitledes tasub meeles pidada, et kontrollpunktid kustutavad 'r\u00e4paseid' lehti sharded m\u00e4lu piirkonnast k\u00f5vakettale, seej\u00e4rel luuakse kontrollpunkt. See kontrollpunkt v\u00f5ib hiljem olla kasutatav taastamise kohana, kui PostgreSQL peaks \u00e4kki kokku kukkuma. <\/p>\n

<\/p>\n

Seega, et k\u00f5ik \"r\u00e4pased\" lehed kettale l\u00e4htestada, tuleb teha teatud kogus kirjutamist. Ja tavaliselt on s\u00fcsteemides, kus on palju m\u00e4lu, seda v\u00e4ga palju. Ja kui meil on kontrollpunkte v\u00e4ga sageli l\u00fchikese aja jooksul, siis kettas\u00fcsteemi j\u00f5udlus kannatab t\u00f5siselt. Kliendi p\u00e4ringud kannatavad ressursside puuduse all. Nad v\u00f5itlevad ressursside p\u00e4rast ning neil j\u00e4\u00e4b j\u00f5udlusest puudu. <\/p>\n

<\/p>\n

Seega, pg_stat_bgwriter kaudu v\u00f5ivad antud v\u00e4ljade j\u00e4rgi j\u00e4lgida kontrollpunktide arvu. Ja kui mingis ajavahemikus (n\u00e4iteks 10-15-20 minuti, pool tunni jooksul) on kontrollpunkte v\u00e4ga palju, n\u00e4iteks 3-4-5, siis see v\u00f5ib juba olla probleem. Ja tuleb vaadata andmebaasi, vaadata konfiguratsiooni, mis sellist kontrollpunktide rohkust p\u00f5hjustab. V\u00f5ib-olla toimub mingi suur kirjutamine. Workload'i p\u00f5hjal saame juba hinnata, kuna meil on t\u00f6\u00f6koormuse graafikud juba lisatud. Saame kohandada kontrollpunktide parameetreid nii, et need ei m\u00f5juta p\u00e4ringute j\u00f5udlust.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ma tulen j\u00e4lle autovacuum\u2019i juurde, sest see on asi, mis nagu juba mainisin, v\u00f5ib kergesti m\u00f5jutada nii kettahaarde kui ka p\u00e4ringute j\u00f5udlust, seet\u00f5ttu on alati oluline hinnata autovacuum\u2019i m\u00e4\u00e4ra. <\/p>\n

<\/p>\n

Autovacuum\u2019i t\u00f6\u00f6de arv andmebaasis on piiratud. Vaikimisi on neid kolm, seega kui meil on pidevalt t\u00f6\u00f6tamas kolm t\u00f6\u00f6list, t\u00e4hendab see, et meie autovacuum on alakonfigureeritud, tuleb t\u00f5sta limite, \u00fcle vaadata autovacuum\u2019i seaded ja minna juba konfiguratsiooni.
\nOn oluline hinnata, millised autovacuum\u2019i t\u00f6\u00f6lised meil t\u00f6\u00f6tavad. Kas see on kasutaja k\u00e4ivitatud, DBA on tulnud ja k\u00e4sitsi k\u00e4ivitanud mingi vacuum\u2019i, ning see on tekitanud koormuse. Meil on tekkinud mingi probleem. V\u00f5i on see autovacuum\u2019ide arv, mis arvestavad tehingute arvutust. M\u00f5nedes PostgreSQL versioonides on need v\u00e4ga koormavad vacuum\u2019id. Need v\u00f5ivad kergesti m\u00f5jutada j\u00f5udlust, sest need loevad kogu tabelit t\u00e4iesti l\u00e4bi, skaneerides k\u00f5ik plokid selles tabelis. <\/p>\n

<\/p>\n

Ja muidugi, ka vaakumi kestus. Kui meil on pikad vaakumid, mis t\u00f6\u00f6tavad v\u00e4ga pikka aega, siis see t\u00e4hendab, et peaksime taas t\u00e4helepanu p\u00f6\u00f6rama vaakumi konfiguratsioonile ja v\u00f5ib-olla kaaluma selle seadete \u00fclevaatamist. Sest v\u00f5ib tekkida olukord, kus vaakum t\u00f6\u00f6tab tabelis kaua (3-4 tundi), kuid selle t\u00f6\u00f6tamise ajal on tabelis j\u00e4lle kogunenud suur hulk surnud ridu. Ja nii pea, kui vaakum l\u00f5ppeb, peab see tabelit uuesti vaakumeerima. Nii j\u00f5uame olukorda \u2013 l\u00f5putu vaakum. Ja sellisel juhul ei tule vaakum oma t\u00f6\u00f6ga toime ning tabelid hakkavad j\u00e4rk-j\u00e4rgult suurendama oma mahtu, kuigi selles olevate kasulike andmete hulk j\u00e4\u00e4b endiseks. Seet\u00f5ttu vaatame alati pikal vaakumite ajal konfiguratsiooni ja p\u00fc\u00fcame seda optimeerida, kuid samas, et klientide p\u00e4ringute j\u00f5udlus ei kannataks. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Praegu ei leidu praktiliselt \u00fchtegi PostgreSQL-i installatsiooni, kus ei oleks voogedastust. Replikatsioon on andmete edastamise protsess peamehelt kopeerimisprotsessile.<\/p>\n

<\/p>\n

PostgreSQL-is replikatsioon toimub tehingu logi kaudu. Master genereerib tehingu logi. Tehingu logi saadetakse replikale \u00fcle v\u00f5rgus ja seal see taastatakse. K\u00f5ik on lihtne. <\/p>\n

<\/p>\n

Seet\u00f5ttu kasutatakse replikatsiooni viivituse j\u00e4lgimiseks vaadet pg_stat_replication. Kuid sellega ei ole k\u00f5ik lihtne. Versioonis 10 on vaates toimunud mitmeid muudatusi. Esiteks, m\u00f5ned v\u00e4ljad on \u00fcmber nimetatud. Ja m\u00f5ned v\u00e4ljad on lisatud. Versioonis 10 lisandusid v\u00e4ljad, mis v\u00f5imaldavad hinnata replikatsiooni viivitust sekundites. See on v\u00e4ga mugav. Enne versiooni 10 oli v\u00f5imalik hinnata replikatsiooni viivitust baitides. See v\u00f5imalus j\u00e4\u00e4b alles ka versioonis 10, st saate valida, kumba teile sobib \u2013 hinnata viivitust baitides v\u00f5i sekundites. Paljud teevad m\u00f5lemat.<\/p>\n

<\/p>\n

Kuid siiski, et hinnata replikatsiooni viivitust, tuleb teada tehingu logi positsiooni. Need tehingu logi positsioonid ongi pg_stat_replication vaates. \u00dctleme nii, et saame funktsiooni pg_xlog_location_diff() abil v\u00f5tta kaks punkti tehingu logis. Arvutada nende vahelise erinevuse ja saada replikatsiooni viivitus baitides. See on v\u00e4ga mugav ja lihtne. <\/p>\n

<\/p>\n

10. versioonis nimetati see funktsioon \u00fcmber pg_wal_lsn_diff(). \u00dcldiselt, k\u00f5ikides funktsioonides, vaadetes, utiliitides, kus ilmus s\u00f5na \"xlog\", asendati see s\u00f5naga \"wal\". See kehtib nii vaadete kui ka funktsioonide kohta. See on selline uuendus. <\/p>\n

<\/p>\n

Pluss, 10. versioonis lisandusid read, mis n\u00e4itavad konkreetselt viivitust. Need on write lag, flush lag ja replay lag. St neid asju on oluline j\u00e4lgida. Kui n\u00e4eme, et meil on replikatsiooni viivitus, tuleb uurida, miks see tekkis, kust see tuli ning probleeme lahendada. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

S\u00fcsteemsete m\u00f5\u00f5dikute osas on peaaegu k\u00f5ik korras. Kui iga monitoringu loomine algab s\u00fcsteemsetest m\u00f5\u00f5dikutest. Need on protsessorite, m\u00e4lu, vahetuse, v\u00f5rgu ja ketta kasutamine. Kuid paljusid parameetreid ei ole seal vaikimisi olemas. <\/p>\n

<\/p>\n

Kui protsessi utilizeerimisega on k\u00f5ik korras, siis ketta utilizeerimisega on probleeme. T\u00fc\u00fcpiliselt lisavad j\u00e4lgimisriistade arendajad teavet l\u00e4bilaskev\u00f5ime kohta. See v\u00f5ib olla iops v\u00f5i baitides. Kuid nad unustavad latentsuse ja kettaseadmete utilizeerimise. Need on olulisemad parameetrid, mis aitavad hinnata, kui koormatud meie kettad on ja kui palju nad peavad pidurdama. Kui meil on k\u00f5rge latentsus, siis t\u00e4hendab see, et kettastega on mingid probleemid. Kui meil on k\u00f5rge utilizeerimine, siis t\u00e4hendab see, et kettad ei tule toime.<\/strong> Need on kvaliteetsemad omadused kui l\u00e4bilaskev\u00f5ime.<\/p>\n

<\/p>\n

Kuigi neid statistilisi andmeid saab ka failis\u00fcsteemist \/proc, nagu tehakse protsessorite utilizeerimise puhul. Miks seda teavet j\u00e4lgimistesse ei lisata, ei tea ma. Kuid sellegipoolest on oluline, et see oleks teie j\u00e4lgimises.<\/strong> <\/p>\n

<\/p>\n

Sama kehtib ka v\u00f5rguliideste kohta. V\u00f5rgu l\u00e4bilaskev\u00f5ime kohta on teavet pakettide, baitide kaupa, kuid siiski puudub teave latentsuse ja utilizeerimise kohta, kuigi see oleks samuti kasulik teave.<\/strong> <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Iga monitooringul on omad puudused. \u00dcksk\u00f5ik millist monitooringut te valite, see ei vasta alati teatud kriteeriumidele. Siiski nad arenevad, lisanduvad uued funktsioonid ja asjad, seega valige midagi ja viige see l\u00f5pule. <\/p>\n

<\/p>\n

Ja et edendada, on oluline alati m\u00f5ista, mida edastatud statistika t\u00e4hendab ning kuidas seda saab probleemide lahendamiseks kasutada. <\/p>\n

<\/p>\n

Ja m\u00f5ned peamised punktid:<\/p>\n

<\/p>\n