Grunnatriði PostgreSQL eftirlits. Alexey Lesovsky

Ég legg til að þú lesir afrit skýrslu Alexey Lesovsky frá Data Egret „Fundamentals of PostgreSQL monitoring“

Í þessari skýrslu mun Alexey Lesovsky tala um lykilatriði tölfræði eftir sókn, hvað þau þýða og hvers vegna þau ættu að vera til staðar í eftirliti; um hvaða línurit eigi að vera í vöktuninni, hvernig eigi að bæta þeim við og hvernig eigi að túlka þau. Skýrslan mun nýtast gagnagrunnsstjórnendum, kerfisstjórum og forriturum sem hafa áhuga á Postgres bilanaleit.

Mitt nafn er Alexey Lesovsky, ég er fulltrúi Data Egret fyrirtækið.

Nokkur orð um sjálfan mig. Ég byrjaði fyrir löngu síðan sem kerfisstjóri.

Ég stýrði alls kyns mismunandi Linux kerfum, vann við ýmislegt tengt Linux, þ.e. sýndarvæðingu, vöktun, vann með proxy o.s.frv. En á einhverjum tímapunkti fór ég að vinna meira með gagnagrunna, PostgreSQL. Mér líkaði mjög vel við hann. Og á einhverjum tímapunkti fór ég að vinna á PostgreSQL mestallan vinnutímann. Og svo smám saman varð ég PostgreSQL DBA.

Og allan minn feril hef ég alltaf haft áhuga á efni tölfræði, eftirlits og fjarmælinga. Og þegar ég var kerfisstjóri vann ég mjög náið með Zabbix. Og ég skrifaði lítið sett af handritum eins og zabbix-framlengingar. Hann var nokkuð vinsæll á sínum tíma. Og þar var hægt að fylgjast með mjög mismunandi mikilvægum hlutum, ekki bara Linux, heldur einnig ýmsum hlutum.

Núna er ég að vinna í PostgreSQL. Ég er nú þegar að skrifa annað sem gerir þér kleift að vinna með PostgreSQL tölfræði. Það er kallað pgCenter (grein um Habré - Tölfræði eftir sókn án tauga og spennu).

Smá inngangsorð. Hvaða aðstæður búa við viðskiptavinir okkar, viðskiptavinir okkar? Það er einhvers konar slys sem tengist gagnagrunninum. Og þegar búið er að endurheimta gagnagrunninn kemur deildarstjórinn eða þróunarstjórinn og segir: „Vinir, við þurfum að fylgjast með gagnagrunninum því eitthvað slæmt gerðist og við þurfum að koma í veg fyrir að þetta gerist í framtíðinni.“ Og hér byrjar það áhugaverða ferli að velja vöktunarkerfi eða aðlaga núverandi eftirlitskerfi þannig að þú getir fylgst með gagnagrunninum þínum - PostgreSQL, MySQL eða einhverjum öðrum. Og samstarfsmenn byrja að stinga upp á: „Ég heyrði að það væri til svona og svona gagnagrunnur. Við skulum nota það." Samstarfsmenn byrja að rífast hver við annan. Og á endanum kemur í ljós að við veljum einhvers konar gagnagrunn en PostgreSQL vöktun kemur frekar illa fram í honum og við þurfum alltaf að bæta einhverju við. Taktu nokkrar geymslur frá GitHub, klónaðu þær, aðlagðu forskriftir og aðlagaðu þau einhvern veginn. Og á endanum verður þetta einhvers konar handavinna.

Þess vegna mun ég í þessari ræðu reyna að gefa þér smá þekkingu á því hvernig á að velja vöktun ekki aðeins fyrir PostgreSQL, heldur einnig fyrir gagnagrunninn. Og gefðu þér þá þekkingu sem gerir þér kleift að ljúka eftirliti þínu til að fá einhvern ávinning af því, svo að þú getir fylgst með gagnasafni þínum með ávinningi, til að koma í veg fyrir komandi neyðartilvik sem geta komið upp.

Og hugmyndirnar sem verða í þessari skýrslu er hægt að laga beint að hvaða gagnagrunni sem er, hvort sem það er DBMS eða noSQL. Þess vegna er ekki bara til PostgreSQL, heldur verða margar uppskriftir um hvernig á að gera þetta í PostgreSQL. Það verða dæmi um fyrirspurnir, dæmi um aðila sem PostgreSQL hefur til að fylgjast með. Og ef DBMS þín hefur sömu hlutina sem gerir þér kleift að setja þá í eftirlit geturðu líka aðlagað þá, bætt þeim við og það verður gott.

Ég verð ekki í skýrslunni
tala um hvernig á að afhenda og geyma mælikvarða. Ég segi ekkert um eftirvinnslu gagna og framsetningu fyrir notanda. Og ég mun ekki segja neitt um viðvörun.
En þegar líður á söguna mun ég sýna mismunandi skjáskot af núverandi vöktun og einhvern veginn gagnrýna þau. En engu að síður mun ég reyna að nefna ekki vörumerki til að búa ekki til auglýsingar eða andstæðingur auglýsingar fyrir þessar vörur. Þess vegna eru allar tilviljanir tilviljunarkenndar og eftir ímyndunaraflinu.

Fyrst skulum við reikna út hvað eftirlit er. Eftirlit er mjög mikilvægt að hafa. Þetta skilja allir. En á sama tíma tengist eftirlit ekki viðskiptavöru og hefur ekki bein áhrif á hagnað fyrirtækisins, þannig að tíma er alltaf varið til eftirlits á eftirstöðvum. Ef við höfum tíma, þá gerum við eftirlit; ef við höfum ekki tíma, þá allt í lagi, við setjum það í bakdaginn og einhvern tíma munum við snúa aftur til þessara verkefna.

Þess vegna er vöktun oft ófullnægjandi og hefur enga áhugaverða hluti sem myndi hjálpa okkur að vinna betur með gagnagrunninn þegar við komum til viðskiptavina. Og því þarf alltaf að ljúka eftirliti.

Gagnagrunnar eru svo flóknir hlutir sem þarf líka að fylgjast með því gagnagrunnar eru geymsla upplýsinga. Og upplýsingar eru mjög mikilvægar fyrir fyrirtækið, þær geta ekki glatast á nokkurn hátt. En á sama tíma eru gagnagrunnar mjög flókið hugbúnaðarstykki. Þau samanstanda af miklum fjölda af íhlutum. Og það þarf að fylgjast með mörgum af þessum þáttum.

Ef við erum að tala sérstaklega um PostgreSQL, þá er hægt að tákna það í formi kerfis sem samanstendur af miklum fjölda íhluta. Þessir þættir hafa samskipti sín á milli. Og á sama tíma er PostgreSQL með svokallað Stats Collector undirkerfi, sem gerir þér kleift að safna tölfræði um rekstur þessara undirkerfa og útvega stjórnanda eða notanda einhvers konar viðmót svo hann geti skoðað þessa tölfræði.

Þessi tölfræði er sett fram í formi ákveðins mengis aðgerða og skoðana. Þeir geta líka verið kallaðir borð. Það er, með því að nota venjulegan psql biðlara geturðu tengst gagnagrunninum, valið þessar aðgerðir og skoðanir og fengið nokkrar sérstakar tölur um rekstur PostgreSQL undirkerfanna.

Þú getur bætt þessum tölum við uppáhalds eftirlitskerfið þitt, teiknað línurit, bætt við aðgerðum og fengið greiningar til lengri tíma litið.

En í þessari skýrslu mun ég ekki fjalla alveg um allar þessar aðgerðir, því það gæti tekið allan daginn. Ég mun bókstaflega fjalla um tvo, þrjá eða fjóra hluti og segja þér hvernig þeir hjálpa til við að gera eftirlitið betra.

Og ef við tölum um gagnagrunnseftirlit, hvað þarf þá að fylgjast með? Í fyrsta lagi þurfum við að fylgjast með aðgengi, því gagnagrunnurinn er þjónusta sem veitir viðskiptavinum aðgang að gögnum og við þurfum að fylgjast með aðgengi, og einnig veita nokkur eigindleg og megindleg einkenni þess.

Við þurfum líka að fylgjast með viðskiptavinum sem tengjast gagnagrunninum okkar, því þeir geta bæði verið venjulegir viðskiptavinir og skaðlegir viðskiptavinir sem geta skaðað gagnagrunninn. Einnig þarf að fylgjast með þeim og fylgjast með starfsemi þeirra.

Þegar viðskiptavinir tengjast gagnagrunninum er augljóst að þeir byrja að vinna með gögnin okkar, þannig að við þurfum að fylgjast með því hvernig viðskiptavinir vinna með gögnin: með hvaða töflum og í minna mæli með hvaða vísitölum. Það er, við þurfum að meta vinnuálagið sem skapast af viðskiptavinum okkar.

En vinnuálag felst auðvitað líka í beiðnum. Forrit tengjast gagnagrunninum, fá aðgang að gögnum með fyrirspurnum og því er mikilvægt að leggja mat á hvaða fyrirspurnir við höfum í gagnagrunninum, fylgjast með því að þær séu nægilegar, að þær séu ekki skökku skrifaðar, að endurskrifa þurfi og gera suma valkosti svo þeir virki hraðar. og með betri frammistöðu.

Og þar sem við erum að tala um gagnagrunn, þá er gagnagrunnurinn alltaf bakgrunnsferli. Bakgrunnsferlar hjálpa til við að viðhalda afköstum gagnagrunnsins á góðu stigi, þannig að þeir þurfa ákveðið magn af fjármagni fyrir sig til að starfa. Og á sama tíma geta þau skarast við beiðnir viðskiptavina, svo gráðugir bakgrunnsferli geta haft bein áhrif á frammistöðu beiðna viðskiptavina. Þess vegna þarf líka að fylgjast með þeim og rekja þær þannig að ekki verði röskun hvað varðar bakgrunnsferla.

Og allt þetta hvað varðar gagnagrunnseftirlit er áfram í kerfismælingunni. En með hliðsjón af því að flestir innviðir okkar eru að færast í skýin, þá hverfa kerfismælingar einstakra gestgjafa alltaf í bakgrunninn. En í gagnagrunnum eiga þau enn við og auðvitað er líka nauðsynlegt að fylgjast með kerfismælingum.

Allt er meira og minna í lagi með kerfismælingar, öll nútíma vöktunarkerfi styðja nú þegar þessa mælikvarða, en almennt séð duga sumir íhlutir enn ekki og sumu þarf að bæta við. Ég mun líka koma inn á þær, það verða nokkrar glærur um þær.

Fyrsti liður skipulagsins er aðgengi. Hvað er aðgengi? Aðgengi að mínum skilningi er hæfni grunnsins til að þjóna tengingum, þ.e.a.s. grunnurinn er hækkaður, hann, sem þjónusta, tekur við tengingum frá viðskiptavinum. Og þetta aðgengi er hægt að meta út frá ákveðnum eiginleikum. Það er mjög þægilegt að sýna þessa eiginleika á mælaborðum.

Allir vita hvað mælaborð eru. Þetta er þegar þú kíktir einu sinni á skjáinn þar sem nauðsynlegar upplýsingar eru teknar saman. Og þú getur strax ákvarðað hvort það er vandamál í gagnagrunninum eða ekki.
Í samræmi við það ætti aðgengi að gagnagrunninum og öðrum lykileinkennum alltaf að birtast á mælaborðum þannig að þessar upplýsingar séu við höndina og alltaf aðgengilegar þér. Nokkrar viðbótarupplýsingar sem nú þegar hjálpa til við rannsókn atvika, þegar sumar neyðartilvik eru rannsakaðar, þarf að setja þær á aukamælaborð eða fela þær í drilldown tengla sem leiða til eftirlitskerfis þriðja aðila.

Dæmi um eitt vel þekkt eftirlitskerfi. Þetta er mjög flott eftirlitskerfi. Hún safnar miklum gögnum en frá mínu sjónarhorni hefur hún undarlega hugmynd um mælaborð. Það er hlekkur til að „búa til mælaborð“. En þegar þú býrð til mælaborð, býrðu til lista yfir tvo dálka, lista yfir línurit. Og þegar þú þarft að skoða eitthvað byrjarðu að smella með músinni, fletta, leita að töflunni sem þú vilt. Og þetta tekur tíma, þ.e.a.s. það eru engin mælaborð sem slík. Það eru aðeins listar yfir töflur.

Hvað ættir þú að bæta við þessi mælaborð? Þú getur byrjað á slíkum eiginleikum eins og viðbragðstíma. PostgreSQL hefur pg_stat_statements útsýnið. Það er sjálfgefið óvirkt, en það er eitt af mikilvægu kerfissýnunum sem ætti alltaf að vera virkt og notað. Það geymir upplýsingar um allar hlaupandi fyrirspurnir sem hafa verið keyrðar í gagnagrunninum.

Í samræmi við það getum við byrjað á því að við getum tekið heildarframkvæmdartíma allra beiðna og deilt honum með fjölda beiðna með því að nota ofangreinda reiti. En þetta er meðalhitinn á spítalanum. Við getum byrjað á öðrum sviðum - lágmarksframkvæmdartími fyrirspurnar, hámark og miðgildi. Og við getum jafnvel smíðað hundraðshlutar; PostgreSQL hefur samsvarandi aðgerðir fyrir þetta. Og við getum fengið nokkrar tölur sem einkenna viðbragðstíma gagnagrunnsins okkar fyrir þegar kláraðar beiðnir, þ.e.a.s. við framkvæmum ekki falsa beiðnina „velja 1“ og skoðum svartímann, heldur greinum við svartímann fyrir þegar kláraðar beiðnir og drögum út. annaðhvort sérstaka mynd, eða við byggjum línurit út frá henni.

Einnig er mikilvægt að fylgjast með fjölda villna sem myndast í kerfinu. Og fyrir þetta geturðu notað pg_stat_database útsýnið. Við einbeitum okkur að xact_rollback sviðinu. Þessi reitur sýnir ekki aðeins fjölda afturköllunar sem eiga sér stað í gagnagrunninum heldur tekur einnig tillit til fjölda villna. Hlutfallslega séð getum við birt þessa mynd á mælaborðinu okkar og séð hversu margar villur við höfum eins og er. Ef það eru margar villur, þá er þetta góð ástæða til að skoða skrárnar og sjá hvers konar villur þær eru og hvers vegna þær eiga sér stað, og fjárfesta síðan og leysa þær.

Þú getur bætt við slíku eins og snúningshraðamæli. Þetta eru fjöldi viðskipta á sekúndu og fjöldi beiðna á sekúndu. Tiltölulega séð geturðu notað þessar tölur sem núverandi frammistöðu gagnagrunnsins þíns og fylgst með því hvort það séu toppar í beiðnum, toppar í viðskiptum, eða öfugt hvort gagnagrunnurinn sé vanhlaðinn vegna þess að einhver bakendi hefur bilað. Það er mikilvægt að horfa alltaf á þessa mynd og muna að fyrir verkefnið okkar er frammistaða af þessu tagi eðlileg, en gildin fyrir ofan og neðan eru nú þegar einhvers konar vandamál og óskiljanleg, sem þýðir að við þurfum að skoða hvers vegna þessar tölur eru svo hátt.

Til þess að áætla fjölda viðskipta getum við aftur vísað til pg_stat_database yfirlitsins. Við getum bætt við fjölda skuldbindinga og fjölda afturköllunar og fengið fjölda viðskipta á sekúndu.

Skilja allir að nokkrar beiðnir geta passað inn í eina færslu? Þess vegna eru TPS og QPS aðeins öðruvísi.

Hægt er að fá fjölda beiðna á sekúndu frá pg_stat_statements og reiknaðu einfaldlega summan af öllum fullgerðum beiðnum. Það er ljóst að við berum saman núverandi gildi við það fyrra, dragum það frá, fáum delta og fáum magnið.

Þú getur bætt við viðbótarmælingum ef þess er óskað, sem einnig hjálpa til við að meta framboð á gagnagrunninum okkar og fylgjast með því hvort það hafi verið einhver stöðvunartími.

Ein af þessum mælingum er spenntur. En spenntur í PostgreSQL er svolítið erfiður. Ég skal segja þér hvers vegna. Þegar PostgreSQL hefur byrjað byrjar spenntur að tilkynna. En ef á einhverjum tímapunkti, til dæmis, eitthvað verkefni var í gangi á nóttunni, kom OOM-drápari og stöðvaði PostgreSQL barnaferlið með valdi, þá í þessu tilfelli slítur PostgreSQL tengingu allra viðskiptavina, endurstillir rifna minnissvæðið og byrjar bata frá kl. síðasta eftirlitsstöðin. Og á meðan þessi endurheimt frá eftirlitsstöðinni varir tekur gagnagrunnurinn ekki við tengingum, þ.e.a.s. þetta ástand er hægt að meta sem niður í miðbæ. En spennutímateljarinn verður ekki endurstilltur vegna þess að hann tekur mið af ræsingartíma póstmeistara frá fyrstu stundu. Þess vegna er hægt að sleppa slíkum aðstæðum.

Þú ættir líka að fylgjast með fjölda ryksuga starfsmanna. Vita allir hvað autovacuum er í PostgreSQL? Þetta er áhugavert undirkerfi í PostgreSQL. Margar greinar hafa verið skrifaðar um hana, margar skýrslur hafa verið gerðar. Það eru miklar umræður um tómarúm og hvernig það eigi að virka. Margir telja það nauðsynlegt mein. En svona er þetta. Þetta er eins konar hliðstæða sorphirðu sem hreinsar úreltar útgáfur af línum sem engin þörf er á í neinum viðskiptum og losar um pláss í töflum og vísitölum fyrir nýjar línur.

Af hverju þarftu að fylgjast með því? Vegna þess að tómarúmið er stundum mjög sárt. Það eyðir miklu magni af fjármagni og beiðnir viðskiptavina fara að líða fyrir það.

Og það ætti að fylgjast með því í gegnum pg_stat_activity útsýnið, sem ég mun tala um í næsta kafla. Þessi sýn sýnir núverandi virkni í gagnagrunninum. Og með þessari starfsemi getum við fylgst með fjölda ryksuga sem eru að virka núna. Við getum fylgst með lofttæmum og séð að ef við höfum farið yfir mörkin, þá er þetta ástæða til að skoða PostgreSQL stillingarnar og á einhvern hátt hagræða virkni tómarúmsins.

Annað við PostgreSQL er að PostgreSQL er mjög veikur fyrir löngum viðskiptum. Sérstaklega frá viðskiptum sem hanga lengi og gera ekki neitt. Þetta er svokallað stat aðgerðalaus-í-viðskipti. Slík viðskipti halda læsingum og koma í veg fyrir að tómarúmið virki. Og fyrir vikið bólgna borðin og stækka. Og fyrirspurnir sem vinna með þessar töflur byrja að vinna hægar, vegna þess að þú þarft að moka allar gömlu útgáfur af línum frá minni yfir á disk og til baka. Þess vegna þarf líka að fylgjast með tímanum, lengd lengstu viðskiptanna, lengstu tómarúmsbeiðnirnar. Og ef við sjáum einhver ferli sem hafa verið í gangi í mjög langan tíma, þegar meira en 10-20-30 mínútur fyrir OLTP hleðslu, þá þurfum við að fylgjast með þeim og slíta þeim kröftuglega eða fínstilla forritið þannig að þeir eru ekki kallaðir og hanga ekki svo lengi. Fyrir greiningarvinnuálag eru 10-20-30 mínútur eðlilegar; það eru líka lengri.

Næst höfum við möguleika á tengdum viðskiptavinum. Þegar við höfum þegar búið til mælaborð og birt helstu tiltækileikamælikvarða á það, getum við einnig bætt við viðbótarupplýsingum um tengda viðskiptavini þar.

Upplýsingar um tengda viðskiptavini eru mikilvægar vegna þess að frá PostgreSQL sjónarhorni eru viðskiptavinir ólíkir. Það eru góðir viðskiptavinir og það eru slæmir viðskiptavinir.

Einfalt dæmi. Eftir viðskiptavin skil ég umsóknina. Forritið hefur tengst gagnagrunninum og byrjar strax að senda beiðnir sínar þangað, gagnagrunnurinn vinnur þær og framkvæmir þær og skilar niðurstöðunum til viðskiptavinarins. Þetta eru góðir og réttir viðskiptavinir.

Það eru aðstæður þegar viðskiptavinurinn hefur tengst, hann heldur tengingunni, en gerir ekkert. Það er í aðgerðalausu ástandi.

En það eru slæmir viðskiptavinir. Til dæmis tengdist sami viðskiptavinur, opnaði færslu, gerði eitthvað í gagnagrunninum og fór svo inn í kóðann, til dæmis til að fá aðgang að utanaðkomandi uppsprettu eða vinna úr mótteknum gögnum þar. En hann lokaði ekki viðskiptunum. Og viðskiptin hanga í gagnagrunninum og er haldið í lás á línunni. Þetta er slæmt ástand. Og ef skyndilega mistekst forrit einhvers staðar í sjálfu sér með undantekningu, þá geta viðskiptin verið opin í mjög langan tíma. Og þetta hefur bein áhrif á PostgreSQL árangur. PostgreSQL verður hægari. Þess vegna er mikilvægt að fylgjast með slíkum viðskiptavinum tímanlega og hætta störfum þeirra kröftuglega. Og þú þarft að fínstilla umsókn þína svo að slíkar aðstæður komi ekki upp.

Aðrir slæmir viðskiptavinir eru að bíða. En þeir verða slæmir vegna aðstæðna. Til dæmis, einföld aðgerðalaus viðskipti: það getur opnað viðskipti, tekið læsingar á sumum línum, þá einhvers staðar í kóðanum mun það mistakast og skilja eftir hangandi viðskipti. Annar viðskiptavinur mun koma og biðja um sömu gögn, en hann mun lenda í lás, vegna þess að þessi hangandi viðskipti eru nú þegar með læsingar á nokkrum nauðsynlegum línum. Og önnur færslan mun hanga og bíða eftir að fyrstu viðskiptunum ljúki eða stjórnandinn lokar henni með valdi. Þess vegna geta færslur í bið safnast saman og fyllt gagnagrunnstengingarmörkin. Og þegar mörkin eru full getur forritið ekki lengur unnið með gagnagrunninum. Þetta er nú þegar neyðarástand fyrir verkefnið. Þess vegna þarf að fylgjast með slæmum viðskiptavinum og bregðast við þeim tímanlega.

Annað dæmi um eftirlit. Og hér er nú þegar ágætis mælaborð. Það eru upplýsingar um tengingar hér að ofan. DB tengi – 8 stykki. Og það er allt. Við höfum engar upplýsingar um hvaða viðskiptavinir eru virkir, hvaða viðskiptavinir eru bara aðgerðalausir og gera ekki neitt. Það eru engar upplýsingar um væntanleg viðskipti og biðtengingar, þ.e.a.s. þetta er mynd sem sýnir fjölda tenginga og það er allt. Og gettu svo sjálfur.

Í samræmi við það, til að bæta þessum upplýsingum við vöktun, þarftu að opna pg_stat_activity kerfisskjáinn. Ef þú eyðir miklum tíma í PostgreSQL, þá er þetta mjög gott útsýni sem ætti að verða vinur þinn, því það sýnir núverandi virkni í PostgreSQL, þ.e.a.s. hvað er að gerast í því. Fyrir hvert ferli er sérstök lína sem sýnir upplýsingar um þetta ferli: frá hvaða hýsil tengingin var gerð, undir hvaða notanda, undir hvaða nafni, hvenær viðskiptin voru hafin, hvaða beiðni er í gangi, hvaða beiðni var síðast framkvæmd. Og í samræmi við það getum við metið ástand viðskiptavinarins með því að nota tölfræðireitinn. Tiltölulega séð getum við flokkað eftir þessu sviði og fengið þá tölfræði sem er í gagnagrunninum og fjölda tenginga sem hafa þessa tölfræði í gagnagrunninum. Og við getum sent tölurnar sem þegar hafa borist í eftirlitið okkar og teiknað línurit út frá þeim.
Það er einnig mikilvægt að meta lengd viðskiptanna. Ég sagði þegar að það er mikilvægt að leggja mat á lengd tómarúma, en viðskipti eru metin á sama hátt. Það eru xact_start og query_start reitir. Þeir, tiltölulega séð, sýna upphafstíma viðskiptanna og upphafstíma beiðninnar. Við tökum now() fallið, sem sýnir núverandi tímastimpil, og drögum færsluna frá og biðjum um tímastimpil. Og við fáum lengd viðskiptanna, lengd beiðninnar.

Ef við sjáum löng viðskipti ættum við að ljúka þeim þegar. Fyrir OLTP hleðslu eru löng viðskipti nú þegar meira en 1-2-3 mínútur. Fyrir OLAP vinnuálag eru langar færslur eðlilegar, en ef þær taka meira en tvær klukkustundir að klára þá er þetta líka merki um að við séum með skekkju einhvers staðar.

Þegar viðskiptavinir hafa tengst gagnagrunninum byrja þeir að vinna með gögnin okkar. Þeir fá aðgang að töflum, þeir fá aðgang að vísitölum til að fá gögn úr töflunni. Og það er mikilvægt að meta hvernig viðskiptavinir hafa samskipti við þessi gögn.

Þetta er nauðsynlegt til að meta vinnuálag okkar og skilja í grófum dráttum hvaða töflur eru „heitastar“ fyrir okkur. Til dæmis er þetta nauðsynlegt í aðstæðum þar sem við viljum setja „heit“ borð á einhvers konar hraðvirka SSD geymslu. Til dæmis er hægt að færa sumar geymslutöflur sem við höfum ekki notað í langan tíma í einhvers konar „kalt“ skjalasafn, yfir á SATA drif og láta þær búa þar, þær verða aðgengilegar eftir þörfum.

Þetta er einnig gagnlegt til að greina frávik eftir allar útgáfur og dreifingar. Segjum að verkefnið hafi gefið út nýja eiginleika. Til dæmis bættum við við nýjum virkni til að vinna með gagnagrunninn. Og ef við teiknum töflunotkunargröf, getum við auðveldlega greint þessi frávik á þessum línuritum. Til dæmis, uppfæra bursts eða eyða bursts. Það verður mjög sýnilegt.

Þú getur líka greint frávik í „fljótandi“ tölfræði. Hvað þýðir það? PostgreSQL er með mjög sterkan og mjög góðan fyrirspurnaáætlun. Og teymið verja miklum tíma í þróun þess. Hvernig virkar hann? Til þess að gera góðar áætlanir safnar PostgreSQL tölfræði um dreifingu gagna í töflum á ákveðnu tímabili og með ákveðinni tíðni. Þetta eru algengustu gildin: fjöldi einstakra gilda, upplýsingar um NULL í töflunni, mikið af upplýsingum.

Byggt á þessari tölfræði, smíðar skipuleggjandi nokkrar fyrirspurnir, velur þá bestu og notar þessa fyrirspurnaráætlun til að framkvæma fyrirspurnina sjálfa og skila gögnum.

Og það gerist að tölfræðin „fljóta“. Gæða- og magngögnin breyttust einhvern veginn í töflunni, en tölfræðinni var ekki safnað. Og áætlanirnar sem myndast eru kannski ekki ákjósanlegar. Og ef áætlanir okkar reynast óhagkvæmar miðað við vöktunina sem safnað hefur verið, byggt á töflunum, munum við geta séð þessi frávik. Til dæmis, einhvers staðar breyttust gögnin eigindlega og í stað vísitölunnar var farið að nota raðleið í gegnum töfluna, þ.e. ef fyrirspurn þarf að skila aðeins 100 línum (það er hámark 100), þá verður fullkomin leit gerð að þessari fyrirspurn. Og þetta hefur alltaf mjög slæm áhrif á frammistöðu.

Og við getum séð þetta í eftirliti. Og skoðaðu nú þegar þessa fyrirspurn, keyrðu útskýringu fyrir hana, safnaðu tölfræði, byggðu nýja viðbótarvísitölu. Og þegar brugðist við þessu vandamáli. Þess vegna er það mikilvægt.

Annað dæmi um eftirlit. Ég held að margir hafi kannast við hann því hann er mjög vinsæll. Hver notar það í verkefnum sínum Prometheus? Hver notar þessa vöru í tengslum við Prometheus? Staðreyndin er sú að í stöðluðu geymslunni fyrir þessa vöktun er mælaborð til að vinna með PostgreSQL - postgres_exporter Prómeþeifs. En það er eitt slæmt smáatriði.

Það eru nokkur línurit. Og bæti eru sýnd sem eining, þ.e. það eru 5 línurit. Þetta eru Setja inn gögn, Uppfæra gögn, Eyða gögnum, Sækja gögn og Skila gögnum. Mælingin er bæti. En málið er að tölfræði í PostgreSQL skilar gögnum í tuple (raðir). Og í samræmi við það eru þessi línurit mjög góð leið til að vanmeta vinnuálag þitt nokkrum sinnum, tugum sinnum, vegna þess að tuple er ekki bæti, tuple er strengur, það er mörg bæti og það er alltaf breytilegt að lengd. Það er, að reikna út vinnuálag í bætum með því að nota tuples er óraunhæft verkefni eða mjög erfitt. Þess vegna, þegar þú notar mælaborð eða innbyggt eftirlit, er alltaf mikilvægt að skilja að það virkar rétt og skilar þér rétt metnum gögnum.

Hvernig á að fá tölfræði um þessar töflur? Í þessu skyni hefur PostgreSQL ákveðna fjölskyldu skoðana. Og meginsjónarmiðið er pg_stat_user_tables. User_tables - þetta þýðir töflur búnar til fyrir hönd notandans. Aftur á móti eru til kerfisskoðanir sem eru notaðar af PostgreSQL sjálfu. Og það er yfirlitstafla Alltables, sem inniheldur bæði kerfi og notendur. Þú getur byrjað á hvaða þeirra sem þér líkar best.

Með því að nota ofangreinda reiti er hægt að áætla fjölda innskots, uppfærslu og eyðingar. Dæmið um mælaborð sem ég notaði notar þessa reiti til að meta eiginleika vinnuálags. Þess vegna getum við líka byggt á þeim. En það er þess virði að muna að þetta eru tuples, ekki bæti, svo við getum ekki bara gert það í bætum.

Út frá þessum gögnum getum við smíðað svokallaðar TopN töflur. Til dæmis, Top-5, Top-10. Og þú getur fylgst með þessum heitu borðum sem eru endurunnin meira en önnur. Til dæmis, 5 „heitar“ töflur til innsetningar. Og með því að nota þessar TopN töflur metum við vinnuálag okkar og getum metið vinnuálag eftir allar útgáfur, uppfærslur og uppfærslur.

Það er líka mikilvægt að meta stærð töflunnar, því stundum setja forritarar nýjan eiginleika út og töflurnar okkar byrja að vaxa í stórum stærðum, vegna þess að þeir ákváðu að bæta við viðbótarmagni af gögnum, en spáðu ekki fyrir um hvernig þetta myndi hafa áhrif á stærð gagnagrunnsins. Svona mál koma okkur líka á óvart.

Og nú smá spurning til þín. Hvaða spurning vaknar þegar þú tekur eftir álaginu á gagnagrunnsþjóninum þínum? Hver er næsta spurning sem þú hefur?

En í raun vaknar spurningin sem hér segir. Hvaða beiðnum veldur álagið? Það er að segja að það er ekki áhugavert að skoða ferla sem stafa af álaginu. Ljóst er að ef hýsingaraðili er með gagnagrunn þá er gagnagrunnurinn í gangi þar og ljóst að þar verður aðeins gagnagrunninum fargað. Ef við opnum Top, munum við sjá þar lista yfir ferla í PostgreSQL sem eru að gera eitthvað. Það verður ekki ljóst af Top hvað þeir eru að gera.

Í samræmi við það þarftu að finna þær fyrirspurnir sem valda mestu álaginu, því að stilla fyrirspurnir gefur að jafnaði meiri hagnað en að stilla PostgreSQL eða stýrikerfisstillingar, eða jafnvel stilla vélbúnaðinn. Samkvæmt mati mínu er þetta um það bil 80-85-90%. Og þetta er gert miklu hraðar. Það er fljótlegra að leiðrétta beiðni en að leiðrétta stillingarnar, skipuleggja endurræsingu, sérstaklega ef ekki er hægt að endurræsa gagnagrunninn eða bæta við vélbúnaði. Það er auðveldara að endurskrifa fyrirspurnina einhvers staðar eða bæta við vísitölu til að fá betri niðurstöðu úr þessari fyrirspurn.

Í samræmi við það er nauðsynlegt að fylgjast með beiðnum og að þær séu fullnægjandi. Tökum annað dæmi um eftirlit. Og hér virðist líka vera frábært eftirlit. Það eru upplýsingar um afritun, það eru upplýsingar um afköst, blokkun, auðlindanýtingu. Allt er í lagi, en það eru engar upplýsingar um beiðnir. Það er ekki ljóst hvaða fyrirspurnir eru í gangi í gagnagrunninum okkar, hversu lengi þær eru í gangi, hversu margar af þessum fyrirspurnum eru. Við þurfum alltaf að hafa þessar upplýsingar í eftirliti okkar.

Og til að fá þessar upplýsingar getum við notað pg_stat_statements eininguna. Byggt á því geturðu smíðað margs konar línurit. Til dæmis er hægt að fá upplýsingar um algengustu fyrirspurnirnar, það er að segja um þær fyrirspurnir sem eru keyrðar oftast. Já, eftir dreifingu er líka mjög gagnlegt að skoða það og skilja hvort það er einhver aukning í beiðnum.

Þú getur fylgst með lengstu fyrirspurnunum, það er þeim fyrirspurnum sem taka lengstan tíma að ljúka. Þeir keyra á örgjörvanum, þeir neyta I/O. Við getum líka metið þetta með því að nota reitina total_time, mean_time, blk_write_time og blk_read_time.

Við getum metið og fylgst með þyngstu beiðnum hvað varðar auðlindanotkun, þær sem lesa af diski, sem vinna með minni, eða öfugt, skapa einhvers konar skrifhleðslu.

Við getum metið örlátustu beiðnirnar. Þetta eru fyrirspurnirnar sem skila miklum fjölda lína. Þetta gæti til dæmis verið einhver beiðni þar sem gleymdist að setja takmörk. Og það skilar einfaldlega öllu innihaldi töflunnar eða fyrirspurnarinnar yfir fyrirspurðar töflur.

Og þú getur líka fylgst með fyrirspurnum sem nota tímabundnar skrár eða tímabundnar töflur.

Og við höfum enn bakgrunnsferli. Bakgrunnsferlar eru fyrst og fremst eftirlitsstöðvar eða þeir eru einnig kallaðir eftirlitsstöðvar, þetta eru sjálfvirkt tómarúm og afritun.

Annað dæmi um eftirlit. Það er Viðhaldsflipi til vinstri, farðu á hann og vonandi sjáum við eitthvað gagnlegt. En hér er aðeins tími tómarúmsreksturs og tölfræðisöfnunar, ekkert annað. Þetta eru mjög lélegar upplýsingar og því þurfum við alltaf að hafa upplýsingar um hvernig bakgrunnsferlar virka í gagnagrunninum okkar og hvort það séu einhver vandamál í vinnu þeirra.

Þegar við skoðum eftirlitsstöðvar ættum við að muna að eftirlitsstöðvar skola óhreinum síðum frá rifnu minnissvæðinu yfir á disk og búa síðan til eftirlitsstöð. Og þetta eftirlitsstöð er síðan hægt að nota sem stað fyrir bata ef PostgreSQL var skyndilega hætt í neyðartilvikum.

Í samræmi við það, til að skola allar „óhreinu“ síðurnar á diskinn, þarftu að skrifa ákveðið magn. Og að jafnaði, á kerfum með mikið magn af minni, er þetta mikið. Og ef við gerum eftirlitsstöðvar mjög oft með stuttu millibili, þá mun afköst disksins lækka mjög verulega. Og beiðnir viðskiptavina munu þjást af skorti á fjármagni. Þeir munu keppa um auðlindir og skortir framleiðni.

Í samræmi við það, í gegnum pg_stat_bgwriter með því að nota tilgreinda reiti, getum við fylgst með fjölda eftirlitsstöðva sem eiga sér stað. Og ef við erum með mikið af eftirlitsstöðvum á ákveðnum tíma (á 10-15-20 mínútum, á hálftíma), til dæmis, 3-4-5, þá getur þetta nú þegar verið vandamál. Og þú þarft nú þegar að skoða í gagnagrunninum, skoða í stillingunum, hvað veldur slíkum gnægð af eftirlitsstöðvum. Kannski er einhver stór upptaka í gangi. Við getum nú þegar metið vinnuálagið, vegna þess að við höfum þegar bætt við vinnuálagsgröfum. Við getum nú þegar fínstillt færibreytur eftirlitsstaða og gengið úr skugga um að þær hafi ekki mikil áhrif á árangur fyrirspurna.

Ég er að koma aftur að autovacuum aftur vegna þess að það er svoleiðis hlutur, eins og ég sagði, sem getur auðveldlega bætt upp bæði disknum og fyrirspurnarafköstum, svo það er alltaf mikilvægt að áætla magn autovacuum.

Fjöldi sjálfvirkra ryksuga í gagnagrunninum er takmarkaður. Sjálfgefið eru þeir þrír, þannig að ef við erum alltaf með þrjá starfsmenn sem vinna í gagnagrunninum þýðir þetta að sjálfvirka tómarúmið okkar er ekki stillt, við þurfum að hækka mörkin, endurskoða sjálfvirka tómarúmsstillingarnar og komast inn í uppsetninguna.
Það er mikilvægt að leggja mat á hvaða ryksugumenn við höfum. Annað hvort var það ræst frá notandanum, DBA kom og setti handvirkt upp einhvers konar tómarúm, og þetta skapaði álag. Við höfum einhvers konar vandamál. Eða þetta er fjöldi ryksuga sem skrúfa færsluteljarann ​​af. Fyrir sumar útgáfur af PostgreSQL eru þetta mjög þungar ryksugur. Og þeir geta auðveldlega lagt saman frammistöðuna vegna þess að þeir lesa alla töfluna, skanna alla blokkina í þeirri töflu.

Og, auðvitað, lengd tómarúma. Ef við erum með langvarandi tómarúm sem keyra í mjög langan tíma, þá þýðir þetta að við þurfum aftur að huga að lofttæmistillingunni og ef til vill endurskoða stillingar hennar. Vegna þess að sú staða getur komið upp þegar tómarúmið vinnur á borðinu í langan tíma (3-4 klst), en á þeim tíma sem tómarúmið var að vinna, tókst aftur að safnast mikið magn af dauðum röðum í borðið. Og um leið og tómarúminu er lokið þarf hann að ryksuga þetta borð aftur. Og við komum að aðstæðum - endalausu tómarúmi. Og í þessu tilviki tekst tómarúmið ekki við vinnu sína og töflurnar byrja smám saman að bólgna í stærð, þó að rúmmál gagnlegra gagna í því sé það sama. Þess vegna, á löngum tómarúmum, skoðum við alltaf uppsetninguna og reynum að fínstilla hana, en á sama tíma þannig að frammistaða beiðna viðskiptavina verði ekki fyrir skaða.

Nú á dögum er nánast engin PostgreSQL uppsetning sem er ekki með straumafritun. Afritun er ferlið við að flytja gögn frá meistara yfir í eftirmynd.

Afritun í PostgreSQL er gerð í gegnum viðskiptaskrá. Töframaðurinn býr til viðskiptadagbók. Færsluskráin fer yfir nettenginguna til eftirmyndarinnar og síðan er hún afrituð á eftirmyndinni. Það er einfalt.

Í samræmi við það er pg_stat_replication viewið notað til að fylgjast með afritunartöfinni. En ekki er allt einfalt með hana. Í útgáfu 10 hefur útsýnið tekið nokkrum breytingum. Í fyrsta lagi hafa sumir reiti verið endurnefndir. Og nokkrum sviðum hefur verið bætt við. Í útgáfu 10 birtust reitir sem gera þér kleift að áætla afritunartöfina á nokkrum sekúndum. Það er mjög þægilegt. Fyrir útgáfu 10 var hægt að áætla afritunartöfina í bætum. Þessi valkostur er áfram í útgáfu 10, þ.e.a.s. þú getur valið það sem er þægilegra fyrir þig - metið töfina í bætum eða metið töfina í sekúndum. Margir gera hvort tveggja.

En engu að síður, til þess að meta afritunartöfina, þarftu að vita staðsetningu logsins í viðskiptunum. Og þessar færsluskrárstöður eru nákvæmlega í pg_stat_replication útsýninu. Tiltölulega séð getum við tekið tvo punkta í viðskiptaskránni með því að nota pg_xlog_location_diff() aðgerðina. Reiknaðu delta á milli þeirra og fáðu afritunartöfina í bætum. Það er mjög þægilegt og einfalt.

Í útgáfu 10 var þessari aðgerð breytt í pg_wal_lsn_diff(). Almennt séð, í öllum aðgerðum, skoðunum og tólum þar sem orðið „xlog“ birtist, var því skipt út fyrir gildið „wal“. Þetta á bæði við um skoðanir og aðgerðir. Þetta er þvílík nýjung.

Auk þess var í útgáfu 10 bætt við línum sem sýna töfina sérstaklega. Þetta eru rittöf, flush lag, endurspilunartöf. Það er, það er mikilvægt að fylgjast með þessum hlutum. Ef við sjáum að við höfum afritunartöf, þá þurfum við að rannsaka hvers vegna það birtist, hvaðan það kom og laga vandamálið.

Næstum allt er í lagi með kerfismælingar. Þegar einhver vöktun hefst byrjar hún með kerfismælingum. Þetta er förgun á örgjörvum, minni, skipti, neti og diski. Hins vegar eru margar breytur ekki þar sjálfgefið.

Ef allt er í lagi með endurvinnsluferlið, þá eru vandamál með endurvinnslu diska. Að jafnaði bæta eftirlitshönnuðir við upplýsingum um afköst. Það getur verið í iops eða bæti. En þeir gleyma leynd og nýtingu diskatækja. Þetta eru mikilvægari breytur sem gera okkur kleift að meta hversu hlaðnir diskarnir okkar eru og hversu hægir þeir eru. Ef við höfum mikla leynd, þá þýðir þetta að það eru einhver vandamál með diskana. Ef við höfum mikla nýtingu þýðir það að diskarnir eru ekki að takast á við. Þetta eru betri eiginleikar en afköst.

Þar að auki er einnig hægt að nálgast þessa tölfræði úr /proc skráarkerfinu, eins og gert er fyrir endurvinnsluvinnsluaðila. Ég veit ekki hvers vegna þessum upplýsingum er ekki bætt við eftirlit. En engu að síður er mikilvægt að hafa þetta í eftirliti þínu.

Sama á við um netviðmót. Það eru upplýsingar um netafköst í pökkum, í bætum, en engu að síður eru engar upplýsingar um leynd og engar upplýsingar um nýtingu, þó þetta séu líka gagnlegar upplýsingar.

Öll eftirlit hefur galla. Og það er sama hvers konar eftirlit þú tekur, það mun alltaf ekki uppfylla einhver skilyrði. En engu að síður eru þau að þróast, nýir eiginleikar og nýir hlutir bætast við, svo veldu eitthvað og kláraðu það.

Og til að klára verður þú alltaf að hafa hugmynd um hvað tölfræðin sem gefnar er þýða og hvernig þú getur notað hana til að leysa vandamál.

Og nokkur lykilatriði:

• Þú ættir alltaf að fylgjast með framboði og hafa mælaborð svo þú getir fljótt metið að allt sé í lagi með gagnagrunninn.
• Þú þarft alltaf að hafa hugmynd um hvaða viðskiptavinir eru að vinna með gagnagrunninn þinn til að eyða slæmum viðskiptavinum og skjóta þá niður.
• Mikilvægt er að meta hvernig þessir viðskiptavinir vinna með gögn. Þú þarft að hafa hugmynd um vinnuálag þitt.
• Mikilvægt er að meta hvernig þetta vinnuálag myndast, með hjálp hvaða fyrirspurna. Þú getur metið fyrirspurnir, þú getur fínstillt þær, endurskoðað þær, byggt upp vísitölur fyrir þær. Það er mjög mikilvægt.
• Bakgrunnsferli geta haft neikvæð áhrif á beiðnir viðskiptavina, svo það er mikilvægt að fylgjast með því að þeir noti ekki of mikið úrræði.
• Kerfismælingar gera þér kleift að gera áætlanir um stigstærð og auka getu netþjónanna þinna, svo það er mikilvægt að fylgjast með og meta þá líka.

Ef þú hefur áhuga á þessu efni, þá geturðu fylgst með þessum krækjum.
http://bit.do/stats_collector - þetta er opinber skjöl frá tölfræðisafnara. Þar er lýsing á öllum tölfræðilegum skoðunum og lýsing á öllum sviðum. Þú getur lesið, skilið og greint þær. Og byggðu á þeim, byggðu línuritin þín og bættu þeim við eftirlitið þitt.

Dæmi um beiðnir:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Þetta er fyrirtækjageymslan okkar og mín eigin. Þær innihalda dæmi um fyrirspurnir. Það eru engar fyrirspurnir frá select* úr röðinni þar. Það eru þegar til tilbúnar fyrirspurnir með sameiningum, með áhugaverðum aðgerðum sem gera þér kleift að breyta hráum tölum í læsileg, þægileg gildi, þ.e. þetta eru bæti, tími. Þú getur tekið þau upp, skoðað þau, greint þau, bætt þeim við eftirlit þitt, byggt eftirlit þitt út frá þeim.

spurningar

Spurning: Þú sagðir að þú myndir ekki auglýsa vörumerki, en ég er samt forvitinn - hvers konar mælaborð notar þú í verkefnum þínum?
Svar: Það er mismunandi. Það kemur fyrir að við komum til viðskiptavinar og hann hefur nú þegar sitt eigið eftirlit. Og við ráðleggjum viðskiptavinum hvað þarf að bæta við eftirlit hans. Verst er ástandið hjá Zabbix. Vegna þess að það hefur ekki getu til að byggja TopN línurit. Við sjálf notum Okmeter, vegna þess að við vorum að ráðfæra okkur við þessa krakka um eftirlit. Þeir fylgdust með PostgreSQL út frá tækniforskriftum okkar. Ég er að skrifa mitt eigið gæludýraverkefni, sem safnar gögnum í gegnum Prometheus og skilar þeim inn grafana. Verkefni mitt er að búa til minn eigin útflutningsaðila í Prometheus og prenta svo allt í Grafana.

Spurning: Eru til einhverjar hliðstæður AWR skýrslna eða... samansöfnun? Veistu um eitthvað svona?
Svar: Já, ég veit hvað AWR er, það er töff hlutur. Í augnablikinu eru til margs konar reiðhjól sem útfæra um það bil eftirfarandi gerð. Með einhverju millibili eru sumar grunnlínur skrifaðar í sama PostgreSQL eða í sérstaka geymslu. Þú getur gúglað þær á netinu, þær eru til. Einn af þróunaraðilum slíks er að sitja á sql.ru spjallborðinu í PostgreSQL þræðinum. Þú getur náð honum þar. Já, það eru til svona hlutir, það er hægt að nota þá. Plús í sínu pgCenter Ég er líka að skrifa hlut sem gerir þér kleift að gera það sama.

PS1 Ef þú ert að nota postgres_exporter, hvaða mælaborð ertu að nota? Þeir eru nokkrir. Þær eru þegar gamaldags. Kannski mun samfélagið búa til uppfært sniðmát?

PS2 Fjarlægt pganalyze vegna þess að það er sér SaaS tilboð sem leggur áherslu á frammistöðueftirlit og sjálfvirkar stillingartillögur.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Hvaða sjálfstýrða postgresql vöktun (með mælaborði) finnst þér best?

• 30,0%Zabbix + viðbætur frá Alexey Lesovsky eða zabbix 4.4 eða libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze er sér SaaS - ég get ekki eytt því1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 notendur kusu. 26 notendur sátu hjá.

Heimild: www.habr.com