Data Egret-eko Alexey Lesovsky-ren txostenaren transkripzioa irakurtzea gomendatzen dizut "PostgreSQL Monitoring-en Oinarriak"
Txosten honetan, Alexey Lesovsky-k postgres estatistiken funtsezko puntuei buruz hitz egingo du, zer esan nahi duten eta zergatik sartu behar diren jarraipenean; monitorizazioan zer grafiko izan behar duten, nola gehitu eta nola interpretatu. Txostena erabilgarria izango da Postgres-en arazoak konpontzeko interesa duten datu-baseen administratzaileentzat, sistema-administratzaileentzat eta garatzaileentzat.
Nire izena Alexey Lesovsky da, Data Egret ordezkatzen dut.
Niri buruz hitz batzuk. Aspaldi hasi nintzen sistemaren administratzaile gisa.
Linux mota guztiak administratu nituen, Linuxekin erlazionatutako hainbat gauza egin nituen, hau da, birtualizazioa, monitorizazioa, proxyekin lan egin, etab. Baina noizbait datu-baseetan gehiago sartu nintzen, PostgreSQL. Asko gustatu zitzaidan. Eta uneren batean, PostgreSQL-rekin lan egiten hasi nintzen nire lan-denbora gehiena. Eta horrela pixkanaka PostgreSQL DBA bihurtu nintzen.
Eta nire karreran zehar, estatistikak, monitorizazioa, telemetria gaiak interesatu izan zaizkit beti. Eta sistema administratzaile nintzenean, oso gogor lan egin nuen Zabbix-en. Eta antzeko gidoi multzo txiki bat idatzi zuen . Bere garaian nahiko ezaguna zen. Eta han gauza garrantzitsu oso desberdinak kontrolatu ahal izan ziren, Linux ez ezik, hainbat osagai ere.
Orain dagoeneko PostgreSQL egiten ari naiz. Dagoeneko idazten ari naiz PostgreSQL estatistikekin lan egiteko aukera ematen duen beste gauza bat. Deitzen da (Habreri buruzko artikulua - ).
Sarrera txiki bat. Zeintzuk dira gure bezeroekin, gure bezeroekin? Datu-basearekin lotutako istripu motaren bat dago. Eta datu-basea lehengoratuta dagoenean, saileko burua edo garapen-burua etortzen da eta zera esaten du: Β«Lagunok, datu-basearen jarraipena egin beharko genuke, zerbait txarra gertatu delako eta beharrezkoa baita etorkizunean horrelakorik ez gertatzeaΒ». Eta hemen hasten da monitorizazio sistema bat aukeratzeko edo lehendik dagoen monitorizazio sistema bat egokitzeko prozesu interesgarria, zure datu-basea kontrolatu ahal izateko - PostgreSQL, MySQL edo beste batzuk. Eta lankideak eskaintzen hasten dira: Β«Entzun nuen halako eta halako datu-base bat dagoela. Erabili dezagunΒ». Lankideak elkarri eztabaidatzen hasten dira. Eta azkenean, datu-base motaren bat aukeratzen dugula ematen du, baina PostgreSQL monitorizazioa nahiko gaizki irudikatuta dago bertan eta beti zerbait amaitu behar dugu. Hartu GitHub-etik biltegi batzuk, klonatu, egokitu script-ak, nola edo hala sintonizatu. Eta azkenean eskuzko lan batean erortzen da.
Hori dela eta, txosten honetan, PostgreSQL-rako ez ezik, datu-baserako monitorizazioa aukeratzeko ezagutza batzuk ematen saiatuko naiz. Eta zure monitorizazioa amaitzea ahalbidetuko dizun ezagutza ematea, hortik etekina ateratzeko, zure datu-basea onuragarriz kontrolatu ahal izateko, denboran sor daitezkeen larrialdi-egoerak ekiditeko.
Eta txosten honetan egongo diren ideia horiek, zuzenean edozein datu-basetara egokitu daitezke, izan DBMS edo noSQL batera. Hori dela eta, hemen PostgreSQL ez ezik, PostgreSQL-n hau egiteko errezeta asko egongo dira. Kontsulten adibideak egongo dira, PostgreSQL-k monitorizatzeko dituen entitateen adibideak. Eta zure DBMSak monitorizazioan jartzea ahalbidetzen dizuten gauza berdinak baditu, haiek ere egokitu ditzakezu, gehitu eta ondo egongo da.
Ez dut berri emango
neurketak nola entregatu eta gordetzeari buruz hitz egin. Ez dut ezer esango datuak postprozesatu eta erabiltzaileari emateari buruz. Eta ez dut ezer esango alertari buruz.
Baina istorioan zehar, dauden monitorizazioen pantaila-argazki desberdinak erakutsiko ditut, nolabait kritikatuko ditut. Dena den, markarik ez izendatzen saiatuko naiz, produktu horien publizitaterik edo iragarkiaren aurkako publizitatea ez sortzeko. Hori dela eta, kasualitate guztiak ausazkoak dira eta zure irudimenean geratzen dira.
Lehenik eta behin, uler dezagun zer den monitorizazioa. Jarraipena egitea oso garrantzitsua da. Denek ulertzen dute hau. Baina, aldi berean, monitorizazioa ez dago negozio-produktu batekin zerikusirik eta ez die zuzenean eragiten enpresaren irabaziei, beraz, monitorizazioari denbora hondar batean ematen zaio beti. Denbora badugu, jarraipenean aritzen gara, denborarik ez badago, ados, atzerapenean sartuko dugu eta noizbait itzuliko gara zeregin horietara.
Hori dela eta, gure praktikatik, bezeroengana iristen garenean, monitorizazioa sarritan garatu gabe dago eta ez du datu-basearekin lan hobea egiten lagunduko ligukeen gauza interesgarririk. Eta, beraz, jarraipena beti amaitu behar da.
Datu-baseak hain gauza konplexuak dira, zeinak ere kontrolatu behar dituzun, datu-baseak informazio biltegi bat direlako. Eta informazioa oso garrantzitsua da enpresarentzat, ezin da inola ere galdu. Baina, aldi berean, datu-baseak oso software konplexuak dira. Osagai askoz osatuta daude. Eta osagai horietako asko kontrolatu behar dira.
PostgreSQL-i buruz zehazki hitz egiten ari bagara, osagai kopuru handiz osatuta dagoen eskema gisa irudika daiteke. Osagai hauek elkarri eragiten diote. Eta, aldi berean, PostgreSQL-k Stats Collector azpisistema deiturikoa du, azpisistema horien funtzionamenduari buruzko estatistikak biltzeko eta administratzaileari edo erabiltzaileari interfaze bat eskaintzeko, estatistika horiek ikus ditzan.
Estatistika hau funtzio eta ikuspegi multzo batzuen moduan aurkezten da (ikuspegia). Taulak ere deitu daitezke. Hau da, psql bezero arrunt bat erabiliz, datu-basera konekta zaitezke, funtzio eta ikuspegi hauek hautatu eta PostgreSQL azpisistemen funtzionamenduari buruzko zenbaki zehatz batzuk lor ditzakezu.
Zenbaki hauek zure gogoko jarraipen-sistemara gehi ditzakezu, grafikoak marraztu, eginbideak gehitu eta epe luzera analisiak lor ditzakezu.
Baina txosten honetan, ez ditut funtzio horiek guztiak salbuespenik gabe landuko, egun oso bat behar baita. Literalki bi, hiru edo lau gauza aipatuko ditut eta kontatuko dizut nola laguntzen duten monitorizazioa hobetzen.
Eta datu-basearen jarraipenaz hitz egiten badugu, zer kontrolatu behar da? Lehenik eta behin, erabilgarritasuna kontrolatu behar dugu, datu-basea bezeroei datuetarako sarbidea ematen dien zerbitzua delako eta erabilgarritasuna kontrolatu behar dugulako, eta bere ezaugarri kualitatibo eta kuantitatibo batzuk ere eman behar ditugu.
Gure datu-basera konektatzen diren bezeroak ere kontrolatu behar ditugu, bezero arruntak eta datu-basea kalte dezaketen bezero kaltegarriak izan daitezkeelako. Gainera, jarraipena eta jarraipena egin behar zaie.
Bezeroak datu-basera konektatzen direnean, begi-bistakoa da gure datuekin lanean hasten direla, beraz, bezeroek datuekin nola lan egiten duten kontrolatu behar dugu: zein taulekin, neurri txikiagoan zein indizeekin. Hau da, gure bezeroek sortzen duten lan-karga ebaluatu behar dugu.
Baina lan karga ere eskaeretan datza, noski. Aplikazioak datu basera konektatzen dira, kontsultak erabiliz datuak sartzen dira, beraz, garrantzitsua da datu-basean zein kontsulta ditugun ebaluatzea, haien egokitasuna kontrolatzea, gaizki idatzita ez daudela, aukera batzuk berridatzi eta egin behar direla azkarrago funtziona dezaten. eta errendimendu hobearekin.
Eta datu-baseari buruz ari garenez, datu-basea atzeko planoko prozesuak dira beti. Atzeko planoko prozesuek datu-basearen errendimendua maila onean mantentzen dute, beraz, baliabide kopuru jakin bat behar dute exekutatzeko. Eta, aldi berean, bezeroen eskaera-baliabideekin gainjar daitezke, beraz, atzeko prozesuen lan zikorrak zuzenean eragin dezake bezeroen eskaeren errendimenduan. Hori dela eta, monitorizatu eta jarraipena egin behar zaie, atzeko prozesuei dagokienez distortsiorik egon ez dadin.
Eta hori guztia datu-baseen jarraipena sistemaren metrikan geratzen da. Baina gure azpiegitura osoa hodeietara doala gehienetan, ostalari indibidual baten sistemaren neurketak beti atzealdean geratzen dira. Baina datu-baseetan, oraindik garrantzitsuak dira eta, jakina, beharrezkoa da sistemaren neurketak kontrolatzea ere.
Sistemaren metrikekin, dena gutxi gorabehera ondo dago, monitorizazio sistema moderno guztiek dagoeneko onartzen dute metrika hauek, baina, oro har, osagai batzuk oraindik ez dira nahikoak eta gauza batzuk gehitu behar dira. Horiek ere ukituko ditut, hainbat diapositiba izango dira haiei buruz.
Planaren lehen puntua irisgarritasuna da. Zer da irisgarritasuna? Nire ustez erabilgarritasuna oinarriak konexioak zerbitzatzeko duen gaitasuna da, hau da, oinarria altxatzen da, zerbitzu gisa bezeroen konexioak onartzen ditu. Eta irisgarritasun hori ezaugarri batzuen arabera baloratu daiteke. Ezaugarri hauek oso erosoak dira aginte-paneletan erakusteko.
Denek daki zer diren aginte-panelak. Hau da pantailari begirada bat eman diozun, beharrezko informazioa laburbiltzen duena. Eta berehala zehaztu dezakezu datu-basean arazoren bat dagoen edo ez.
Horren arabera, datu-basearen erabilgarritasuna eta gainerako funtsezko ezaugarriak aginte-paneletan jarri behar dira beti, informazio hori eskura egon dadin, beti zurekin. Gorabeheren ikerketan, larrialdi egoera batzuen ikerketan, dagoeneko bigarren mailako aginte-paneletan jarri behar dira edo hirugarrenen monitorizazio-sistemetara eramaten duten drilldown esteketan ezkutatuta dauden xehetasun gehigarri batzuk.
Monitorizazio sistema ezagun baten adibidea. Hau monitorizazio sistema oso polita da. Datu asko biltzen ditu, baina nire ikuspuntutik, aginteen kontzeptu arraroa du. "Sortu panela" esteka dago. Baina aginte-panela bat sortzen duzunean, bi zutabeko zerrenda sortzen duzu, diagramen zerrenda. Eta zerbait begiratu behar duzunean, klik egiten hasten zara, korritzen, saguarekin nahi duzun diagrama bilatzen. Eta honek denbora behar du, hau da, ez dago aginte-panelrik. Grafikoen zerrendak baino ez daude.
Zer gehitu behar zaie aginte-panel horiei? Erantzun denbora bezalako ezaugarri batekin has zaitezke. PostgreSQL-k pg_stat_statements ikuspegia du. Lehenespenez desgaituta dago, baina beti gaitu eta erabili behar den sistemaren ikuspegi garrantzitsuetako bat da. Datu-basean exekutatutako kontsulta guztiei buruzko informazioa gordetzen du.
Horren arabera, eskaera guztien exekuzio-denbora osoa hartu eta goiko eremuak erabiliz eskaera-kopuruarekin zatitu dezakegula abia gaitezke. Baina hori ospitaleko batez besteko tenperatura da. Beste eremu batzuetan eraiki dezakegu: gutxieneko kontsultaren exekuzio denbora, maximoa eta mediana. Eta pertzentilak ere eraiki ditzakegu, PostgreSQL-k horretarako dagozkion funtzioak ditu. Eta gure datu-basearen erantzun-denbora ezaugarritzen duten zenbaki batzuk lor ditzakegu dagoeneko betetako eskaeren kasuan, hau da, ez dugu 'hautatu 1' eskaera faltsurik exekutatzen eta erantzun-denbora ikusten, baina dagoeneko betetako eskaeren erantzun-denbora aztertzen dugu eta bai marrazten dugu. aparteko irudi bat, edo grafiko bat eraikitzen dugu horretan oinarrituta.
Garrantzitsua da sistemak gaur egun sortzen duen akats kopuruaren jarraipena egitea ere. Eta horretarako pg_stat_database ikuspegia erabil dezakezu. Xact_rollback eremura bideratzen ari gara. Eremu honek datu-basean gertatzen diren itzulketen kopurua ez ezik, errore kopurua ere kontuan hartzen du. Erlatiboki hitz eginez, zifra hau gure aginte-panelean bistaratu eta momentu honetan zenbat akats ditugun ikus dezakegu. Akats asko egonez gero, hori dagoeneko arrazoi ona da erregistroak aztertzeko eta nolako akatsak diren eta zergatik gertatzen diren ikusteko, eta gero inbertitu eta konpontzeko.
Takometroa bezalako gauza bat gehi dezakezu. Hauek dira segundoko transakzio kopurua eta segundoko eskaera kopurua. Erlatiboki hitz eginez, zenbaki hauek zure datu-basearen uneko errendimendu gisa erabil ditzakezu eta behatu eskaeren gailurrik dagoen, transakzioetan gailurrik dagoen edo, alderantziz, datu-basea gutxiegi dagoen kargatutako backend motaren bat erori delako. Garrantzitsua da beti zifra honi erreparatzea eta gogoratzea gure proiekturako horrelako errendimendu bat normala dela, eta goiko eta beheko balioak dagoeneko problematikoak eta ulergaitzak direla, eta horrek esan nahi du zergatik aztertu behar dugula halako zenbakiak. .
Transakzio kopurua kalkulatzeko, berriz ere pg_stat_database ikuspegira jo dezakegu. Konpromiso kopurua eta errebote kopurua gehi ditzakegu segundoko transakzio kopurua lortzeko.
Denek ulertzen dute hainbat eskaera transakzio batean sar daitezkeela? Beraz, TPS eta QPS apur bat desberdinak dira.
Segundoko eskaera kopurua pg_stat_statements-etik lor daiteke eta exekutatutako eskaera guztien batura kalkulatu besterik ez dago. Argi dago egungo balioa aurrekoarekin alderatzen dugula, kendu, delta lortu, zenbatekoa lortu.
Nahi izanez gero, neurri gehigarriak gehi ditzakezu, gure datu-basearen erabilgarritasuna ebaluatzeko eta geldialdirik egon den kontrolatzeko ere laguntzen dutenak.
Neurri horietako bat funtzionamendu-denbora da. Baina PostgreSQL-en funtzionamendu denbora pixka bat zaila da. Esango dizut zergatik. PostgreSQL abiarazten denean, funtzionamendu denboraren berri ematen hasten da. Baina uneren batean, adibidez, zereginen bat gauez exekutatzen ari bazen, OOM-hiltzaile bat etorri zen eta indarrez amaitu zuen PostgreSQL haurraren prozesua, orduan, kasu honetan, PostgreSQL-k bezero guztien konexioa amaitzen du, zatitutako memoria-eremua berrezarri eta berreskuratzen hasten da. azken kontrol-puntua. Eta kontrol-puntutik berreskuratze horrek irauten duen bitartean, datu-baseak ez ditu konexiorik onartzen, hau da, egoera hau geldialdi-denbora gisa baloratu daiteke. Baina honek ez du funtzionamendu-denboraren kontagailua berrezarriko, posta-zuzendaria lehen unetik hasi zeneko denbora kontuan hartzen duelako. Hori dela eta, horrelako egoerak saltatu daitezke.
Hutseko langileen kopurua ere kontrolatu beharko zenuke. Pertsona orok daki zer den autovacuum PostgreSQL-n? PostgreSQL-en azpisistema interesgarria da. Artikulu asko idatzi dira horri buruz, erreportaje asko egin dira. Eztabaida asko hutsaren inguruan, nola funtzionatu behar duen. Askok beharrezko gaitztzat dute. Baina hala da. Zabor-biltzaile moduko bat da, transakzio batek behar ez dituen errenkaden bertsio zaharkituak garbitzen dituena eta errenkada berrietarako tauletan eta indizeetan lekua askatzen duena.
Zergatik kontrolatu behar da? Hutsak batzuetan min handia egiten duelako. Baliabide asko kontsumitzen ditu eta bezeroen eskaerak hori jasaten hasten dira.
Eta hurrengo atalean hitz egingo dudan pg_stat_activity ikuspegiaren bidez kontrolatu beharko litzateke. Ikuspegi honek datu-baseko uneko jarduera erakusten du. Eta jarduera honen bidez, oraintxe bertan funtzionatzen ari diren hutsuneen jarraipena egin dezakegu. Hutsak kontrolatu ditzakegu eta muga gainditu badugu, PostgreSQL ezarpenak aztertzeko eta nolabait hutsaren funtzionamendua optimizatzeko aukera da.
PostgreSQL-ren beste ezaugarri bat da PostgreSQL transakzio luzeez oso gaixorik dagoela. Batez ere, denbora luzez zintzilikatu eta ezer egiten ez duten transakzioetatik. Hauek stat idle-in-transaction izenekoak dira. Horrelako transakzio batek sarrailak ditu, hutsean funtzionatzea eragozten du. Eta, ondorioz, mahaiak puztu egiten dira, tamaina handitzen dute. Taula hauekin lan egiten duten kontsultak, polikiago hasten dira lanean, errenkaden bertsio zahar guztiak memoriatik diskora eta atzera eraman behar dituzulako. Hori dela eta, denbora, transakzio luzeenen iraupena, hutsune eskaera luzeenen jarraipena ere egin behar da. Eta oso denbora luzez exekutatzen ari diren prozesu batzuk ikusten baditugu, OLTP karga baterako 10-20-30 minutu baino gehiagoz, orduan arreta jarri eta amaitzera behartu behar ditugu, edo aplikazioa optimizatu, horrela. ez dira deitzen eta ez dira hainbeste denbora zintzilikatzen. Karga analitiko baterako, 10-20-30 minutu normala da, luzeagoak ere badira.
Ondoren konektatutako bezeroekin aukera dugu. Dagoeneko aginte-panel bat osatu dugunean, eskuragarritasun-neurri nagusiak argitaratu ditugunean, konektatutako bezeroei buruzko informazio gehigarria ere gehi dezakegu bertan.
Konektatutako bezeroei buruzko informazioa garrantzitsua da, PostgreSQL-ren ikuspuntutik bezero mota desberdinak daudelako. Bezero onak daude eta bezero txarrak daude.
Adibide sinple bat. Bezeroaren arabera, aplikazioa esan nahi dut. Aplikazioa datu-basera konektatu da eta berehala hasten da bere eskaerak bidaltzen hara, datu-baseak prozesatu eta exekutatzen ditu, eta emaitzak bezeroari itzultzen dizkio. Hauek bezero onak eta egokiak dira.
Bezeroa konektatuta dagoen egoerak daude, konexioa mantentzen du, baina ez du ezer egiten. Inaktibo egoeran dago.
Baina bezero txarrak daude. Adibidez, bezero bera konektatu, transakzio bat ireki, datu-basean zerbait egin eta gero kodean sartu zen, adibidez, kanpoko iturri batera sartzeko edo jasotako datuak bertan prozesatzeko. Baina, aldi berean, ez zuen transakzioa itxi. Eta transakzioa datu-basean zintzilikatzen da eta blokeoa lerroan mantentzen du. Egoera txarra da hau. Eta bat-batean aplikazioa nonbait salbuespen baten ondorioz erortzen bada (Salbuespena), orduan transakzioa zabalik egon daiteke denbora luzez. Eta horrek zuzenean eragiten dio PostgreSQL-ren errendimenduari. PostgreSQL motelago exekutatuko da. Hori dela eta, garrantzitsua da bezero horiek garaiz jarraitzea eta lana indarrez amaitzea. Eta zure aplikazioa optimizatu behar duzu horrelako egoerarik egon ez dadin.
Beste bezero txarrak bezeroak zain daude. Baina egoerak direla eta txarra bihurtzen dira. Adibidez, inaktibo transakzio sinple bat: transakzio bat ireki dezake, lerro batzuetan blokeoak har ditzake, gero kodean nonbait eroriko da, transakzio bat zintzilik utziz. Beste bezero bat etorriko da, datu berdinak eskatuko ditu, baina blokeo batekin egingo du topo, zintzilik dagoen transakzio horrek dagoeneko beharrezko errenkada batzuetan sarrailak dituelako. Eta bigarren transakzioa aurreikuspenean zintzilikatuko da lehen transakzioa amaitzen denean edo bere administratzaileak indarrez ixten duenean. Horrela, zain dauden transakzioek datu-basearen konexioaren muga pilatu eta gaindi dezakete. Eta muga beteta dagoenean, aplikazioak ezin du datu-basearekin funtzionatu. Dagoeneko larrialdi egoera da proiektuarentzat. Hori dela eta, bezero txarrak jarraipena egin behar zaie eta garaiz erantzun behar zaie.
Jarraipenaren beste adibide bat. Eta hona hemen aginte-panel duin bat. Goiko konexioei buruzko informazioa dago. DB konexioa - 8 pieza. Eta dena da. Ez dugu informaziorik zein bezero aktibo dauden, zein bezero inaktibo dauden, ezer egin gabe. Ez dago transakzio zintzilik eta zintzilik dauden konexioei buruzko informaziorik, hau da, konexio kopurua erakusten duen zifra hau da eta kitto. Eta gero zuk zeuk asmatu.
Horren arabera, informazio hori monitorizazioari gehitzeko, pg_stat_activity sistemaren ikuspegira jo behar duzu. PostgreSQL-en denbora asko ematen baduzu, zure lagun bihurtu beharko litzatekeen ikuspegi oso ona da, PostgreSQL-en uneko jarduera erakusten duelako, hau da, bertan gertatzen dena. Prozesu bakoitzerako lerro bana dago prozesu honi buruzko informazioa erakusten duena: zein ostalaritik egin den konexioa, zein erabiltzailerekin, zein izenarekin, transakzioa noiz hasi den, zein eskaera exekutatzen ari den unean, zein eskaera exekutatu den azkena. Eta, horren arabera, bezeroaren egoera ebaluatu dezakegu stat eremuaren arabera. Erlatiboki hitz eginda, eremu honen arabera taldeka gaitezke eta datu-basean dauden estatistikak eta datu-basean datu-basean dauden estatistikak lortu ditzakegu. Eta dagoeneko jasotako zenbakiak gure jarraipenera bidali eta horien gainean grafikoak marraz ditzakegu.
Era berean, garrantzitsua da transakzioaren iraupena ebaluatzea. Dagoeneko esan dut garrantzitsua dela hutsuneen iraupena ebaluatzea, baina transakzioak ere modu berean ebaluatzen dira. Xact_start eta query_start eremuak daude. Haiek, nahiko hitz eginez, transakzioaren hasiera-ordua eta eskaeraren hasiera-ordua erakusten dituzte. Orain () funtzioa hartzen dugu, uneko denbora-zigilua erakusten duena, eta transakzio eta eskaera-zigiluak kenduko ditugu. Eta transakzioaren iraupena lortzen dugu, eskaeraren iraupena.
Transakzio luzeak ikusten baditugu, dagoeneko osatu beharko genituzke. OLTP karga baterako, transakzio luzeak dagoeneko 1-2-3 minutu baino gehiago dira. OLAP karga baterako, transakzio luzeak normalak dira, baina bi ordu baino gehiagoz exekutatzen badira, hau ere nonbait okerra daukagun seinale da.
Bezeroak datu basera konektatu ondoren, gure datuekin lanean hasten dira. Tauletan sartzen dira, indizeetara sartzen dira taula bateko datuak lortzeko. Eta garrantzitsua da bezeroek datu horiekin nola lan egiten duten ebaluatzea.
Hau beharrezkoa da gure lan karga ebaluatzeko eta gutxi gorabehera zein mahai ditugun "beroenak" ulertzeko. Adibidez, hau beharrezkoa da SSD biltegiratze azkar batean mahai "beroak" jarri nahi ditugun egoeretan. Esaterako, denbora luzez erabili ez ditugun artxibo-taula batzuk artxibo βhotzβ batera eraman daitezke, SATA diskoetara eta bertan bizitzen utzi, behar den moduan sartuko dira.
Edozein bertsio eta inplementazioaren ondoren anomaliak detektatzeko ere erabilgarria da. Demagun proiektuak ezaugarri berri batzuk zabaldu dituela. Adibidez, datu-basearekin lan egiteko funtzionaltasun berriak gehitu ditugu. Eta taulak erabiltzeko grafikoak eraikitzen baditugu, grafiko horietan erraz detekta ditzakegu anomalia horiek. Adibidez, eguneratu leherketak edo ezabatu leherketak. Oso ikusgai izango da.
Era berean, posible da "flotatutako" estatistiken anomaliak detektatzeko. Zer esan nahi du? PostgreSQL-k kontsulta-planifikatzaile oso sendoa eta oso ona du. Eta garatzaileek denbora asko eskaintzen diote bere garapenari. Nola egiten du lan? Plan onak eraikitzeko, PostgreSQL-k datuen banaketari buruzko estatistikak biltzen ditu denbora tarte jakin batekin tauletan, aldizkakotasun pixka batekin. Hauek dira baliorik ohikoenak: balio esklusiboen kopurua, NULL-i buruzko informazioa taulan, informazio asko.
Estatistika horietan oinarrituta, planifikatzaileak hainbat kontsulta eraikitzen ditu, egokiena aukeratzen du eta kontsulta-plan hau erabiltzen du kontsulta bera exekutatzeko eta datuak itzultzeko.
Eta gertatzen da estatistikek "flotatzen" dutela. Kalitate- eta kantitate-datuak nolabait aldatu ziren taulan, baina estatistikak ez ziren bildu. Eta osatutako planak agian ez dira optimoak. Eta bildutako jarraipenari dagokionez gure planak optimoak ez badira, taulen arabera, anomalia horiek ikusi ahal izango ditugu. Esaterako, nonbait datuak kualitatiboki aldatzen ziren eta indizearen ordez, taulatik pasabide sekuentziala erabiltzen hasi zen, hau da. Kontsultak 100 errenkada soilik itzuli behar baditu (100eko muga dago), orduan zenbaketa osoa egingo da kontsulta honetarako. Eta horrek beti eragin oso txarra du errendimenduan.
Eta jarraipenean ikus dezakegu. Eta dagoeneko begiratu kontsulta hau, egin azalpena, bildu estatistikak, eraiki indize osagarri berri bat. Eta dagoeneko erantzun arazo honi. Horregatik garrantzitsua da.
Jarraipenaren beste adibide bat. Uste dut jende askok ezagutzen duela oso ezaguna delako. Nork erabiltzen du bere proiektuetan ? Eta nork erabiltzen du produktu hau Prometheus-ekin batera? Kontua da monitorizazio honen biltegi estandarrean PostgreSQL-ekin lan egiteko panel bat dagoela - Prometeo. Baina detaile txar bat dago hemen.
Hainbat taula daude. Eta byteak unitate gisa zehazten dira, hau da, 5 grafiko daude. Hauek dira Txertatu datuak, Eguneratu datuak, Ezabatu datuak, Eskuratu datuak eta Itzuli datuak. Byteak unitate-dimentsio gisa zehazten dira. Baina kontua da PostgreSQL-en estatistikek datuak tuplatan (errenkadan) itzultzen dituztela. Eta, horren arabera, grafiko hauek oso modu ona dira zure lan-karga hainbat aldiz gutxiesteko, dozenaka aldiz, tupla bat ez baita byte bat, tupla bat kate bat da, byte asko eta luzera aldakorra baita beti. Hau da, lan karga bytetan kalkulatzea tuplak erabiliz zeregin irrealista edo oso zaila da. Hori dela eta, aginte-panela edo monitorizazio integratua erabiltzen duzunean, beti da garrantzitsua ulertzea ondo funtzionatzen duela eta behar bezala ebaluatutako datuak itzultzen dizkizula.
Nola lortu estatistikak taula hauetan? Horretarako, PostgreSQL-k ikuspegi-familia bat du. Eta ikuspegi nagusia da . Erabiltzaile_taulak - honek esan nahi du taulak erabiltzailearen izenean sortzen direla. Aitzitik, sistemaren ikuspegiak daude, PostgreSQL-k berak erabiltzen dituena. Eta Alltables laburpen-taula bat dago, sistema eta erabiltzailea barne hartzen dituena. Gehien gustatzen zaizun horietako edozeinetatik has zaitezke.
Goiko eremuak txertatze, eguneratze eta ezabatze kopurua kalkulatzeko erabil daitezke. Erabili dudan adibide-panelak eremu hauek erabiltzen ditu lan-kargaren ezaugarriak ebaluatzeko. Hori dela eta, horien gainean ere eraiki dezakegu. Baina komeni da gogoratzea hauek tuplak direla, ez byteak, beraz ezin dugu hartu eta byte egin.
Datu horietatik abiatuta, TopN-taulak deritzonak eraiki ditzakegu. Adibidez, Top-5, Top-10. Eta besteek baino gehiago erabiltzen diren mahai bero horien jarraipena egin dezakezu. Adibidez, txertatzeko 5 taula "bero". Eta TopN-taula hauen arabera, gure lan-karga ebaluatzen dugu eta lan-karga-leherketak ebalua ditzakegu kaleratze eta eguneratze eta inplementazioen ondoren.
Taularen tamaina ebaluatzea ere garrantzitsua da, batzuetan garatzaileek funtzio berri bat zabaltzen dutelako eta gure taulak beren tamaina handietan hazten hasten direlako, datu-kopuru gehigarria gehitzea erabaki zutelako, baina ez zutelako hau nola izango litzatekeen aurreikusi. datu-basearen tamainan eragina izatea. Horrelako kasuak ere sorpresa gisa etortzen zaizkigu.
Eta orain galdera txiki bat zuretzat. Zein da galdera datu-basearen zerbitzarian karga nabaritzen duzunean? Zein da zure hurrengo galdera?
Baina benetako galdera honako hau da. Zein eskaerak eragiten ditu kargak? Hau da, ez da interesgarria kargak eragiten dituen prozesuak ikustea. Argi dago hosta datu-base batekin baldin badago, datu-basea hor exekutatzen ari dela eta argi dago datu-baseak bakarrik botako direla bertan. Top irekitzen badugu, bertan zerbait egiten ari diren PostgreSQL prozesuen zerrenda ikusiko dugu. Goitik ez da argituko zertan ari diren.
Horren arabera, karga gehien eragiten duten kontsulta horiek aurkitu behar dituzu, kontsultaren sintonizazioak, normalean, PostgreSQL konfigurazioa edo sistema eragilearen doikuntzak edo hardwarearen sintonizazioak baino etekin handiagoa ematen duelako. Nire kalkuluen arabera, hau %80-85-90 ingurukoa da. Eta hau askoz azkarrago egiten da. Azkarragoa da eskaera zuzentzea konfigurazioa zuzentzea, berrabiarazi bat programatzea baino, batez ere datu-basea ezin bada berrabiarazi edo hardwarea gehitzea. Errazagoa da nonbait kontsulta berridaztea edo indize bat gehitzea kontsulta honen emaitza hobea lortzeko.
Horren arabera, beharrezkoa da eskaerak eta horien egokitasuna kontrolatzea. Har dezagun jarraipenaren beste adibide bat. Eta hemen ere jarraipen bikaina dela dirudi. Erreplikazioari buruzko informazioa dago, erreprodukzioari, blokeoari eta baliabideen erabilerari buruzko informazioa dago. Dena ondo dago, baina ez dago eskaerei buruzko informaziorik. Ez dago argi zein kontsultak exekutatzen ari diren gure datu-basean, zenbat denbora exekutatzen duten, zenbat kontsulta hauetako. Jarraipenean informazio hori beti eduki behar dugu.
Eta informazio hori lortzeko, pg_stat_statements modulua erabil dezakegu. Bere oinarrian, hainbat grafiko eraiki ditzakezu. Esaterako, gehien egiten diren eskaerei buruzko informazioa lor dezakezu, hau da, gehien egiten diren eskaerei buruzkoa. Bai, hedatu ondoren oso erabilgarria da hori aztertzea eta eskaeren gorakadarik dagoen ulertzea ere.
Eskaera luzeenen jarraipena egin dezakezu, hau da, betetzeko denbora gehien behar duten eskaerak. Prozesadorean exekutatzen dira, I/O kontsumitzen dute. Guztia_denbora, batez besteko_denbora, blk_write_time eta blk_read_time eremuen arabera ere ebalua dezakegu.
Baliabideen erabilerari dagokionez eskaerarik astunenak ebaluatu eta kontrola ditzakegu, diskotik irakurtzen direnak, memoriarekin lan egiten dutenak edo, aitzitik, nolabaiteko idazketa-karga sortzen dutenak.
Eskaera eskuzabalenak ebalua ditzakegu. Hauek dira errenkada kopuru handia itzultzen duten kontsultak. Adibidez, muga bat jartzea ahaztu zaien eskaera mota bat izan daiteke. Eta eskatutako tauletan taularen edo kontsultaren eduki osoa itzultzen du.
Eta aldi baterako fitxategiak edo aldi baterako taulak erabiltzen dituzten kontsultak ere kontrola ditzakezu.
Eta atzeko prozesuak ditugu oraindik. Atzeko planoko prozesuak kontrol-puntuak dira nagusiki edo kontrol-puntuak ere deitzen zaizkie, hauek hutsune automatikoa eta erreplikazioa dira.
Jarraipenaren beste adibide bat. Ezkerrean Mantentze fitxa bat dago, joan bertara eta espero zerbait erabilgarria ikustea. Baina hemen, hutsaren denbora eta estatistika bilketa bakarrik, kito. Oso informazio eskasa da, beraz, beti izan behar duzu gure datu-basean atzeko prozesuek nola funtzionatzen duten eta haien lanarekin arazoren bat dagoen.
Kontrol-puntuak aztertzen ditugunean, gogoratu behar da gure kontrol-puntuek orri "zikinak" garbitzen dituztela zatitutako memoria-eremutik diskora, gero kontrol-puntu bat sortzen dutela. Eta kontrol-puntu hori berreskuratzeko garaian leku gisa erabil daiteke dagoeneko, PostgreSQL larrialdi batean bat-batean amaitu bada.
Horren arabera, orri "zikin" guztiak diskora garbitzeko, idatzi kopuru jakin bat egin behar duzu. Eta, oro har, memoria kopuru handia duten sistemetan, hau asko da. Eta kontrol-puntuak sarritan egiten baditugu tarte labur batean, orduan diskoaren errendimendua asko apalduko da. Eta bezeroen eskaerek baliabide falta jasango dute. Baliabideengatik lehiatuko dira eta produktibitate falta.
Horren arabera, zehaztutako eremuetan pg_stat_bgwriter bidez, gertatzen diren kontrol-puntu kopurua kontrolatu dezakegu. Eta denbora-tarte jakin baterako kontrol-puntu asko baditugu (10-15-20 minutuz, ordu erdiz), adibidez, 3-4-5, orduan dagoeneko arazo bat izan daiteke. Eta datu-basean begiratu behar duzu, konfigurazioan begiratu, zerk eragiten duen kontrol-puntu ugari. Agian disko handiren bat etorriko da. Dagoeneko lan-karga ebaluatu dezakegu, dagoeneko gehitu ditugulako lan-karga-taulak. Dagoeneko eten-puntuaren parametroak moldatu ditzakegu eta kontsultaren errendimenduari eragin handirik ez diotela ziurtatu.
Berriro itzuliko naiz automatikoki hutsunera, esan dudan bezala, diskoaren eta kontsultaren errendimendua erraz gehitzen duen gauza bat delako, beraz, beti da garrantzitsua autohutsaren zenbatekoa neurtzea.
Datu-basean automatikoki hutsean dauden langileen kopurua mugatua da. Lehenespenez, hiru daude, beraz, datu-basean hiru langile baditugu denbora guztian lanean, horrek esan nahi du gure hutsune automatikoa konfiguratuta dagoela, mugak igo behar ditugula, hutsune automatikoaren ezarpenak berrikusi eta dagoeneko konfiguraziora igo behar dugula.
Garrantzitsua da hutsean zein langile lan egiten dugun ebaluatzea. Edo erabiltzailearengandik abiarazi zen, DBA sartu zen eta bere eskuekin hutsune bat abiarazi zuen, eta honek karga bat sortu zuen. Arazoren bat dugu. Edo hau da transakzioen kontagailua askatzen duten hutsen kopurua. PostgreSQL-ren bertsio batzuentzat, hauek oso huts astunak dira. Eta errendimendua erraz gehi dezakete, taula osoa kentzen ari direlako, taula honetako bloke guztiak eskaneatzen.
Eta, noski, hutsuneen iraupena. Oso denbora luzez funtzionatzen duten huts luzeak baditugu, horrek esan nahi du berriro hutsaren konfigurazioari arreta jarri beharko geniola eta agian bere ezarpenak birplanteatu beharko genituzkeela. Egoera bat sor daitekeelako hutsak denbora luzez mahai gainean lan egiten duenean (3-4 ordu), baina hutsean lanean zehar, hildako errenkada ugari berriro mahaian pilatzea lortu zen. Eta hutsunea amaitu bezain laster, mahai hau berriro xurgatu behar du. Eta egoera batera iristen gara: hutsune infinitu batera. Eta kasu honetan, hutsak ez dio bere lanari aurre egiten, eta taulak pixkanaka-pixkanaka handitzen hasten dira, nahiz eta bertan dauden datu erabilgarriak berdina izaten jarraitzen duen. Horregatik, huts luzeetan, konfigurazioari begiratu eta optimizatzen saiatzen gara beti, baina, aldi berean, bezeroen eskaeren errendimendua kaltetu ez dadin.
Orain ez dago ia PostgreSQL instalaziorik non streaming erreplikarik egon ez den. Erreplikazioa datuak maisu batetik erreplika batera transferitzeko prozesua da.
PostgreSQL-n erreplikatzea transakzioen erregistro baten bidez antolatzen da. Maisuak transakzioen erregistroa sortzen du. Sareko konexioko transakzioen erregistroa erreplikara doa, gero erreplikan erreproduzitzen da. Dena sinplea da.
Horren arabera, pg_stat_replication ikuspegia erabiltzen da erreplikazioaren atzerapena kontrolatzeko. Baina ez da erraza beretzat. 10. bertsioan, ikuspegiak hainbat aldaketa jasan ditu. Lehenik eta behin, eremu batzuei izena aldatu zaie. Eta eremu batzuk gehitu dira. 10. bertsioan, erreplikazioaren atzerapena segundotan ebaluatzeko aukera ematen duten eremuak agertu ziren. Oso erosoa da. 10. bertsioa baino lehen, erreplikazio-lag-a bytetan kalkulatzea posible zen. Ezaugarri hau 10. bertsioan geratu zen, hau da, zuretzat erosoena dena aukeratu dezakezu - ebaluatu atzerapena bytetan edo ebaluatu atzerapena segundotan. Askok biak egiten dituzte.
Hala ere, erreplikazioaren atzerapena ebaluatzeko, transakzioan erregistroaren posizioa ezagutu behar duzu. Eta transakzioen erregistroko posizio hauek pg_stat_replication ikuspegian daude. Erlatiboki hitz eginez, pg_xlog_location_diff() funtzioa erabil dezakegu transakzioen erregistroan bi puntu hartzeko. Kalkulatu haien arteko delta eta lortu erreplikazio-lag-a bytetan. Oso erosoa eta erraza da.
10. bertsioan funtzio honi pg_wal_lsn_diff() izena jarri zitzaion. Orokorrean, "xlog" hitza aurkitzen zen funtzio, ikuspegi, utilitate guztietan, "wal" balioarekin ordezkatu zen. Hau bai ikuspegietan eta baita funtzioetan ere. Halako berrikuntza bat da.
Gainera, 10. bertsioan, berariaz atzerapena erakusten duten lerroak gehitu ziren. Hauek dira idazketa lag, flush lag, replay lag. Hau da, garrantzitsua da gauza horien jarraipena egitea. Erreplikazio-lag bat dugula ikusten badugu, zergatik agertu den, nondik datorren ikertu eta arazoa konpondu behar dugu.
Sistemaren metrikekin, ia dena dago ordenatuta. Edozein monitorizazio jaiotzen denean, sistemaren metrikekin hasten da. Hau da prozesadoreen, memoriaren, trukearen, sarearen eta diskoaren erabilera. Baina, hala ere, parametro asko ez daude lehenespenez.
Prozesua deuseztatzeko dena ondo badago, diskoa botatzeko arazoak daude. Oro har, monitorizazio-garatzaileek banda zabalerako informazioa gehitzen dute. Iops edo bytetan izan daiteke. Baina latentziaz eta disko gailuen erabileraz ahaztu egiten dira. Parametro garrantzitsuagoak dira, gure diskoak zenbat kargatuta dauden eta zenbat moteltzen diren ebaluatzeko aukera ematen digutenak. Latentzia handia badugu, horrek esan nahi du diskoekin arazo batzuk daudela. Erabilera handia badugu, horrek esan nahi du diskoek ezin dutela aurre egin. Band-zabalera baino ezaugarri kualitatiboagoak dira.
Hala ere, estatistika hauek /proc fitxategi sistematik ere lor daitezke, prozesadorearen birziklapenerako egiten den bezala. Zergatik ez da informazio hori gehitzen jarraipenean, ez dakit. Baina oraindik garrantzitsua da zure monitorizazioan edukitzea.
Gauza bera gertatzen da sareko interfazeekin. Sareko banda-zabalerari buruzko informazioa dago paketeetan, byteetan, baina, hala ere, ez dago latentziari buruzko informaziorik eta erabilerari buruzko informaziorik, nahiz eta hori ere informazio erabilgarria den.
Edozein monitorizaziok bere eragozpenak ditu. Eta edozein monitorizazio mota egiten duzun edozein dela ere, beti huts egingo du irizpide batzuk beteko. Baina, hala ere, garatzen dira, ezaugarri berriak gehitzen dira, gauza berriak, beraz, aukeratu zerbait eta amaitu.
Eta amaitzeko, beti izan behar duzu zer esan nahi duen emandako estatistikak eta nola konpondu ditzakezun arazoak.
Eta funtsezko puntu batzuk:
- Beti erabilgarritasuna kontrolatu behar duzu, aginte-panelak izan, horrela, oinarriarekin dena ondo dagoela azkar ebaluatu ahal izateko.
- Beti izan behar duzu zure datu-basearekin zer bezero lan egiten duten ideia bat izan behar duzu bezero txarrak kendu eta tiro egiteko.
- Garrantzitsua da bezero hauek datuekin nola lan egiten duten ebaluatzea. Zure lan-kargari buruzko ideia bat izan behar duzu.
- Garrantzitsua da lan-karga hori nola osatzen den ebaluatzea, zein kontsulten laguntzarekin. Kontsultak ebaluatu ditzakezu, optimizatu, birfaktorizatu, indizeak eraiki ditzakezu. Oso garrantzitsua da.
- Atzeko planoek bezeroen eskaeretan eragin negatiboa izan dezakete, beraz, garrantzitsua da baliabide gehiegi erabiltzen ez dituztela ziurtatzea.
- Sistema-neurriek eskalatzeko planak egiteko aukera ematen dizute, zure zerbitzarien ahalmena handitzeko, beraz, garrantzitsua da haiek ere jarraipena egitea eta ebaluatzea.
Gai hau interesatzen bazaizu, esteka hauek jarraitu ditzakezu.
estatistika-biltzailearen dokumentazio ofiziala da. Ikuspegi estatistiko guztien deskribapena eta eremu guztien deskribapena daude. Irakurri, ulertu eta aztertu ditzakezu. Eta horietan oinarrituta, eraiki zure grafikoak, gehitu zure jarraipena.
Adibideak eskatu:
Hau da gure gordailu korporatiboa eta nirea. Lagin eskaerak dituzte. Ez dago serietik hautatutako* kontsultarik, zerbait hor. Dagoeneko prest dauden eskaerak daude elkartzeekin, zenbaki gordinetik balio irakurgarri eta erosoak egiteko aukera ematen duten funtzio interesgarriak erabiliz, hau da, byteak, denbora dira. Hautatu, ikusi, aztertu, zure monitorizazioetara gehi ditzakezu, haietan oinarrituta zure monitorizazioak eraiki.
Zure galderak
Galdera: Ez zenuela markak iragarriko esan zenuen, baina oraindik galdetzen ari naiz: zer-nolako panelak erabiltzen dituzu zure proiektuetan?
Erantzuna: Modu ezberdinetan. Gertatzen da bezeroarengana etortzen garela eta dagoeneko bere jarraipena duela. Eta bezeroari bere monitorizazioari zer gehitu behar zaion aholkatzen diogu. Egoerarik okerrena Zabbixekin dago. TopN-grafikoak eraikitzeko gaitasunik ez duelako. Guk geuk erabiltzen dugu tipo horiei jarraipenari buruz kontsultatu genuelako. PostgreSQLren jarraipena egin zuten gure TORn oinarrituta. Nire maskota-proiektua idazten ari naiz, Prometheus-en bidez datuak biltzen dituena eta bertan marrazten dituena . Nire zeregina Prometheus-en nire esportatzailea egitea da eta gero dena Grafanan marraztea.
Galdera: Ba al dago AWR txostenen edo... agregazioen analogorik? Badakizu horrelako zerbaiten berri?
Erantzuna: Bai, badakit zer den AWR, gauza polita da. Momentuz, hainbat bizikleta daude gutxi gorabehera hurrengo eredua ezartzen dutenak. Denbora tarteren batean, oinarri-lerro batzuk PostgreSQL berean edo biltegiratze bereizi batean idazten dira. Interneten google ditzakezu, dira. Horrelako garatzaileetako bat sql.ru foroan dago PostgreSQL harian. Han harrapa dezakezu. Bai, badaude horrelakoak, erabil daitezke. gehi bere Gauza bera egiteko aukera ematen dizun gauza bat ere idazten dut.
PS1 postgres_exporter erabiltzen ari bazara, zein panel erabiltzen ari zara? Hainbat dira. Dagoeneko zaharkituta daude. Sor al dezake komunitateak txantiloi eguneratu bat?
PS2 pganalyze kendu da, errendimenduaren monitorizazioan eta sintonizazio iradokizun automatizatuan oinarritzen den SaaS eskaintza jabeduna baita.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Zein postgresql monitorizazio auto-ostatatutako (arbelarekin) uste duzu onena dela?
-
30,0%Zabbix + Alexey Lesovsky edo zabbix 4.4 edo libzbxpgsql + zabbix libzbxpgsql + zabbix3-ren gehiketak
-
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 jabedun SaaS bat da - ezin da ezabatu1
-
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 erabiltzailek eman dute botoa. 26 erabiltzaile abstenitu ziren.
Iturria: www.habr.com