{"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 alused. 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 \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Hallates erinevaid Linuxi s\u00fcsteeme, tegelesin erinevate asjadega, mis olid seotud Linuxiga, st virtualiseerimise, monitoorimisega, t\u00f6\u00f6tasin proksidega jne. Kuid mingil hetkel hakkasin rohkem tegelema andmebaasidega, PostgreSQL'iga. See meeldis mulle v\u00e4ga. Ja mingil hetkel hakkasin PostgreSQL'le p\u00fchendama suurema osa oma t\u00f6\u00f6ajast. Nii ma aeglaselt muutusin PostgreSQL DBA-ks.<\/p>\n

<\/p>\n

Ja kogu oma karj\u00e4\u00e4ri jooksul on mind alati huvitanud statistika, monitooringu ja telemeetria teemad. Kui olin s\u00fcsteemiadministraator, tegelesin tihedalt Zabbixiga. Kirjutasin v\u00e4ikese komplekti skripte nagu zabbix-extensions<\/a><\/noindex>. See oli omal ajal \u00fcsna populaarne. Seal sai monitoorida v\u00e4ga erinevaid olulisi asju, mitte ainult Linuxit, vaid ka teisi komponente.<\/p>\n

<\/p>\n

Praegu tegelema PostgreSQL'iga. Kirjutan teistsugust asja, mis v\u00f5imaldab t\u00f6\u00f6tada PostgreSQL statistika pealt. See kannab nime pgCenter<\/a><\/noindex> (artikkel Habr's \u2014 PostgreSQL statistika muredeta ja pingeteta<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

L\u00fchike sissejuhatus. Millised olukorrad meie tellijatel, meie klientidel esinevad? Juhtub m\u00f5ni h\u00e4da, mis on seotud andmebaasiga. Ja kui andmebaas on juba taastatud, tuleb osakonna juht v\u00f5i arenduse juht ning \u00fctleb: \u201eKallis, peaksime andmebaasi j\u00e4lgima, sest juhtus midagi halba ja me peame tagama, et midagi sellist ei juhtuks tulevikus.\u201c Ja siin algab huvitav valikuprotsess j\u00e4lgimiss\u00fcsteemi valimiseks v\u00f5i olemasoleva j\u00e4lgimiss\u00fcsteemi kohandamiseks, et saaksime oma andmebaasi \u2014 PostgreSQL, MySQL v\u00f5i m\u00f5ne muu \u2014 j\u00e4lgida. Ja kolleegid hakkavad ettepanekuid tegema: \u201eMa olen kuulnud, et selline andmebaas on olemas. Kas me ei v\u00f5iks seda kasutada?\u201c Kolleegid hakkavad omavahel vaidlema. Tulemuseks on, et valime m\u00f5ne andmebaasi, kuid PostgreSQL-i j\u00e4lgimine on seal n\u00f5rgalt esindatud ja alati peab midagi seadistama. Peame v\u00f5tma GitHubist mingeid hoidlaid, need kloonima, skripte kohandama, kuidagi t\u00e4iustama. Ja l\u00f5puks muutub see k\u00e4sit\u00f6\u00f6ks. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Seet\u00f5ttu p\u00fc\u00fcan ma selles ettekandes anda teile teavet, kuidas valida j\u00e4lgimist mitte ainult PostgreSQL-i, vaid ka andmebaasi jaoks. Ja anda teadmised, mis aitavad teil teie j\u00e4lgimist t\u00e4iustada, et saada sellest kasu, et saaksite oma andmebaasi j\u00e4lgida kasulikult ning \u00f5igeaegselt hoiatada v\u00f5imalike probleemide eest, mis v\u00f5ivad tekkida. <\/p>\n

<\/p>\n

Ja need ideed, mis selles ettekandes esitatakse, saab otse kohandada igasuguste andmebaaside jaoks, olgu need siis S\u00dcB v\u00f5i noSQL. Seet\u00f5ttu ei ole siin mitte ainult PostgreSQL, vaid ka palju retsepte, kuidas seda PostgreSQL-is teha. Esitatakse p\u00e4ringute n\u00e4iteid, n\u00e4iteid isenditest, mis on PostgreSQL-is j\u00e4lgimiseks olemas. Ja kui teie S\u00dcB-il on sarnased asjad, mis v\u00f5imaldavad neid j\u00e4lgimisse panna, saate neid samuti kohandada, lisada ja k\u00f5ik on h\u00e4sti.<\/p>\n

<\/p>\n

\"PostgreSQLEttekandes ei r\u00e4\u00e4gi ma
\nm\u00f5\u00f5dikute edastamisest ja salvestamisest. Ma ei r\u00e4\u00e4gi midagi andmete t\u00f6\u00f6tlemise ja kasutajale esitamise kohta. Ja ma ei r\u00e4\u00e4gi midagi h\u00e4irete seadistamisest.
\nKuid loo k\u00e4igus hakkan ma n\u00e4itama erinevaid olemasolevaid monitooringute ekraanipilte ja m\u00f5ningaid neist kritiseerima. Pean siiski silmas, et p\u00fc\u00fcan br\u00e4ndide nimesid mitte mainida, et mitte tekitada neile toodetele reklaami v\u00f5i vastureklaami. Seega on k\u00f5ik sarnased juhtumid juhuslikud ja j\u00e4\u00e4vad teie fantaasiasse.
\n\"PostgreSQL
\nEsiteks m\u00f5istame, mis on monitooring. Monitooring on v\u00e4ga oluline asi, mida on h\u00e4dasti vaja. Seda m\u00f5istetakse k\u00f5ikjal. Kuid samal ajal ei kuulu monitooring \u00e4ri toote hulka ega m\u00f5juta otseselt ettev\u00f5tte kasumit, seet\u00f5ttu p\u00f6\u00f6ratakse monitooringule alati aega alles siis, kui muud t\u00f6\u00f6d on tehtud. Kui meil on aega, siis tegeleme monitooringuga, kui aega ei ole, siis OK, paneme selle ootele ja tulevikus tuleme nende \u00fclesannete juurde tagasi. <\/p>\n

<\/p>\n

Seet\u00f5ttu meie praktikast, kui me tuleme klientide juurde, on monitooring sageli puudulik ja ei sisalda huvitavaid elemente, mis aitaksid meil andmebaasidega t\u00f6\u00f6d paremini teha. Seet\u00f5ttu on monitooringut alati vaja t\u00e4iendada. <\/p>\n

<\/p>\n

Andmebaasid on keerulised asjad, mida tuleb samuti monitooringu alla v\u00f5tta, sest andmebaasid on teabehoidla. Ja teave on ettev\u00f5tte jaoks v\u00e4ga oluline, seda ei tohi mingil juhul kaotada. Kuid samas on andmebaasid ka v\u00e4ga keerulised tarkvarakomponendid. Need koosnevad paljusid komponente. Ja paljusid neist komponentidest tuleb monitooringu alla v\u00f5tta. <\/p>\n

<\/p>\n

\"PostgreSQLKui r\u00e4\u00e4gime konkreetselt PostgreSQL-ist, siis v\u00f5ib seda esitada kui sellist skeemi, mis koosneb paljusid komponente. Need komponendid suhtlevad \u00fcksteisega. Ja samal ajal on PostgreSQL-is nn Stats Collectori alams\u00fcsteem, mis v\u00f5imaldab koguda statistikat nende alams\u00fcsteemide t\u00f6\u00f6 kohta ja anda administreerijale v\u00f5i kasutajale teatud liidese, et ta saaks seda statistikat vaadata. <\/p>\n

<\/p>\n

See statistika on esitatud teatud funktsioonide ja vaadete (view) kogumina. Neid v\u00f5ib nimetada ka tabeliteks. See t\u00e4hendab, et tavalise psql kliendi abil saate andmebaasiga \u00fchendada, teha nendele funktsioonidele ja vaadetele SELECT-p\u00e4ringu ning saada juba konkreetseid numbreid PostgreSQL alams\u00fcsteemide t\u00f6\u00f6 kohta. <\/p>\n

<\/p>\n

Saate lisada need numbrid oma lemmik monitooringus\u00fcsteemi, koostada graafikuid, lisada funktsioone ja saada pikaajalist anal\u00fc\u00fcsi. <\/p>\n

<\/p>\n

Kuid ma ei kavatse selles raportis arutada k\u00f5iki neid funktsioone, sest see v\u00f5ib v\u00f5tta terve p\u00e4eva. Ma keskendun vaid kahele kuni neljale punktile ja r\u00e4\u00e4gin, kuidas need aitavad j\u00e4lgimist paremaks muuta.
\n\"PostgreSQL
\nJa kui r\u00e4\u00e4kida andmebaasi j\u00e4lgimisest, siis mida tuleks j\u00e4lgida? Esiteks tuleb j\u00e4lgida k\u00e4ttesaadavust, kuna andmebaas on teenus, mis pakub klientidele juurdep\u00e4\u00e4su andmetele, ja peame j\u00e4lgima k\u00e4ttesaadavust, samuti m\u00f5ningaid selle kvaliteetseid ja kvantitatiivseid omadusi. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

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

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kui kliendid \u00fchenduvad andmebaasi, siis on ilmne, et nad hakkavad t\u00f6\u00f6tama meie andmetega, seega peame j\u00e4lgima ka seda, kuidas kliendid andmetega t\u00f6\u00f6tavad: milliste tabelitega, v\u00e4hemal m\u00e4\u00e4ral milliste indexitega. See t\u00e4hendab, et peame hindama t\u00f6\u00f6koormust, mille meie kliendid tekitavad.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kuid t\u00f6\u00f6koormus koosneb muidugi p\u00e4ringutest. Rakendused \u00fchenduvad andmebaasiga, kutsuvad andmeid v\u00e4lja p\u00e4ringute kaudu, seega on oluline hinnata, millised p\u00e4ringud meil andmebaasis on, j\u00e4lgida nende adekvaatsust, et nad ei oleks valesti kirjutatud, ning m\u00f5ningaid valikuid tuleks \u00fcmber kirjutada, et need t\u00f6\u00f6taksid kiiremini ja parema j\u00f5udlusega. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja kuna me r\u00e4\u00e4gime andmebaasist, siis andmebaas t\u00e4hendab alati taustprotsesse. Taustprotsessid aitavad s\u00e4ilitada andmebaasi j\u00f5udlust heas seisus, seega vajavad nad teatud hulga ressursse enda jaoks. Samuti v\u00f5ivad nad kattuda klientide p\u00e4ringute ressurssidega, seega v\u00f5ivad taustprotsesside intensiivne t\u00f6\u00f6 otseselt m\u00f5jutada klientide p\u00e4ringute j\u00f5udlust. Seega tuleb neid samuti j\u00e4lgida ja v\u00e4ltida tasakaaluh\u00e4ireid taustprotsesside osas. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja see k\u00f5ik andmebaasi j\u00e4lgimise osas j\u00e4\u00e4b s\u00fcsteemi meetrika. Kuid arvestades, et meie kogu infrastruktuur liigub peamiselt pilve, j\u00e4\u00e4vad eraldi hosti s\u00fcsteemi meetrikad alati tagaplaanile. Kuid andmebaasides on need endiselt olulised ja s\u00fcsteemi meetrikate j\u00e4lgimine on loomulikult samuti vajalik. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

S\u00fcsteemi meetrikate osas on enam-v\u00e4hem k\u00f5ik h\u00e4sti, k\u00f5ik kaasaegsed j\u00e4lgimiss\u00fcsteemid toetavad neid meetrikaid, kuid \u00fcldiselt m\u00f5ningaid komponente siiski puudub ja m\u00f5ned asjad on vajalikud lisada. Nendest r\u00e4\u00e4gin ma samuti, paar slaidi on nende kohta. <\/p>\n

<\/p>\n

\"PostgreSQL
\nEsimene plaani punkt on k\u00e4ttesaadavus. Mis on k\u00e4ttesaadavus? K\u00e4ttesaadavus minu arusaama kohaselt t\u00e4hendab andmebaasi v\u00f5imet teenindada \u00fchendusi, st andmebaas on aktiivne, see, nagu teenus, aktsepteerib klientide \u00fchendusi. Ja seda k\u00e4ttesaadavust saab hinnata teatud omadustega. Need omadused on v\u00e4ga mugavad paneelidele v\u00e4lja toomiseks. <\/p>\n

<\/p>\n

\"PostgreSQL
\nK\u00f5ik teavad, mis on paneelid. See on siis, kui heidad pilku ekraanile, kus on kokku koondatud vajalik teave. Ja sa saad kohe m\u00e4\u00e4rata - kas andmebaasis on probleem v\u00f5i mitte.
\nSeega andmebaasi k\u00e4ttesaadavus ja teised olulised omadused on alati vajalikud paneelidele v\u00e4ljatootmiseks, et see teave oleks k\u00e4ep\u00e4rast ja alati sinu l\u00e4hedal. M\u00f5ned lisadetailid, mis aitavad juhtumite uurimise, avariiolukordade uurimise puhul, peaksid minema teisej\u00e4rgulistele paneelidele v\u00f5i olema peidetud drilldown-linkidesse, mis viivad kolmandate osapoolte j\u00e4lgimiss\u00fcsteemidesse. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche tuntud j\u00e4lgimiss\u00fcsteemi n\u00e4ide. See on v\u00e4ga \u00e4ge j\u00e4lgimiss\u00fcsteem. See kogub v\u00e4ga palju andmeid, kuid minu arvates on seal kummaline m\u00f5isted paneelide osas. Seal on link \"loo paneel\". Kuid kui sa lood paneeli, siis lood sa teatud loendi, mis koosneb kahest veerust, mingi graafikute loendi. Ja kui sul on vaja midagi vaadata, siis hakkad hiirega klikkima, kerima, otsima vajalikku graafikut. Ja selleks kulub aega, st t\u00f5elisi paneele ei ole. On vaid graafikute loendid.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Mida tuleks nende juhtpaneelide peale lisada? V\u00f5ib alustada sellise n\u00e4itajaga nagu reageerimisaeg. PostgreSQL-is on vaade pg_stat_statements. Vaikimisi on see v\u00e4lja l\u00fclitatud, kuid see on \u00fcks olulisemaid s\u00fcsteemi vaateid, mis tuleks alati sisse l\u00fclitada ja kasutada. See salvestab teavet k\u00f5igi k\u00e4ideldud p\u00e4ringute kohta, mis on andmebaasis teostatud. <\/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 vigu, mida s\u00fcsteem praegu genereerib. Selleks saame kasutada vaadet pg_stat_database. Me vaatame v\u00e4ljale xact_rollback. See v\u00e4li n\u00e4itab mitte ainult tabeli tagasiv\u00f5tmise arvu, vaid arvestab ka vigade arvu. \u00dctleme nii, et saame selle numbri oma juhtpaneelile v\u00e4lja tuua ja vaadata, kui palju vigu meil praegu on. Kui vigu on palju, on see juba hea p\u00f5hjus vaadata logisid ja n\u00e4ha, millised need vead on ja miks need juhtuvad, ning seej\u00e4rel uurida ja lahendada need.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Saame lisada sellise asja nagu tahhomeeter. See on tehingute arv sekundis ja p\u00e4ringute arv sekundis. \u00dctleme nii, et v\u00f5ite neid numbreid kasutada oma andmebaasi praeguse j\u00f5udluse indikaatorina ja j\u00e4lgida, kas on p\u00e4ringute v\u00f5i tehingute tippe, v\u00f5i vastupidi, et andmebaas on alatalletatud, sest m\u00f5ni backend on kokku kukkunud. Seda numbrit on oluline alati 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 on.<\/p>\n

<\/p>\n

Tehingute arvu hindamiseks v\u00f5ime j\u00e4lle p\u00f6\u00f6rduda pg_stat_database vaate poole. Saame liita commitide ja rollbackide arvu, et saada tehingute arv sekundis. <\/p>\n

<\/p>\n

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

<\/p>\n

P\u00e4ringute arvu sekundis saab saada pg_stat_statements'ist ning lihtsalt arvutada v\u00e4lja k\u00f5ikide t\u00e4idetud p\u00e4ringute summa. On selge, et me v\u00f5rdleme praegust v\u00e4\u00e4rtust varasemaga, lahutame selle, saame delta ja saame arvu.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

V\u00f5ime soovi korral lisada t\u00e4iendavaid m\u00f5\u00f5dikuid, mis aitavad samuti hinnata meie andmebaasi k\u00e4ttesaadavust ja j\u00e4lgida, kas on olnud mingit katkestust. <\/p>\n

<\/p>\n

\u00dcks neist m\u00f5\u00f5dikest on uptime. Kuid uptime PostgreSQL-is on veidi keeruline asi. R\u00e4\u00e4gin, miks. Kui PostgreSQL k\u00e4ivitub, algab uptime arvestamine. Kuid kui m\u00f5nel hetkel, n\u00e4iteks \u00f6\u00f6sel, t\u00e4ideti m\u00f5ni \u00fclesanne, tuli OOM-killer ja sundis PostgreSQL-lt alamharu protsessi katkestama, siis sel juhul l\u00f5petab PostgreSQL k\u00f5igi klientide \u00fchendused, t\u00fchjendab sharding m\u00e4lu ja alustab taastamist viimase kontrollpunkti juures. Ja kuni see taastamine kestab, ei v\u00f5ta andmebaas \u00fchendusi, seega saab seda olukorda hinnata kui katkestust. Kuid samas uptime m\u00f5\u00f5dik ei nulli ennast, sest see arvestab postmaster'i k\u00e4ivitamise aega alates esimesest hetkes. Seet\u00f5ttu v\u00f5ib selliseid olukordi m\u00f6\u00f6da vaadata.<\/p>\n

<\/p>\n

Samuti tuleb j\u00e4lgida vakumeerimise t\u00f6\u00f6tlusprotsesside arvu. Kas k\u00f5ik tunnevad autovacuum'i PostgreSQL-is? See on huvitav alams\u00fcsteem PostgreSQL-is. Selle kohta on kirjutatud palju artikleid, peetud palju ettekandeid. Palju arutelusid vakumeerimise \u00fcle, kuidas see peaks t\u00f6\u00f6tama. Paljud peavad seda v\u00e4ltimatuks kurjuseks. Ja see on t\u00f5si. See on omamoodi pr\u00fcgikasti koristaja, mis puhastab aegunud ridade versioonid, mis ei ole \u00fchegi tehingu jaoks vajalikud, ja vabastab ruumi tabelites, indeksites uute ridade jaoks. <\/p>\n

<\/p>\n

Miks tuleb seda j\u00e4lgida? Sest vakumeerimine v\u00f5ib vahel olla v\u00e4ga valus. See s\u00f6\u00f6b suure hulga ressursse ja kliendip\u00e4ringud kannatavad selle t\u00f5ttu. <\/p>\n

<\/p>\n

Ja tuleks j\u00e4lgida selle aktiivsust pg_stat_activity vaate kaudu, millest ma r\u00e4\u00e4gin j\u00e4rgmises osas. See vaade n\u00e4itab praegust tegevust andmebaasis. Selle tegevuse kaudu saame j\u00e4lgida, kui palju vaakume on hetkel t\u00f6\u00f6s. Saame j\u00e4lgida vaakume ja n\u00e4ha, et kui meil on \u00fcletatud piirang, siis on see p\u00f5hjus vaadata PostgreSQL seadeid ja kuidas vaakumi t\u00f6\u00f6d optimeerida. <\/p>\n

<\/p>\n

Teine PostgreSQL omadus on see, et PostgreSQL kannatab v\u00e4ga pikkaealiste tehingute all. Eriti tehingute, mis on pikka aega aktiivsed, kuid ei tee midagi. Need on nn stat idle-in-transaction tehingud. Selline tehing hoiab blokeeringuid ja takistab vaakumi t\u00f6\u00f6d. Tagaj\u00e4rjeks on see, et tabelid paisuvad, nende suurus suureneb. Ja p\u00e4ringud, mis t\u00f6\u00f6tavad nende tabelitega, hakkavad t\u00f6\u00f6tama aeglasemalt, sest tuleb vanu ridade versioone m\u00e4lust kettale ja tagasi kaevama.<\/strong> Seet\u00f5ttu on oluline j\u00e4lgida ka pikkade tehingute aega, k\u00f5ige pikemate vaakumip\u00e4ringute aega. Ja kui me n\u00e4eme mingeid protsesse, mis t\u00f6\u00f6tavad juba v\u00e4ga pikka aega, rohkem kui 10-20-30 minutit OLTP-koormuse jaoks, siis tuleb neile t\u00e4helepanu p\u00f6\u00f6rata ja need kas sulgeda sundkorras v\u00f5i optimeerida rakendust, et need ei kutsuks \u00fcles ja ei seisaks liiga kaua.<\/strong> Ala-analyytika koormuse jaoks on 10-20-30 minutit normaalne, seal v\u00f5ib olla ka veelgi pikemaid. <\/p>\n

<\/p>\n

\"PostgreSQL
\nJ\u00e4rgmine on variant \u00fchendatud klientidega. Kui oleme juba koostanud juhtpaneeli, ja seni, kuni oleme sellele v\u00e4lja riputanud v\u00f5tmeprotsendid saadavusest, saame sinna lisada ka t\u00e4iendavat teavet \u00fchendatud klientide kohta. <\/p>\n

<\/p>\n

Teave \u00fchendatud klientide kohta on oluline, sest PostgreSQL vaatepunktist on kliendid erinevad. On h\u00e4id kliente ja halbu kliente. <\/p>\n

<\/p>\n

Lihtne n\u00e4ide. Klient, mida ma m\u00f5istan, on rakendus. Rakendus on \u00fchendatud andmebaasi ja saadab sinna kohe oma p\u00e4ringud, andmebaas t\u00f6\u00f6tleb neid ja t\u00e4idab, tulemused tagastatakse kliendile. Need on head ja \u00f5iged kliendid. <\/p>\n

<\/p>\n

M\u00f5nikord juhtub, et klient on \u00fchendatud, hoiab \u00fchendust, kuid ei tee selle samal ajal midagi. Ta on idle olekus. <\/p>\n

<\/p>\n

Kuid on ka halbu kliente. N\u00e4iteks, kui klient \u00fchendub, avab tehingu, teeb midagi andmebaasis ja seej\u00e4rel liigub koodi, et p\u00f6\u00f6rduda v\u00e4lise allika poole v\u00f5i teha seal andmete t\u00f6\u00f6tlemist. Kuid ta ei sule tehingut. Ja tehing j\u00e4\u00e4b andmebaasi rippuma ja hoiab rida lukus. See on halb olukord. Kui rakendus peaks kuskil eksitama (Exception), siis v\u00f5ib tehing j\u00e4\u00e4da avatud v\u00e4ga kauaks. Ja see m\u00f5jutab otseselt PostgreSQLi j\u00f5udlust. PostgreSQL t\u00f6\u00f6tab aeglasemalt. Seet\u00f5ttu on oluline selliseid kliente \u00f5igeaegselt j\u00e4lgida ja nende t\u00f6\u00f6 l\u00f5petada. Samuti on vajalik oma rakendust optimeerida, et sarnaseid olukordi v\u00e4ltida. <\/p>\n

<\/p>\n

Teised halvad kliendid on ootel kliendid. Kuid nad muutuvad halbadeks asjaolude t\u00f5ttu. N\u00e4iteks tavaline seisev tehing: klient v\u00f5ib avada tehingu, v\u00f5tta lukud m\u00f5nele reale, kuid seej\u00e4rel kukub see kuskil koodis ja j\u00e4\u00e4b riputama. Kui teine klient k\u00fcsib samu andmeid, siis ta seisab silmitsi lukustusega, kuna see rippuv tehing juba hoiab lukke m\u00f5nedele vajalikule reale. Ja teine tehing j\u00e4\u00e4b ootama, kuni esimene tehing l\u00f5petatakse v\u00f5i selle administraator sunniviisiliselt suletakse. Seega, ootavad tehingud v\u00f5ivad koguneda ja \u00fcletada andmebaasi \u00fchenduste piiri. Ja kui piir on \u00fcletatud, ei saa rakendus andmebaasi enam kasutada. See on projekti jaoks juba kriitiline olukord. Seet\u00f5ttu tuleb halbu kliente j\u00e4lgida ja neile \u00f5igeaegselt reageerida. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine n\u00e4ide j\u00e4lgimisest. Ja siin on korralik armatuurlaud. \u00dclemises osas on teave \u00fchenduste kohta. DB connection \u2013 8 t\u00fckki. Ja see on k\u00f5ik. Meil ei ole teavet selle kohta, millised kliendid on aktiivsed, millised kliendid lihtsalt ootavad, ei tee midagi. Ei ole teavet riputatud tehingute ja ootavate \u00fchenduste kohta, st see on lihtsalt number, mis n\u00e4itab \u00fchenduste arvu ja k\u00f5ik. Edasi m\u00f5elge ise.
\n\"PostgreSQL
\nSeega, et lisada see teave j\u00e4lgimisele, tuleb p\u00f6\u00f6rduda s\u00fcsteemi vaate pg_stat_activity poole. Kui veedate palju aega PostgreSQLis, on see v\u00e4ga hea vaade, mis peaks saama teie s\u00f5braks, kuna see n\u00e4itab hetkeaktiivsust PostgreSQLis, st mis seal toimub. Iga protsessi kohta on eraldi rida, mis n\u00e4itab teavet selle protsessi kohta: milliselt hostilt on \u00fchendus tehtud, kumba kasutajat kasutatakse, millise nimega, millal tehing k\u00e4ivitati, mis p\u00e4ring hetkel k\u00e4ib ja milline p\u00e4ring k\u00e4idi viimati. Seega saame kliendi seisundit hinnata v\u00e4ljaande stat j\u00e4rgi. \u00dctlemisi v\u00f5ib selle v\u00e4ljaande p\u00f5hjal grupeerida ja saada need stat\u2019id, mis andmebaasis on hetkel olemas, ja \u00fchenduste arvu, mis antud stat\u2019iga andmebaasi siseneb. Saadud numbreid saame edastada meie j\u00e4lgimisele ja joonistada neist graafikuid.
\nSamuti on oluline hinnata tehingu kestvust. Olen juba \u00f6elnud, et on oluline hinnata vakumeid, kuid tehinguid hinnatakse samamoodi. On v\u00e4ljaanded xact_start ja query_start. Need, \u00fctleme nii, n\u00e4itavad tehingu ja p\u00e4ringu k\u00e4ivitamise aega. Me v\u00f5tame funktsiooni now(), mis n\u00e4itab praegust ajam\u00e4rki, ja lahutame tehingu ja p\u00e4ringu timestamp\u2019id. Nii saame tehingu kestvuse ja p\u00e4ringu kestvuse. <\/p>\n

<\/p>\n

Kui n\u00e4eme pikki tehinguid, peame need l\u00f5petama. OLTP-koormuse korral on pikad tehingud need, mis kestavad \u00fcle 1-2-3 minuti.<\/strong>. OLAP-koormuse korral on pikad tehingud normaalsed, kuid kui need kestavad \u00fcle kahe tunni, siis on see samuti m\u00e4rk sellest, et kuskil on meil moonutus.<\/strong> <\/p>\n

<\/p>\n

\"PostgreSQL
\nKui kliendid on andmebaasiga \u00fchendatud, hakkavad nad t\u00f6\u00f6tama meie andmetega. Nad p\u00f6\u00f6rduvad tabelite poole, nad p\u00f6\u00f6rduvad indekste poole, et saada andmeid tabelist. On oluline hinnata, kuidas kliendid nende andmetega t\u00f6\u00f6tavad.<\/p>\n

<\/p>\n

See on vajalik meie t\u00f6\u00f6koormuse hindamiseks ja selleks, et m\u00f5ista, millised tabelid on k\u00f5ige \"kuumemad\". N\u00e4iteks on see kasulik olukordades, kus soovime \"kuumad\" tabelid paigutada kiirele SSD salvestusse. Samas v\u00f5ivad vanad arhiivtabelid, mida me enam ei kasuta, minna \u201ek\u00fclmale\u201c arhiivi SATA-diskidele, kus nad v\u00f5ivad j\u00e4\u00e4da ootele, ning nendele juurdep\u00e4\u00e4s toimub vajadusel. <\/p>\n

<\/p>\n

See on samuti kasulik erinevate anomaaliate tuvastamiseks p\u00e4rast uute versioonide ja juurutuste v\u00e4ljatoomist. Oleta, et projekt tutvustas uut funktsiooni. N\u00e4iteks lisati uus funktsionaalsus andmebaasiga t\u00f6\u00f6tamiseks. Kui me koostame tabelite kasutamise graafikud, saame nende graafikute pealt kergesti tuvastada need anomaaliad, n\u00e4iteks uuenduste (update) v\u00f5i kustutuste (delete) t\u00f5usud. See on v\u00e4ga selgelt j\u00e4lgitav.<\/p>\n

<\/p>\n

Samuti saab tuvastada anomaaliaid \"kallistatud\" statistikast. Mida see t\u00e4hendab? PostgreSQL-il on v\u00e4ga tugev ja hea p\u00e4ringute planeerija. Arendajad p\u00fchendavad palju aega selle arendamisele. Kuidas see t\u00f6\u00f6tab? Heade plaanide koostamiseks kogub PostgreSQL teatud ajavahemike j\u00e4rel statistikat tabelite andmete jaotuse kohta. See sisaldab k\u00f5ige sagedasemaid v\u00e4\u00e4rtusi: unikaalsete v\u00e4\u00e4rtuste arv, teave NULL v\u00e4\u00e4rtuste kohta tabelis ja palju muud teavet. <\/p>\n

<\/p>\n

Selle statistika p\u00f5hjal koostab planeerija mitu p\u00e4ringut, valib k\u00f5ige optimaalse v\u00f5i sobivama ning kasutab seda p\u00e4ringute plaani p\u00e4ringu t\u00e4itmiseks ja andmete tagastamiseks. <\/p>\n

<\/p>\n

Kuid v\u00f5ib juhtuda, et statistika \"ujub\". Tabelis on andmete kvaliteet ja hulk muutunud, kuid statistika ei ole selle ajaga uuendatud. Kujundatud plaanid v\u00f5ivad osutuda mitte-optimaalseteks. Ja kui meie plaanid osutuvad mitte-optimaalseteks kogutud j\u00e4lgimise p\u00f5hjal, tabelite osas, saame n\u00e4ha neid anomaaliaid. N\u00e4iteks on kusagil andmed kvaliteetselt muutunud ja koos indeksi kasutamisega kasutatakse j\u00e4rjestikku tabeli l\u00e4bilugemist, st kui p\u00e4ring peab tagastama vaid 100 rida (on seatud piirm\u00e4\u00e4r limit 100), siis selle p\u00e4ringu jaoks teostatakse t\u00e4ielik l\u00e4bilugemine. Ja see m\u00f5jutab alati tulemuslikkust v\u00e4ga negatiivselt. <\/p>\n

<\/p>\n

Ja saame seda j\u00e4lgida monitoorimises. Saame vaadata sellele p\u00e4ringule, teostada explain'i, koguda statistikat, luua uue t\u00e4iendava indeksi ja reageerida sellele probleemile. Seet\u00f5ttu on see oluline. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine monitoorimise n\u00e4ide. Ma arvan, et paljud tunnevad seda, 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 pool. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

On mitmeid graafikuid. Ja m\u00f5\u00f5t\u00fchikuna on n\u00e4idatud baite, st seal on 5 graafikut: Insert data, Update data, Delete data, Fetch data ja Return data. Kuid statistika PostgreSQL-is tagastab andmed tuple'is (rea kujul). Seet\u00f5ttu on need graafikud v\u00e4ga hea viis teie t\u00f6\u00f6koormuse alahindamiseks mitmekordselt, k\u00fcmnetesse kordades, sest tuple ei ole bait, tuple on rida, mis on palju baite ja on alati muutuva pikkusega. Seega, t\u00f6\u00f6koormuse arvutamine baidides kasutades tuplesid on ebarealistlik \u00fclesanne v\u00f5i v\u00e4ga keeruline. Seet\u00f5ttu, kui kasutate armatuurlauda v\u00f5i sisseehitatud monitooringut, on alati oluline m\u00f5ista, et see t\u00f6\u00f6tab \u00f5igesti ja tagastab teile t\u00e4pselt hinnatud andmed. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kuidas saada statistikat nende tabelite kohta? Selleks on PostgreSQL-is teatud vaate perede r\u00fchm. Peamine vaade on pg_stat_user_tables<\/a><\/noindex>. User_tables \u2013 see t\u00e4hendab, et tabelid on loodud kasutaja nimel. Vastandina on s\u00fcsteemivaatet, mida kasutab PostgreSQL ise. Ja on kokkuv\u00f5tte tabel Alltables, mis h\u00f5lmab nii s\u00fcsteemis kui ka kasutaja tabelit. Saate tugineda \u00fcksk\u00f5ik millisele, mis teile rohkem meeldib.<\/p>\n

<\/p>\n

\u00dclaltoodud v\u00e4ljade p\u00f5hjal on v\u00f5imalik hinnata insertide, update'ide ja delete'ide arvu. See armatuurlaud, mida ma kasutasin, kasutab just neid v\u00e4lju t\u00f6\u00f6koormuse omaduste hindamiseks. Seet\u00f5ttu saame ka neid kasutada. Kuid tuleb meeles pidada, et need on tuples, mitte baidid, seega ei saa me lihtsalt v\u00f5tta ja teha seda baidideks.<\/p>\n

<\/p>\n

Nende andmete p\u00f5hjal saame luua nn TopN-tabeleid. N\u00e4iteks Top-5, Top-10. Ja saab j\u00e4lgida neid kuumaid tabeleid, mida kasutatakse rohkem kui teisi. N\u00e4iteks 5 \"kuuma\" tabelit sisestamise osas. Ja nende TopN-tabelite p\u00f5hjal hindame oma t\u00f6\u00f6koormust ja suudame hinnata t\u00f6\u00f6koormuse piike p\u00e4rast erinevaid v\u00e4ljalaskmisi, uuendusi ja deploy'e. <\/p>\n

<\/p>\n

Samuti on oluline hinnata tabeli suurust, sest m\u00f5nikord arendajad kasutavad uut funktsionaalsust ning meie tabelid hakkavad suurendama oma mahtu, kuna otsustatakse lisada veel andmeid, kuid ei prognoosita, kuidas see m\u00f5jutab andmebaasi suurust. Sellised olukorrad v\u00f5ivad meie jaoks olla \u00fcllatuseks. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja n\u00fc\u00fcd on teil \u00fcks v\u00e4ike k\u00fcsimus. Milline k\u00fcsimus tekib, kui m\u00e4rkate andmebaasi serveri koormust? Milline j\u00e4rgmine k\u00fcsimus te tahate esitada? <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Aga tegelikult tekib j\u00e4rgnev k\u00fcsimus. Millised p\u00e4ringud p\u00f5hjustavad koormust? Ehk ei ole huvitav vaadata protsesse, mis koormust tekitavad. On selge, et kui host on andmebaasiga, siis seal t\u00f6\u00f6tab andmebaas ja seal ongi ainult andmebaasid. Kui me avame Top'i, siis n\u00e4eme seal PostgreSQL protsesside nimekirja, mis midagi teevad. Top'ist ei ole selge, mida nad teevad. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Seega tuleb tuvastada need p\u00e4ringud, mis p\u00f5hjustavad k\u00f5rgeima koormuse, kuna p\u00e4ringute h\u00e4\u00e4lestamine toob tavaliselt rohkem kasu kui PostgreSQL v\u00f5i operatsioonis\u00fcsteemi konfigureerimine v\u00f5i isegi riistvara h\u00e4\u00e4lestamine. Minu hinnangul on see umbes 80-85-90%. Ja seda on palju kiiremini teha. Kiirem on parandada p\u00e4ringut kui konfigureerida, planeerida taask\u00e4ivitust, eriti kui andmebaasi ei saa taask\u00e4ivitada, v\u00f5i lisada riistvara. Lihtsam on kuskil p\u00e4ringut \u00fcmber kirjutada v\u00f5i lisada indeks, et saada parem tulemus. <\/p>\n

<\/p>\n

\"PostgreSQL
\nSeega on vajalik j\u00e4lgida p\u00e4ringute adekvaatsust. V\u00f5tame teise n\u00e4ite j\u00e4lgimisest. Ja siin tundub ka imeline j\u00e4lgimine. On teave replikatsiooni, l\u00e4bilaskev\u00f5ime, lukustuste, ressursside kasutamise kohta. K\u00f5ik on suurep\u00e4rane, kuid puudub teave p\u00e4ringute kohta. Ei ole selge, millised p\u00e4ringud meie andmebaasis t\u00e4idetakse, kui kaua nad kestavad ja kui palju neid on. Me peame alati j\u00e4lgimises olema selle teabe olemasolu. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ja selle teabe saamiseks saame kasutada pg_stat_statements moodulit. Selle alusel on v\u00f5imalik koostada erinevaid graafikuid. N\u00e4iteks saame saada teavet k\u00f5ige sagedasemate p\u00e4ringute kohta, st nende p\u00e4ringute kohta, mis t\u00e4idetakse k\u00f5ige rohkem. Jah, p\u00e4rast juurutamisi on samuti v\u00e4ga kasulik sellele pilku heita ja aru saada, kas p\u00e4ringutes on toimunud m\u00f5ni j\u00e4rsk t\u00f5us. <\/p>\n

<\/p>\n

Saame j\u00e4lgida k\u00f5ige pikemaid p\u00e4ringuid, st neid p\u00e4ringuid, mis t\u00e4idetakse k\u00f5ige kauem. Need kasutavad protsessorit ja nad tarbivad sisendi-v\u00e4ljundi ressursse. Saame neid samuti hinnata 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, mis loevad kettalt, kas kasutavad m\u00e4lu v\u00f5i vastupidi, genereerivad kirjutuskoormust.<\/p>\n

<\/p>\n

Saame hinnata ka k\u00f5ige heldemaid p\u00e4ringuid. Need on p\u00e4ringud, mis tagastavad suurt hulka ridu. N\u00e4iteks v\u00f5ib see olla m\u00f5ni p\u00e4ring, millele ei pandud piiri ja see tagastab lihtsalt kogu tabeli sisu v\u00f5i p\u00e4ringute sisu, mis on k\u00fcsitud tabelitest.<\/p>\n

<\/p>\n

Samuti on v\u00f5imalik j\u00e4lgida p\u00e4ringuid, mis kasutavad ajutisi faile v\u00f5i ajutisi tabeleid. <\/p>\n

<\/p>\n

\"PostgreSQL
\nJa meil on j\u00e4\u00e4nud taustaprotsessid. Taustaprotsessid, eelk\u00f5ige kontrollpunktid v\u00f5i neid nimetatakse ka kontrollpunktideks, on autovakuu ja replikatsioon. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Teine n\u00e4ide j\u00e4lgimisest. Vasakul on hooldushulga vahekaart, l\u00e4heme sinna ja loodame n\u00e4ha midagi kasulikku. Kuid siin on vaid vakkuumi ja statistika kogumise t\u00f6\u00f6aeg, mitte rohkem. See on v\u00e4ga vaene teave, seet\u00f5ttu on alati oluline omada teavet selle kohta, kuidas meie andmebaasi taustaprotsessid toimivad ja kas nende t\u00f6\u00f6 on tekitanud probleeme. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kui vaatame kontrollpunkte, siis tuleb meeles pidada, et kontrollpunktid kirjutavad \u201er\u00e4pased\u201c lehed killustatud m\u00e4lust kettale ja loovad seej\u00e4rel kontrollpunkti. Ja see kontrollpunkt v\u00f5ib hiljem kasutada punktina taastamiseks, kui PostgreSQL peaks ootamatult sulgema. <\/p>\n

<\/p>\n

Seega, et k\u00f5ik \"r\u00e4past\" lehte kettale kirjutada, on vajalik teatud kirjutamise maht. Ja tavaliselt on s\u00fcsteemides, kus on suur m\u00e4lumaht, see v\u00e4ga suur. Ja kui meil on kontrollpunktid v\u00e4ga sageli l\u00fchikese aja jooksul, siis kettasuuruse tootlikkus langeb oluliselt. Ja kliendi p\u00e4ringud kannatavad ressursside nappuse all. Nad v\u00f5itlevad ressursside nimel ja neil puudub tootlikkus. <\/p>\n

<\/p>\n

Seega, kaudu pg_stat_bgwriter saame nimetatud valdkondade kaudu j\u00e4lgida tekkivate kontrollpunktide arvu. Ja kui meil on teatud ajavahemiku jooksul (10-15-20 minuti jooksul, pool tundi) v\u00e4ga palju kontrollpunkte, n\u00e4iteks 3-4-5, siis see v\u00f5ib juba olla probleem. Ja tuleb vaadata andmebaasi, vaadata konfiguratsiooni, mis p\u00f5hjustab sellist kontrollpunktide hulga. V\u00f5ib-olla toimub mingisugune suur kirjutamine. T\u00f6\u00f6kohustuse p\u00f5hjal saame juba hinnata, kuna meil on t\u00f6\u00f6koormuse graafikud juba lisatud. Me saame juba seadistada kontrollpunktide parameetreid ja teha nii, et need ei m\u00f5juta p\u00e4ringute tootlikkust liiga palju.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Ma tulen taas autovacuum'i juurde, sest see on asi, nagu ma juba \u00fctlesin, mis v\u00f5ib oluliselt m\u00f5jutada nii k\u00f5vaketaste kui ka p\u00e4ringute tootlikkust, seega on alati oluline hinnata autovacuum'i arvu. <\/p>\n

<\/p>\n

Andmebaasis on autovacuum'i t\u00f6\u00f6meeste arv piiratud. Vaikimisi on neid kolm, seega kui meil on kogu aeg kolm t\u00f6\u00f6meest andmebaasis, t\u00e4hendab see, et meie autovacuum on vale seadistusega, limiidid tuleb t\u00f5sta, autovacuum'i seadeid tuleb \u00fcle vaadata ja minna konfiguratsiooni.
\nOluline on hinnata, millised autovacuum'i t\u00f6\u00f6tajad meil on. Kas see on k\u00e4ivitatud kasutaja poolt, DBA tuli ja k\u00e4ivitas k\u00e4sitsi mingisuguse autovacuum'i, ja see tekitas koormuse. Meil tekkis m\u00f5ni probleem. V\u00f5i on see autovacuum'i hulk, mis keerab tehingute loendit. M\u00f5nede PostgreSQL versioonide jaoks on need v\u00e4ga rasked autovacuum'id. Ja need v\u00f5ivad kergesti m\u00f5jutada tootlikkust, kuna nad loevad kogu tabeli t\u00e4ielikult, skaneerivad k\u00f5ik plokid selles tabelis. <\/p>\n

<\/p>\n

Ja, ja ja vaak v\u00f5i jooksul. Kui meil on pikad vaakumid, mis t\u00f6\u00f6tavad v\u00e4ga kaua, siis see t\u00e4hendab, et peaksime uuesti vaatama vaakumi konfiguratsiooni ja v\u00f5ib-olla selle seadeid \u00fcle vaatama. Sest v\u00f5ib tekkida olukord, kus vaakum t\u00f6\u00f6tab tabeli kallal kaua (3-4 tundi), kuid selle t\u00f6\u00f6 jooksul on tabelisse kogunenud taas suur hulk surnud ridu. Ja niipea kui vaakum l\u00f5petab, peab see tabelit uuesti vaakumeerima. Ja me saame olukorra \u2013 l\u00f5putu vaakum. Ja sellisel juhul ei suuda vaakum oma t\u00f6\u00f6d t\u00e4ita ning tabelid hakkavad j\u00e4rk-j\u00e4rgult suurenenud m\u00f5\u00f5tmeid omandama, kuigi kasulik andmemaht j\u00e4\u00e4b samaks. Seet\u00f5ttu vaatame pikade vaakumite korral alati konfiguratsiooni ja p\u00fc\u00fcame seda optimeerida, kuid samas mitte kannatada kliendi p\u00e4ringute j\u00f5udluse all. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Praegu ei ole praktiliselt \u00fchtegi PostgreSQL installatsiooni, kus ei oleks voogedastust. Replikatsioon on andmete edastamise protsess meistrilt kopeerimisele.<\/p>\n

<\/p>\n

Replikatsioon PostgreSQL-is on korraldatud l\u00e4bi tehinguajaloos. Meister genereerib tehinguajaloo. Tehinguajalugu edastatakse v\u00f5rgu\u00fchenduse kaudu kopeerimisele, seej\u00e4rel kopeerimisel see taastatakse. K\u00f5ik on lihtne. <\/p>\n

<\/p>\n

Seega kasutatakse replikatsiooni viivituse j\u00e4lgimiseks vaadet pg_stat_replication. Kuid see ei ole nii lihtne. Versioonis 10 on vaade l\u00e4bi teinud mitmeid muudatusi. Esiteks, m\u00f5ned v\u00e4ljad on \u00fcmber nimetatud. Ja m\u00f5ned v\u00e4ljad on lisatud. 10. versioonis on ilmunud 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\u00e4i alles ka 10. versioonis, st saate valida, mis teile mugavam on \u2013 hinnata viivitust baitides v\u00f5i sekundites. Paljud teevad m\u00f5lemat.<\/p>\n

<\/p>\n

Kuid siiski, et hinnata replikatsiooni viivitust, on vaja teada ajalugu tehingus. Ja need tehinguajaloo positsioonid ongi vaates pg_stat_replication. \u00dctleme, et saame pg_xlog_location_diff() funktsiooni kaudu v\u00f5tta kaks punkti tehinguajaloos. 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 asendati k\u00f5ikides funktsioonides, vaadatud, utiliitides, kus esines s\u00f5na \u00abxlog\u00bb, see s\u00f5naga \u00abwal\u00bb. See kehtib nii vaadatud kui ka funktsioonide puhul. See on selline uuendus. <\/p>\n

<\/p>\n

10. versioonis lisandus ka rida, mis n\u00e4itab konkreetset viivitust. Need on write lag, flush lag, replay lag. Teisis\u00f5nu, neid asju on oluline j\u00e4lgida. Kui n\u00e4eme replikatsiooni viivitust, tuleb uurida, miks see ilmus, kust see tuli ja probleem lahendada. <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

S\u00fcsteemi m\u00f5\u00f5dikud on enamasti korras. Iga j\u00e4lgimise alguses alustatakse s\u00fcsteemi m\u00f5\u00f5dikutega. Need on protsessorite, m\u00e4lu, swap, v\u00f5rgu ja ketta kasutuse m\u00e4\u00e4r. Siiski ei ole seal palju parameetreid vaikimisi. <\/p>\n

<\/p>\n

Kui protsesside kasutus on korras, siis ketta kasutuses on probleeme. Reeglina lisavad j\u00e4lgimisriistade arendajad teavet l\u00e4bilaskvuse kohta. See v\u00f5ib olla iops v\u00f5i baitides. Kuid nad unustavad latentsuse ja ketta seadmete kasutuse. Need on olulisemad parameetrid, mis v\u00f5imaldavad hinnata, kui palju meie kettad on koormatud ja kui palju nad peatumisi tekitavad. Kui meil on k\u00f5rge latentsus, t\u00e4hendab see, et kettaga on mingeid probleeme. Kui meil on k\u00f5rge kasutus, t\u00e4hendab see, et kettad ei suuda hakkama saada.<\/strong> Need on kvaliteetsemad omadused kui l\u00e4bilaskvus.<\/p>\n

<\/p>\n

Kuigi seda statistikat saab ka failis\u00fcsteemist \/proc, nagu seda tehakse protsessorite kasutuse puhul. Miks seda teavet ei lisata j\u00e4lgimistesse, ma ei tea. Siiski on oluline, et see oleks teie j\u00e4lgimises.<\/strong> <\/p>\n

<\/p>\n

Sama kehtib v\u00f5rguinterfeisside kohta. V\u00f5rgu l\u00e4bilaskvuse kohta on teavet pakettide ja baitide kaupa, kuid siiski puudub teave latentsuse ja kasutuse kohta, kuigi see on samuti kasulik teave.<\/strong> <\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Igal j\u00e4lgimisel on puudused. \u00dcksk\u00f5ik millist j\u00e4lgimist te v\u00f5tate, see ei vasta alati mingitele kriteeriumidele. Siiski arenevad nad, lisatakse uusi funktsioone, uusi asju, seega valige midagi ja t\u00e4iustage seda. <\/p>\n

<\/p>\n

Ja et t\u00e4iustada, tuleb alati teada, mida annab antud statistika ja kuidas selle abil probleeme lahendada. <\/p>\n

<\/p>\n

Ja paar v\u00f5tmehetke:<\/p>\n

<\/p>\n