Juaj të njihni për përmbledhjen e raportit nga Alexei Lesovski nga Data Egret "Bazat e monitorimit të PostgreSQL"
Në këtë raport, Alexei Lesovski do të flasë për pikat kyçe të statistikave të PostgreSQL, çfarë do të thonë ato dhe pse duhet të jenë të pranishme në monitorim; për grafikat që duhet të jenë në monitorim, si t'i shtoni ato dhe si t'i interpretoni. Raporti do të jetë i dobishëm për administratorët e bazave të të dhënave, administratorët sistemorë dhe zhvilluesit të cilëve iu intereson zgjidhja e problemeve në Postgres.
Unë quhem Alexei Lesovski, përfaqësoj kompaninë Data Egret.
Disa fjalë për veten. Kam filluar një herë e një kohë si administrator sistemi.
Kam administruar të ndryshme Linux, kam bërë gjëra të ndryshme që lidhen me Linux, pra virtualizim, monitorim, kam punuar me proxy etj. Por në një moment, fillova të merrem më shumë me bazat e të dhënave, PostgreSQL. Më pëlqeu shumë. Dhe në një moment, fillova të merrem me PostgreSQL pjesën më të madhe të kohës sime të punës. Kështu gradualisht u bëra PostgreSQL DBA.
Dhe gjatë gjithë karrierës time kam qenë gjithmonë i interesuar në temat e statistikave, monitorimit, marrëjes së telemetrisë. Dhe kur isha administrator sistemi, meresha shumë me Zabbix. Kam shkruar një grup të vogël skriptesh si . Ai ishte mjaft popullor në kohën e tij. Dhe atje mund të monitoroheshin shumë gjëra të rëndësishme, jo vetëm Linuxi, por gjithashtu komponente të ndryshme.
Tani merem me PostgreSQL. Po shkruaj një gjë tjetër që lejon punën me statistikën e PostgreSQL. Ajo quhet (artikulli në habr — ).
Një hyrje e vogël. Cilat janë situatat e ndryshme me të cilat përballen klientët tanë? Ka ndodhur ndonjë fatkeqësi që lidhet me bazën e të dhënave. Dhe kur e rikthejmë bazën e të dhënave, shefi i departamentit ose shefi i zhvillimit thotë: "Shokë, duhet ta monitorojmë bazën e të dhënave, sepse ndodhi diçka e keqe dhe duhet që në të ardhmen të mos ndodhi përsëri". Këtu fillon një proces interesant i zgjedhjes së sistemit të monitorimit ose përshtatjes së një sistemi ekzistues të monitorimit që të mund të monitoronim bazën tonë të të dhënave – PostgreSQL, MySQL ose ndonjë tjetër. Kolegët fillojnë të rekomandojnë: "Kam dëgjuar se ka një bazë të tillë të të dhënave. Le të përdorim atë". Kolegët fillojnë të diskutojnë mes tyre. Dhe përfundimisht përfundojmë duke zgjedhur një bazë të dhënash, por monitorimi i PostgreSQL në të është mjaft i zbehtë dhe gjithmonë duhet të bëjmë disa rregullime. Të merremi me disa repozita nga GitHub, t'i klonojmë, të përshtatim skriptet, të rregullojmë disi. Dhe përfundimisht kjo rezulton në punë manuale.
Prandaj në këtë raport do të përpiqem të ofroj disa njohuri mbi se si të zgjidhni monitorim jo vetëm për PostgreSQL, por edhe për bazat e të dhënave. Dhe t'u jap ato njohuri që do t'ju lejojnë të përmirësoni monitorimin tuaj, që të merrni ndihmë prej tij, që të mund të monitoroni bazën tuaj të të dhënave me dobi, për të parashikuar në kohë situatat emergjente që mund të ndodhin.
Dhe idetë që do të jenë në këtë raport, mund të adaptohen drejtpërdrejt për çdo bazë të dhënash, qoftë kjo një DBMS apo noSQL. Prandaj, këtu nuk është vetëm PostgreSQL, por ka shumë receta se si ta bëni këtë në PostgreSQL. Do të ketë shembuj pyetjesh, shembuj entitetesh që janë në PostgreSQL për monitorim. Dhe nëse DBMS juaj ka gjëra të ngjashme që lejojnë të futen në monitorim, ju gjithashtu mund t'i adaptoni, të shtoni dhe do të jetë mirë.
Në raportin nuk do të
flas për se si të dorëzojmë dhe ruajmë metrikat. Nuk do të flas asgjë për pas-përpunimin e të dhënave dhe ofrimin e tyre për përdoruesin. Dhe nuk do të flas asgjë për alarmin.
Por gjatë rrëfimit do të tregoj disa screenshot-e të monitorimeve ekzistuese, do t'i kritikoj disi. Por megjithatë do përpiqem të mos përmend markat, që të mos krijoj reklamë ose anti-reklamë për këto produkte. Prandaj, të gjitha përputhjet janë rastësi dhe mbeten në imagjinatën tuaj.
Në fillim, le të kuptojmë se çfarë është monitorimi. Monitorimi është një gjë shumë e rëndësishme që duhet të kemi. Të gjithë e kuptojnë këtë. Por në të njëjtën kohë monitorimi nuk i përket produktit të biznesit dhe nuk ndikon drejtpërdrejt në fitimin e kompanisë, prandaj monitorimit gjithmonë i kushtohet kohë si një punë e mbetur. Nëse kemi kohë, atëherë merremi me monitorimin, nëse nuk kemi kohë, atëherë OK, e vendosim në backlog dhe ndonjëherë do të kthehemi në këto detyra.
Pra situatën tonë, kur shkojmë te klientët, monitorimi shpesh është i papërfunduar dhe nuk ka asgjë interesante që ndihmon në përmirësimin e punës me bazën e të dhënave. Prandaj, monitorimi gjithmonë ka nevojë për përmirësim.
Baza e të dhënave është një sistem kompleks që gjithashtu ka nevojë për monitorim, pasi ato janë magazina informacioni. Informacioni është shumë i rëndësishëm për kompaninë, ai nuk duhet humbur aspak. Megjithatë, bazat e të dhënave janë pjesë shumë komplekse software-i, që përbëhen nga shumë komponentë. Shumica e këtyre komponentëve duhet monitoruar.
Kur flasim për PostgreSQL, mund ta imagjinojmë si një skemë përbërë nga shumë komponentë. Këta komponentë ndërveprojnë me njëri-tjetrin. Po ashtu, PostgreSQL ka një nën-sistem të quajtur Stats Collector, që mundëson mbledhjen e statistikave mbi këto sisteme dhe ofron një ndërfaqe për administratorin ose përdoruesin për të parë këto statistika.
Këto statistikë paraqiten si një grup funksionesh dhe pamjesh (view). Mund t'i referohen edhe si tabela. Kështu, me klientin e zakonshëm psql, mund të lidhesh me bazën e të dhënave, të blesh këto funksione dhe pamje dhe të marrësh disa numra konkretë për funksionimin e nën-sistemeve të PostgreSQL.
Mund t'i shtosh këta numra në sistemin tënd të preferuar të monitorimit, të vizatosh grafika, të shtosh funksione dhe të marrësh analiza afat-gjate.
Por në këtë paraqitje, nuk do të shqyrtoj të gjitha këto funksione, sepse do të merrte një ditë të tërë. Do të përqendrohem vetëm në dy-tre-katër gjëra dhe do të tregoj si ato ndihmojnë për të përmirësuar monitorimin.
Dhe nëse flasim për monitorimin e bazës, çfarë duhet të monitorojmë? Së pari dhe më kryesorja është të monitorojmë disponueshmërinë, sepse baza është një shërbim që ofron akses në të dhëna për klientët dhe ne duhet të monitorojmë disponueshmërinë, si dhe disa karakteristika të saj cilësore dhe sasiore.
Gjithashtu, duhet të monitorojmë klientët që lidhen me bazën tonë, sepse ata mund të jenë klientë normalë, por ndonjëherë edhe klientë keqdashës që mund të dëmtojnë bazën e të dhënave. Po ashtu, duhet t'i monitorojmë dhe të ndjekim aktivitetin e tyre.
Kur klientët lidhen me bazën e të dhënave, është e qartë se ata fillojnë të punojnë me të dhënat tona, kështu që duhet të monitorojmë si punojnë klientët me të dhënat: me cilat tabela, dhe më pak me cilat indekse. Pra, duhet të vlerësojmë ngarkesën (workload) që krijohet nga klientët tanë.
Por ngarkesa përbëhet sigurisht nga kërkesat. Aplikacionet lidhen me bazën, i qasen të dhënave përmes kërkesave, prandaj është e rëndësishme të vlerësojmë se cilat kërkesa kemi në bazën tonë, të ndjekim adekuatësinë e tyre, që ato të mos jenë të shkruara keq, dhe që disa opsione duhet të përmirësohen për të punuar më shpejt dhe me më shumë efikasitet.
Dhe kur flasim për bazat e të dhënave, ato gjithmonë kanë procese të prapme. Proceset e prapme ndihmojnë në mbajtjen e performancës së bazës në një nivel të mirë, kështu që për funksionimin e tyre kërkojnë një sasi të caktuar burimesh për vete. Në të njëjtën kohë, ato mund të konkurrojnë me burimet e kërkesave të klientëve, kështu që punimi kërkues i proceseve të prapme mund të ndikojë drejtpërdrejt në performancën e kërkesave të klientëve. Prandaj, ato gjithashtu duhet të monitorohen dhe të sigurohemi se nuk ka asnjë anomali në proceset e prapme.
Dhe gjithçka që lidhet me monitorimin e bazës së të dhënave mbetet në metrikat sistemike. Ndërsa marrim parasysh se infrastruktura jonë po migron në cloud, metrikat sistemike të një hosti të veçantë shpesh kalojnë në plan të dytë. Megjithatë, në bazat e të dhënave ato ende janë relevante dhe monitorimi i metrikeve sistemike sigurisht që është i domosdoshëm.
Me metrikat sistemike është më shumë-më pak e gjithë situata është në rregull, të gjitha sistemet moderne të monitorimit tashmë mbështesin këto metrika, por gjithsesi disa komponente akoma mungojnë dhe disa gjëra duhet të shtohen. Për këto do të flasë gjithashtu, disa diapozitiva do të përfshijnë themra.
Pika e parë e planit është disponueshmëria. Çfarë është disponueshmëria? Në mendimin tim, disponueshmëria është aftësia e bazës për të mbështetur lidhjet, dmth baza është ngritur, ajo, si një shërbim, pranon lidhje nga klientët. Dhe kjo disponueshmëri mund të vlerësohet me disa karakteristika. Këto karakteristika janë mjaft të përshtatshme për t'u paraqitur në dashboard.
Të gjithë e dinë se çfarë janë tabelat e kontrollit. Ato janë kur ju hidheni një herë në ekran, ku është e grumbulluar informacioni i nevojshëm. Dhe ju mund ta përcaktoni menjëherë – nëse ka një problem në bazën e të dhënave apo jo.
Prandaj, disponueshmëria e bazës së të dhënave dhe karakteristikat e tjera kyçe gjithmonë duhet të jenë të pranishme në tabelat e kontrollit, që kjo informacion të jetë në dorë, gjithmonë pranë jush. Detajet e tjera, të cilat ndihmojnë në hetimin e incidenteve, në hetimin e situatave emergjente, duhet të jenë të ndara në tabelat e kontrollit të dyta, ose të fshihen në lidhje të drilldown, të cilat çojnë në sisteme të monitorimit të jashtme.
Një shembull i një sistemi të njohur të monitorimit. Ky është një sistem shumë i bukur monitorimi. Ai grumbullon shumë të dhëna, por sipas mendimit tim, ai ka një koncept të çuditshëm të tabelave të kontrollit. Atje ka një lidhje 'krijo tabelë kontrolli'. Por kur krijoni një tabelë kontrolli, ju krijoni një listë të caktuar, e cila përbëhet nga dy kolona, një listë grafikësh. Dhe kur ju nevojitet të shihni diçka, filloni të klikoni me miun, shtyni, kërkoni grafikën që ju nevojitet. Dhe kjo merr kohë, pra tabelat e kontrollit, siç janë, nuk ekzistojnë. Ka vetëm lista grafikësh.
Çfarë duhet të shtohet në këto tabela kontrolli? Mund të filloni me një karakteristikë si koha e përgjigjes. Në PostgreSQL ka një pamje pg_stat_statements. Në mënyrë default, ajo është e çkyçur, por kjo është një nga pamjet sistematike të rëndësishme që gjithmonë duhet të çkyçet dhe përdoret. Ajo ruan informacionin mbi të gjitha kërkesat që janë ekzekutuar në bazën e të dhënave.
Prandaj, ne mund të fillojmë me atë se mund të marrim kohën totale të ekzekutimit të të gjitha kërkesave dhe ta ndajmë me numrin e kërkesave përmes fushave të mësipërme. Por kjo është një temperaturë mesatare për spitalin. Ne mund të marrim fushat e tjera – koha minimale e ekzekutimit të kërkesave, maksimumi dhe medianni. Madje mund të ndërtosh percentilët, në PostgreSQL ka funksione për këtë. Dhe mund të marrim disa shifra, të cilat karakterizojnë kohën e përgjigjes së bazës sonë për kërkesat që janë ekzekutuar, pra ne nuk ekzekutojmë një kërkesë false 'select 1' dhe shqyrtojmë kohën e përgjigjes, por analizojmë kohën e përgjigjeve për kërkesat që janë ekzekutuar dhe vizatojmë ose si shifër të veçantë, ose e ndërtosh grafik.
Gjithashtu është e rëndësishme të ndjekim numrin e gabimeve, të cilat gjenerohen nga sistemi në këtë moment. Dhe për këtë mund të përdorim pamjen pg_stat_database. Ne orientohemi në fushën xact_rollback. Kjo fushë tregon jo vetëm numrin e rrotullimeve që ndodhin në bazë, por gjithashtu merr parasysh numrin e gabimeve. Në njëfarë mënyre, mund ta nxjerrim këtë shifër në tabelën tonë të kontrollit dhe të shohim sa gabime kemi në atë moment. Nëse gabimet janë të shumta, kjo është një mundësi e mirë për të hedhur një sy në log dhe të shikojmë se çfarë lloji gabimesh janë ato dhe pse ndodhin, dhe më pas të investigojmë dhe t'i zgjidhim ato.
Mund të shtoni diçka si Tachometrin. Ky është numri i transaksioneve në sekondë dhe numri i kërkesave në sekondë. Në njëfarë mënyre, ju mund të përdorni këto shifra si performancën aktuale të bazës suaj të të dhënave dhe të vëzhgoni nëse ka kulme të kërkesave, kulme të transaksioneve ose, përkundrazi, baza nuk është e ngarkuar, sepse ndonjë backend është rrëzuar. Kjo shifër është e rëndësishme të shikohet gjithmonë dhe të mbani mend se për projektin tonë një performancë e tillë është normale, ndërsa vlerat më të larta dhe më të ulëta janë të problemet dhe të paqartë, dhe prandaj duhet të shikoni pse këto shifra.
Për të vlerësuar numrin e transaksioneve, ne mund të kthehemi përsëri në pamjen pg_stat_database. Ne mund të përmbledhim numrin e commit dhe nuk mbytshëm dhe të marrim numrin e transaksioneve në sekondë.
Të gjithë e kuptojnë se në një transaksion mund të përfshihen disa kërkesa? Pra, TPS dhe QPS janë paksa të ndryshme.
Numri i kërkesave në sekondë mund të merret nga pg_stat_statements dhe thjesht të llogaritet shuma e të gjitha kërkesave të ekzekutuara. Është e qartë se ne krahasojmë vlerën aktuale me atë të mëparshme, e heqim, marrim diferencën dhe marrim numrin.
Mund të shtoni metrika të tjera në varësi nga dëshira, të cilat gjithashtu ndihmojnë në vlerësimin e disponueshmërisë së bazës sonë dhe vëzhgojnë – a kishte ndonjë downtime.
Një nga këto metrika është uptime. Por uptime në PostgreSQL është diçka paksa e komplikuar. Do të shpjegoj pse. Kur PostgreSQL fillon, fillon të llogarisë uptime. Por nëse në një moment, për shembull, gjatë natës ekzekutohet ndonjë detyrë dhe OOM-killer do të përcaktojë me forcë procesin fëmijë të PostgreSQL, atëherë në këtë rast PostgreSQL ndalon lidhjen e të gjithë klientëve, e ribashkon hapësirën e memories sharduar dhe fillon rikuperimin nga pika e fundit të kontrollit. Dhe sa kohë zgjat kjo rikuperim nga pika e kontrollit, databaza nuk pranon lidhje, pra kjo situatë mund të konsiderohet si downtime. Por edhe pse numri i uptime nuk do të reshtet, sepse ai llogarit kohën e nisjes së postmaster që nga momenti i parë. Prandaj, situatat e tilla mund të kalohen pa u marrë parasysh.
Gjithashtu duhet të monitorohet numri i punëtorëve të vakumit. Të gjithë e dinë çfarë është autovacuum në PostgreSQL? Kjo është një nënstrukturë interesante në PostgreSQL. Për të është shkruar shumë artikuj, janë bërë shumë prezantime. Ka shumë diskutime rreth vakumit, se si duhet të funksionojë. Shumë e konsiderojnë atë një të keqe të pashmangshme. Por të tilla është. Ajo është një përfaqësuese e mbledhësit të plehrave, që pastron versionet e vjetra të rreshtave që nuk i nevojiten asnjë nga transaksionet dhe çliron hapësirë në tabela, indekse për rreshta të rinj.
Pse duhet ta monitorojmë? Sepse vakumi ndonjëherë bën shumë dëme. Ai konsumon një sasi të madhe burimesh dhe kërkesat e klientëve fillojnë të vuajnë për këtë.
Dhe duhet ta monitorojmë atë përmes pamjes pg_stat_activity, për të cilën do të flas në seksionin tjetër. Kjo pamje tregon aktivitetin aktual në databazë. Dhe përmes këtij aktiviteti ne mund të gjurmojmë numrin e vakumeve që po punojnë aktualisht. Ne mund të ndjekim vakumet dhe të shohim se nëse kemi kaluar limitin, atëherë kjo është një arsye për të shqyrtuar parametrat e PostgreSQL dhe për të optimizuar punën e vakumit.
Një veçori tjetër e PostgreSQL është se PostgreSQL pëson shumë nga transaksionet e gjata. Sidomos, nga transaksionet që varen për një kohë të gjatë dhe nuk bëjnë asgjë. Këto janë, të ashtuquajturat, stat idle-in-transaction. Një transaksion i tillë mban bllokimin, ai pengon punën e vakumit. Si rezultat, tabelat fryhen, ato rriten në madhësi. Dhe kërkesat që punojnë me këto tabela fillojnë të punojnë më ngadalë, sepse duhet të pastrojnë të gjitha versionet e vjetra të rreshtave nga memoria në disk dhe për t'i kthyer prapë. Prandaj, koha e zgjatjes së transaksioneve më të gjata, kërkesat më të gjata të vakumit gjithashtu duhet të monitorohen. Dhe nëse shohim ndonjë proces që punon për një kohë shumë të gjatë, më shumë se 10-20-30 minuta për ngarkesën OLTP, atëherë duhet t’i kushtohet vëmendje dhe duhet të përfundohet me forcë, ose të optimizohet aplikacioni në mënyrë që ato të mos thirren dhe të mos mbesin kaq gjatë. Për ngarkesat analitike 10-20-30 minuta është normale, ndonjëherë mund të zgjasë edhe më shumë.
Më pas kemi variantin me klientët e lidhur. Kur tashmë e kemi formuar dashboard-in, e kemi vendosur aty metrikat kryesore të disponueshmërisë, mund të shtojmë gjithashtu informacione shtesë për klientët e lidhur.
Informacioni rreth klientëve të lidhur është i rëndësishëm, sepse, nga këndvështrimi i PostgreSQL, klientët janë të ndryshëm. Ka klientë të mirë dhe ka klientë të keq.
Një shembull i thjeshtë. Nga klienti kuptoj një aplikacion. Aplikacioni lidhet me databazën dhe fillon menjëherë të dërgojë atje kërkesat e tij, databaza i përpunon dhe ekzekuton, rezultatet i kthen klientit. Këta janë klientë të mirë dhe të saktë.
Ka situata që klienti është lidhur, mban lidhjen, por nuk bën asgjë. Ai është në gjendjen idle.
Por ka klientë të këqij. Për shembull, i njëjti klient është lidhur, ka hapur një transaksion, ka bërë diçka në databazë dhe pastaj ka kaluar në kod, le të themi, për t’u drejtuar në një burim të jashtëm ose për të bërë atje përpunimin e të dhënave të marra. Por ai nuk e ka mbyllur transaksionin. Dhe transaksioni mbetet hapur në databazë dhe mban bllokimin mbi rreshta. Ky është një gjendje e keqe. Dhe nëse ndodhi që aplikacioni të bie ndonjëherë me një exception, atëherë transaksioni mund të mbetet i hapur për një kohë shumë të gjatë. Dhe kjo ndikon drejtpërdrejt në performancën e PostgreSQL. PostgreSQL do të punojë më ngadalë. Prandaj, është e rëndësishme të monitorohet në kohë këta klientë dhe të përfundohet puna e tyre me forcë. Dhe duhet të optimizohet aplikacioni për të parandaluar këtë situatë.
Klientët e tjerë të këqij janë ata që presin. Por ata bëhen të këqij për shkak të rrethanave. Për shembull, një transaksion i thjeshtë që mbetet pezull: mund të hapë një transaksion, të marrë bllokime mbi disa rreshta, pastaj diku në kod do të bie, duke lënë një transaksion të mbetur pezull. Një klient tjetër do të vijë, do të kërkojë të njëjtat të dhëna, por do të përballet me bllokimin sepse ai transaksion i mbetur pezull mban bllokime mbi disa rreshta të nevojshëm. Dhe transaksioni i dytë do të mbetet në pritje derisa transaksioni i parë të përfundojë ose administratori i tij ta mbyllë me forcë. Kështu, transaksionet që presin mund të grumbullohen dhe të mbushin limitin e lidhjeve me bazën e të dhënave. Dhe kur limiti është tejkaluar, aplikacioni nuk mund të punojë më me bazën. Kjo është një situatë emergjente për projektin. Prandaj, klientët e këqij duhet të monitorohen dhe të reagohet në kohë ndaj tyre.
Një shembull tjetër monitorimi. Dhe këtu kemi një dashboard të plotë. Ka informacion mbi lidhjet sipër. Lidhja DB – 8 çështe. Dhe kjo është gjithçka. Ne nuk kemi informacion se cilët klientë janë aktivë, cilët klientë janë thjesht të papunë, nuk bëjnë asgjë. Nuk ka informacion mbi transaksionet e mbetura pezull dhe lidhjet që presin, dmth. kjo është një numër që tregon sasinë e lidhjeve dhe kaq. Tani, mundohuni të kuptoni vetë.
Për ta shtuar këtë informacion në monitorim, duhet të referoheni te vtk_stat_activity. Nëse kaloni shumë kohë në PostgreSQL, kjo është një vew shumë e mirë që duhet të bëhet shoku juaj, sepse tregon aktivitetin aktual në PostgreSQL, dmth. çfarë po ndodh atje. Për çdo proces ka një rresht të veçantë që tregon informacionin mbi këtë proces: nga cili host është bërë lidhja, nga cili përdorues, me cilin emër, kur është nisur transaksioni, cili kërkesë është duke iu përmbajtur aktualisht, cili kërkesë është ekzekutuar së fundmi. Dhe, për rrjedhojë, ne mund të vlerësojmë gjendjen e klientit sipas fushës stat. Në terma të thjeshtë, mund të bëjmë grupimin sipas kësaj fushe dhe të marrim ato stats që ekzistojnë aktualisht në bazën e të dhënave dhe numrin e lidhjeve që kanë këto stats në bazën e të dhënave. Dhe ndonjëherë në xhiroshtat më dalin numrat.
E rëndësishme është të vlerësojmë gjithashtu kohëzgjatjen e transaksionit. Kam folur më parë se është e rëndësishme të vlerësojmë kohëzgjatjen e vakuumeve, por edhe transaksionet vlerësohen po ashtu. Ekzistojnë fushat xact_start dhe query_start. Ato, në një farë mënyre, tregojnë kohën e nisjes së transaksionit dhe kohën e nisjes së kërkesës. Ne marrim funksionin now(), i cili tregon pikën e saktë të kohës aktuale dhe e zbritim timestamp e transaksionit dhe kërkesës. Dhe marrim kohëzgjatjen e transaksionit, kohëzgjatjen e kërkesës.
Nëse shohim transaksione të gjata, duhet t'i mbyllim ato. Për ngarkesat OLTP, transaksionet e gjata janë më shumë se 1-2-3 minuta.. Për ngarkesat OLAP, transaksionet e gjata janë normale, por nëse ato zgjaten më shumë se dy orë, kjo është gjithashtu një shenjë se ndodhin probleme diku.
Kur klientët lidhen me bazën e të dhënave, ata fillojnë të punojnë me të dhënat tona. Ata iu drejtohen tabelave, iu drejtohen indekseve, për të marrë të dhëna nga tabela. Dhe është e rëndësishme të vlerësojmë se si klientët punojnë me këto të dhëna.
Kjo është e nevojshme për të vlerësuar ngarkesën tonë dhe për të kuptuar përafërsisht se cilat janë tabelat më 'të nxehta'. Për shembull, kjo është e rëndësishme në situatat kur duam të vendosim tabelat 'të nxehta' në ndonjë ruajtje të shpejtë SSD. Për shembull, disa tabela arkivore, që nuk i kemi përdorur prej kohësh, mund t'i kalojmë në ndonjë 'ruajtje të ftohtë', në disqe SATA dhe le të jetojnë atje, duke pasur qasje në to sipas nevojës.
Kjo është e dobishme gjithashtu për të zbuluar anomali pas disa lëshimeve dhe deplojeve. Supozoni se projekti ka nxjerrë një tipar të ri. Për shembull, kemi shtuar një funksionalitet të ri për të punuar me bazën. Dhe nëse ndërtuam grafikat e përdorimit të tabelave, në këto grafika do të jemi në gjendje të zbulojmë lehtësisht këto anomali. Për shembull, shpërthime në update ose shpërthime në delete. Kjo do të jetë shumë e dukshme.
Gjithashtu është e mundur të zbulohet anomali e statistikave që kanë 'rrëshqitur'. Çfarë do të thotë kjo? Në PostgreSQL ka një planifikues kërkesash shumë të fortë dhe shumë të mirë. Dhe zhvilluesit i kushtojnë shumë kohë zhvillimit të tij. Si funksionon? Për të ndërtuar plane të mira, PostgreSQL mbledh statistikën për shpërndarjen e të dhënave në tabela me një interval të caktuar, me një periodicitet të caktuar. Këto janë vlerat më të shpeshta: numri i vlerave unike, informacioni mbi NULL-in në tabelë, shumë informacione.
Bazuar në këtë statistikë, planifikuesi ndalon disa kërkesa, zgjedh më të optimizuarën dhe përdor këtë plan kërkesë për të ekzekutuar kërkesën dhe kthyer të dhënat.
Dhe ndodh që statistika "lëviz". Cilësia e të dhënave, sasia ka ndryshuar në ndonjë mënyrë në tabelë, por statistika nuk është mbledhur. Dhe planet e formuara mund të mos jenë optimale. Nëse planet tona rezultojnë të jenë të paoptimalizuara sipas monitorimit të mbledhur, ne do të mund të shohim këto anomalitë. Për shembull, ndonjëherë, të dhënat kanë ndryshuar cilësisht dhe indeksi fillon të përdorë një kalim të njëpasnjëshëm përmes tabelës. Kjo do të thotë që nëse kërkesa duhet të kthejë vetëm 100 rreshta (ka një kufi limit 100), atëherë për këtë kërkesë do të kryhet një kontroll i plotë. Dhe kjo gjithmonë ka një ndikim shumë negativ në performancë.
Dhe ne do të mund ta shohim këtë në monitorim. Dhe për të parë këtë kërkesë, të ekzekutojmë një explain për të, të mbledhim statistikat, të ndërtojmë një indeks të ri shtesë. Dhe pastaj të reagojmë ndaj kësaj problemi. Prandaj, është e rëndësishme.
Një shembull tjetër monitorimi. Mendoj se shumë e njohin, sepse është shumë popullor. Kush e përdor atë në projektet e tyre ? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – Prometheus. Por këtu ka një detaj të keq.
Ka disa grafika. Dhe si njësi janë të specifikuara bajtët, pra ka 5 grafika. Këto janë Insert data, Update data, Delete data, Fetch data dhe Return data. Si njësi matjeje janë të specifikuara bajtët. Por çështja është se statistika në PostgreSQL kthen të dhënat në tuple (rreshta). Dhe, për pasojë, këto grafika janë një mënyrë shumë e mirë për të ulur ngarkesën tuaj disa herë, madje dhjetëra herë, sepse tuple nuk është bajt, tuple është rresht, kjo është shumë bajtë dhe gjithmonë ka gjatësi variabile. Pra, llogaritja e ngarkesës në bajtë përmes tuples është një detyrë e pamundur ose shumë e komplikuar. Prandaj, kur përdorni një dashboard ose monitorim të integruar, gjithmonë është e rëndësishme të kuptoni se ai funksionon saktë dhe ju kthen të dhëna të vlerësuara në mënyrë korrekte.
Si të marrim statistika për këto tabela? Për këtë PostgreSQL ka një familje të caktuar të view-ëve. Dhe view kryesore është . User_tables do të thotë se tabelat janë krijuar nga përdoruesi. Në kontrast, ka view të sistemit që përdor vetë PostgreSQL. Dhe ka një tabelë përmbledhëse Alltables, e cila përfshin si tabelat sistemike, ashtu edhe ato të përdoruesve. Ju mund të mbështeteni në ndonjëra prej tyre, cilat do ju pëlqejnë më shumë.
Përmes fushave të përmendura më lart mund të vlerësojmë numrin e insert, update dhe delete. Shembulli i dashboard-it që kam përdorur, saktësisht përdor këto fusha për të vlerësuar karakteristikat e ngarkesës. Prandaj, ne gjithashtu mund të mbështetemi në to. Por duhet të mbahet mend se këto janë tuples, jo bajtë, prandaj nuk mund të kthehemi dhe të bëjmë atë në bajtë.
Bazuar në këto të dhëna, ne mund të ndërtojmë, kështu quhen, tabelat TopN. Për shembull, Top-5, Top-10. Dhe mund të ndjekim ato tabela "të nxehta" që përdoren më shumë se të tjerat. Për shembull, 5 tabelat "e nxehta" me insertim. Dhe bazuar në këto tabela TopN, ne vlerësojmë ngarkesën tonë dhe mund të vlerësojmë shpërthimet e ngarkesës pas çdo lëshimi, përditësimi dhe deploji.
Gjithashtu është e rëndësishme të vlerësojmë përmasat e tabelave, sepse ndonjëherë zhvilluesit lëshojnë një veçori të re dhe tabelat tona fillojnë të fryhen në përmasat e tyre të mëdha, sepse vendosin të shkruajnë një volum të shtuar të të dhënave, por nuk parashikojnë si do të ndikojë kjo në madhësinë e bazës së të dhënave. Këto raste gjithashtu ndodhin dhe janë surpriza për ne.
Dhe tani një pyetje e vogël për ju. Cila është pyetja që lind kur vëreni ngarkesën në serverin me bazën e të dhënave? Cila është pyetja tjetër që ju lind?
Por në të vërtetë pyetja që lind është kjo. Cilët janë kërkesat që shkaktojnë ngarkesë? Pra, nuk është interesante të shikosh proceset që shkaktojnë ngarkesën. E kuptueshme, nëse hosti ka bazën e të dhënave, atëherë aty është e drejtuar baza e të dhënave dhe e qartë se vetëm baza e të dhënave do të përdorë aty. Nëse hapim Top, do të shohim një listë procesesh në PostgreSQL që bëjnë diçka. Nga Top do të jetë e paqartë se çfarë bëjnë ata.
Pra, është e nevojshme të zbulojmë ato kërkesa që shkaktojnë ngarkesën më të madhe, sepse tuning i kërkesave, zakonisht, sjell më shumë përfitim sesa tuning i konfigurimit të PostgreSQL ose sistemit operativ, ose madje tuning i harduerit. Sipas vlerësimit tim – kjo është rreth 80-85-90%. Dhe kjo bëhet shumë më shpejt. Është më e lehtë të korrigjosh një kërkesë, sesa të korrigjosh konfigurimin, të planifikosh një rinisje, veçanërisht nëse nuk lejohet rinisja e bazës, ose të shtosh harduer. Më e thjeshtë është të riformatosh ndonjë kërkesë apo të shtosh një indeks për të marrë një rezultat më të mirë nga kjo kërkesë.
Prandaj, duhet të monitorojmë kërkesat dhe adekvatësinë e tyre. Le të marrim një shembull tjetër të monitorimit. Dhe këtu gjithashtu duket një monitorim i shkëlqyer. Ka informacione mbi replikimin, ka informacione mbi kapacitetin, bllokimet, shfrytëzimin e resurseve. E gjithë kjo është e shkëlqyer, por nuk ka informacione mbi kërkesat. Nuk është e qartë se cilat kërkesa po ekzekutohen në bazën tonë të të dhënave, sa gjatë po ekzekutohen, sa janë këto kërkesa. Ne duhet të kemi gjithmonë këtë informacion në monitorim.
Dhe për të marrë këtë informacion ne mund të përdorim modulin pg_stat_statements. Në bazën e tij mund të ndërtojmë grafika të ndryshme. Për shembull, mund të marrim informacione për kërkesat më të zakonshme, domethënë për ato kërkesa që ekzekutohen më shpesh. Po, pas deployeve gjithashtu është shumë e dobishme ta shohim dhe të kuptojmë nëse ka ndonjë shpërthim të kërkesave.
Mund të monitorojmë kërkesat më të gjata, domethënë ato kërkesa që ekzekutohen më gjatë. Ato funksionojnë në procesor, konsumojnë input-output. Ne gjithashtu mund ta vlerësojmë këtë sipas fushave total_time, mean_time, blk_write_time dhe blk_read_time.
Ne mund të vlerësojmë dhe të monitorojmë kërkesat më të rënda në aspektin e shfrytëzimit të resurseve, ato që lexojnë nga disku, ato që punojnë me memorie apo, përkundrazi, krijojnë një ngarkesë shkruese.
Mund të vlerësojmë edhe kërkesat më të bujshme. Këto janë ato kërkesa që kthejnë një numër të madh rreshtash. Për shembull, mund të jetë ndonjë kërkesë ku është harruar të vendoset një limit. Dhe ajo thjesht kthen gjithë përmbajtjen e tabelës ose kërkuesve të tabelave të kërkuara.
Dhe mund të monitorojmë gjithashtu kërkesat që përdorin skedarë temporarë ose tabela temporarë.
Dhe na kanë mbetur proceset e prapme. Proceset e prapme janë para së gjithash kontrollet, ose siç quhen ndryshe, pikët e kontrollit, autovacuum dhe replikimi.
Një tjetër shembull monitorimi. Ka një skedë Maintenance në majë, kalojmë në të dhe shpresojmë të shohim diçka të dobishme. Por këtu ka vetëm kohën e punës së vakuumit dhe mbledhjen e statistikave, asgjë më shumë. Kjo është shumë informacion i varfër, prandaj gjithmonë është e nevojshme të kem informacion se si funksionojnë proceset e prapme në bazën tonë të të dhënave dhe nëse ka ndonjë problem nga puna e tyre.
Kur shqyrtojmë pikët e kontrollit, duhet të mbajmë parasysh se pikët e kontrollit e shkarkojnë "faqet e ndotura" nga zona e memories së sharduar në disk, pastaj krijojnë një pikë kontrolli. Dhe kjo pikë kontrolli mund të përdoret si një vend për rikuperim, nëse ndonjëherë PostgreSQL është mbyllur në mënyrë të papritur.
Prandaj, për të shkarkuar të gjitha "faqet e ndotura" në disk, duhet të realizohet një sasi e caktuar shkruese. Dhe, si rregull, në sistemet me një sasi të madhe memories – kjo është shumë e madhe. Dhe nëse pikët e kontrollit bëhen shumë shpesh në një interval të shkurtër, atëherë performanca e diskut do të ulet shumë. Kërkesat e klientëve do të vuajnë nga mungesa e resurseve. Ato do të luftojnë për resurset dhe do t'u mungojë kapaciteti.
Prandaj, përmes pg_stat_bgwriter ne mund të monitorojmë numrin e pikëve të kontrollit që ndodhin. Dhe nëse për një periudhë të caktuar kohe (për 10-15-20 minuta, për gjysmë ore) ka shumë pika kontrolli, për shembuj, 3-4-5, atëherë kjo mund të jetë një problem. Dhe pastaj duhet të shohim në bazën e të dhënave, të shohim në konfigurim, çfarë po shkakton këtë përmbajtje të madhe të pikëve kontrolleve. Ndoshta, ka ndonjë shkarkim të madh. Në bazë të ngarkesës mund të vlerësojmë, sepse grafikat e ngarkesës janë tashmë të shtuar. Ne mund të rregullojmë parametrat e pikëve të kontrollit dhe të bëjmë që ato të mos ndikojnë shumë në performancën e kërkesave.
Po rikthehem sërish te autovacuum, sepse kjo është një gjë, siç kam thënë, që lehtësisht mund të dëmtojë performancën si të disqeve ashtu edhe të kërkesave, prandaj gjithmonë është e rëndësishme të vlerësojmë numrin e autovacuum.
Numri i punonjësve autovacuum në bazën e të dhënave është i kufizuar. Si rregull, janë tre, prandaj nëse gjithmonë kanë funksionuar tre punonjës në bazë, atëherë kjo do të thotë se autovacuum është i paqartë, duhet të rriten kufijtë, të rishikohen cilësimet e autovacuum dhe të hyhet në konfigurim.
Është e rëndësishme të vlerësojmë cilët punonjës po funksionojnë. Ose është një vakuum i nisur nga përdoruesi, DBA ka ardhur dhe ka nisur me duar ndonjë vakuum, dhe kjo krijoi një ngarkesë. Llogaritë ndonjë problem. Ose është numri i vakuumeve që rrisin numrin e transaksioneve. Për disa versione të PostgreSQL – këto janë vakuume shumë të rënda. Dhe ato mund të dëmtojnë lehtësisht performancën, sepse lexojnë të gjithë tabelën në tërësi, skanojnë të gjitha blloqet në këtë tabelë.
Dhe, sigurisht, është edhe kohëzgjatja e vakuumeve. Nëse kemi vakuume të gjata që funksionojnë për një kohë të gjatë, atëherë duhet të shqyrtojmë përsëri konfigurimin e vakuumit dhe ndoshta të rishohim cilësimet e tij. Sepse mund të ndodhë që vakuumi të punojë për një kohë të gjatë mbi një tabelë (3-4 orë), por gjatë kohës së punës së vakuumit në tabelë janë akumuluar përsëri një sasi e madhe rreshtash të vdekur. Dhe sapo të përfundojë vakuumi, ai ka nevojë sërish të bëjë vakuum mbi këtë tabelë. Dhe arrijmë në situatën e vakuumit të pafund. Në këtë rast, vakuumi nuk përmbush detyrat e tij, dhe tabelat fillojnë të fryhen gradualisht në përmasa, ndonëse sasia e të dhënave të dobishme në to mbetet e njëjtë. Prandaj, gjatë vakuumeve të gjata, gjithmonë shqyrtojmë konfigurimin dhe përpiqemi ta optimizojmë atë, por pa e dëmtuar performancën e kërkesave të klientëve.
Tani praktikisht nuk ka instalimesh të PostgreSQL pa replikimin në rrjedhë. Replikimi është procesi i transferimit të të dhënave nga masteri në replik.
Replikimi në PostgreSQL funksionon nëpërmjet journalit të transaksioneve. Masteri gjeneron journalin e transaksioneve. Ky journal niset përmes lidhjes rrjet esë për në replikë, dhe më pas ai riprodhohet në replikë. E thjeshtë.
Prandaj, për monitorimin e vonesës së replikimit përdoret pamja pg_stat_replication. Por me të, nuk është gjithçka kaq e thjeshtë. Në versionin 10, pamja ka kaluar disa ndryshime. Së pari, disa fusha janë rinovuar. Disa fusha janë shtuar gjithashtu. Në versionin 10 janë shtuar fusha që lejojnë të vlerësohet vonesa e replikimit në sekonda. Kjo është shumë e dobishme. Para versionit 10, ishte e mundur të vlerësohej vonesa e replikimit në byte. Kjo mundësi ka mbetur edhe në versionin 10, pra, mund të zgjidhni se çfarë ju përshtatet më mirë – të vlerësoni vonesën në byte ose në sekonda. Shumë përdorin të dyja.
Megjithatë, për të vlerësuar vonesën e replikimit, është e nevojshme të dihet pozita e journalit në transaksion. Dhe këto pozita të journalit të transaksioneve ndodhen pikërisht në pamjen pg_stat_replication. Thënë ndryshe, me ndihmën e funksionit pg_xlog_location_diff() mund të marrim dy pika në journalin e transaksioneve. Të llogarisim diferencën mes tyre dhe të marrim vonesën e replikimit në byte. Kjo është shumë e dobishme dhe e thjeshtë.
Në versionin 10, ky funksion është rinovuar në pg_wal_lsn_diff(). Në përgjithësi, në të gjitha funksionet, pamjet, utilitetet, ku është hasur fjalën "xlog", është zëvendësuar me termin "wal". Kjo është një risitë e tillë.
Plus në versionin 10 janë shtuar linjat që tregojnë saktësisht vonesën. Kjo është vonesa e shkruar, vonesa e flush, vonesa e riprodhimit. Pra, këto janë gjëra të rëndësishme për tu monitoruar. Nëse shohim që kemi vonesë replikimi, duhet të hetojmë pse është shfaqur, nga ka ardhur dhe të zgjidhim problemin.
Me metrikat sistemore, pothuajse gjithçka është në rregull. Kur fillon çdo monitorim, ai fillon me metrikat sistemore. Këto janë përdorimi i procesorëve, memorie, swap, rrjeti dhe disku. Megjithatë, shumë parametra nuk janë aty nga default.
Nëse përdorimi i procesit është në rregull, atëherë problemet janë me përdorimin e disku. Si rregull, zhvilluesit e monitorimeve shtojnë informacion rreth kapacitetit të kalimit. Ky informacion mund të jetë në iops ose byte. Por harrojnë mbi latency dhe përdorimin e pajisjeve disk. Këto janë parametra më të rëndësishëm që lejojnë të vlerësohet sa janë të ngarkuar disqet dhe sa ngadalësojnë. Nëse kemi latency të lartë, kjo tregon se ka disa probleme me disqet. Nëse kemi përdorim të lartë, kjo do të thotë se disqet nuk po mundohen. Këto janë karakteristika më cilësore se kapaciteti i kalimit.
Duke pasur parasysh që kjo statistikë gjithashtu mund të merret nga sistemi i skedarëve /proc, siç bëhet për përdorimin e procesorëve. Pse kjo informacion nuk shtohet në monitorime, nuk e di. Megjithatë, është e rëndësishme të keni këtë në monitorimin tuaj.
Po ashtu për ndërfaqet rrjet. Ka informacion mbi kapacitetin e kalimit të rrjetit në paketa, në byte, por megjithatë nuk ka informacion mbi latency dhe nuk ka informacion mbi përdorimin, ndonëse kjo gjithashtu është informacion i dobishëm.
Çdo monitorim ka disavantazhe. Dhe çfarëdo monitorimi që të zgjidhni, gjithmonë do të ketë disa kritere që nuk përmbushen. Megjithatë, ata po zhvillohen, shtohen funksionalitete të reja, gjëra të reja, prandaj zgjidhni diçka dhe rregulloni.
Dhe për të rregulluar, është gjithmonë e nevojshme të keni një ide se çfarë do të thotë statistika që jepet dhe si me ndihmën e saj mund të zgjidhni probleme.
Dhe disa pika kryesore:
- Gjithmonë është e nevojshme të monitoroni disponueshmërinë, të keni tabela të kontrollit për të mundur të vlerësoni shpejt nëse gjithçka është në rregull me bazën.
- Është gjithmonë e nevojshme të keni një përsiatje se kush janë klientët që punojnë me bazën tuaj të të dhënave, për të filtruar klientët e këqij dhe për t'i eliminuar ata.
- Është e rëndësishme të vlerësoni se si këta klientë punojnë me të dhënat. Duhet të keni një përsiatje mbi ngarkesën tuaj të punës.
- Është e rëndësishme të vlerësoni se si formohet kjo ngarkesë, me çfarë kërkesash. Mund të vlerësoni kërkesat, t'i optimizoni ato, t'i riformoni, të ndërtoni indekse për to. Kjo është shumë e rëndësishme.
- Proceset në sfond mund të ndikojnë negativisht në kërkesat e klientëve, prandaj është e rëndësishme të ndiqni që ato të mos përdorin shumë burime.
- Metritë sistematike ju lejojnë të bëni plane për shkallëzim, për rritjen e kapacitetit të serverëve tuaj, prandaj është gjithashtu e rëndësishme t'i ndiqni dhe vlerësoni.
Nëse jeni të interesuar në këtë temë, mund të kaloni nëpër këto lidhje.
— kjo është dokumentacioni zyrtar me kolektorin e statistikave. Aty ka një përshkrim të të gjitha pamjeve statistikore dhe përshkrimin e të gjitha fushave. Mund t'i lexoni, t'i kuptoni dhe t'i analizoni. Dhe tashmë mbi bazën e tyre të ndërtoni grafikat tuaja, t'i shtoni në monitorimet tuaja.
Shembuj kërkesash:
Ky është repositori ynë korporativ dhe ai im. Aty ka shembuj kërkesash. Nuk ka kërkesa si të seria select* from diçka atje. Aty ka kërkesa të gatshme me bashkëngjitje, me përdorimin e funksioneve interesante, që lejojnë që nga numrat e papërpunuar të bëhen vlera të lexueshme dhe të dobishme, dmth. kjo është byte, koha. Mund t'i shqyrtoni ato, t'i shikoni, t'i analizoni, t'i shtoni në monitorimet tuaja, të ndërtoni mbi to monitorimet tuaja.
Pyetje
Pyetje: Thuat se nuk do të reklamoni marka, por gjithsesi më intereson – në projektet tuaja çfarë dashboard-e përdorni?
Përgjigje: Në mënyra të ndryshme. Ndonjëherë shkojmë te klienti dhe ai ka tashmë monitorimin e tij. Dhe ne e këshillojmë klientin mbi atë çfarë duhet të shtohet në monitorimin e tij. Kjo qëndron më keq me Zabbix-in. Sepse ai nuk ka mundësinë të ndërtojë grafika TopN. Vetë ne përdorim , sepse i kemi konsultuar këta djem për monitorimin. Ata bënë monitorimin PostgreSQL mbi bazën e TËNDSHMEVE tona. Po zhvilloj projektin tim personal, i cili mbledh të dhënat përmes Prometheus dhe i vizaton ato në . Kam për qëllim të bëj një eksportues të ri për Prometheus dhe pastaj të vizatoj gjithçka në Grafana.
Pyetje: A ka ndonjë ekuivalent të raporteve AWR ose ... agregimeve? A dini për ndonjë gjë të tillë?
Përgjigje: Po, unë e di se çfarë është AWR, është një send i shkëlqyer. Në këtë moment ka shumë lloje të ndryshme që realizojnë përafërsisht këtë model. Me një interval të caktuar kohe shkruhen disa baseline në të njëjtin PostgreSQL ose në një depo të veçantë. Mund t'i kërkoni në internet, ato ekzistojnë. Një nga zhvilluesit e një sendi të tillë është në forumin sql.ru në temën PostgreSQL. Mund ta kapni atje. Po, këto gjëra ekzistojnë, mund të përdoren. Plus në unë gjithashtu po shkruaj një send që lejon të bëjë të njëjtën gjë.
P.S.1 Nëse po përdorni postgres_exporter, çfarë dashboard-i përdorni? Atje ka disa. Ato janë tashmë të vjetruara. A mundet komuniteti të krijojë një template të azhurnuar?
P.S.2 E hoqa pganalyze, pasi është një ofrim SaaS të pronarit i cili përqendrohet në monitorimin e performancës dhe sugjerimet për optimizimin automatizuar.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
Cili monitorim self-hosted për postgresql (me dashboard) e konsideroni më të mirin?
30,0%Zabbix + shtesat nga Aleksei Lesovski ose zabbix 4.4 ose 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 është një SaaS i pronarit – nuk mund ta heq!
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 përdorues kanë votuar. 26 përdorues janë abstenuar.
Burimi: habr.com
