Hyrje filozofike
Siç dihet, ekzistojnë vetëm dy metoda për zgjidhjen e problemeve:
- Metoda e analizës ose metoda e deduksionit, ose nga e përgjithshmja në të veçantën.
- Metoda e sintezës ose metoda e induksionit, ose nga e veçantja në të përgjithshmen.
Për të zgjidhur problemin "përmirësimi i performancës së bazës së të dhënave" kjo mund të duket ashtu:
Analiza — e analizojmë problemin në pjesë të veçanta dhe duke i zgjidhur ato, përpiqemi të përmirësojmë në fund performancën e bazës së të dhënave në mënyrë të përgjithshme.
Në praktikë analiza duket kështu:
- Ndodhet problemi (incidenti i performancës)
- Mblidhim informacion statistikor mbi gjendjen e bazës së të dhënave
- Kërkojmë ngushticat (bottlenecks)
- Zgjidhim problemet me ngushticat
Ngushticat e bazës së të dhënave — infrastruktura (CPU, Memoria, Disku, Rrjeti, OS), cilësimet (postgresql.conf), kërkesat:
Infrastruktura: mundësitë për ndikuar dhe ndryshuar për inxhinierin — pothuajse zero.
Cilësimet e bazës së të dhënave: mundësitë për ndryshime pak më të mëdha sesa në rastin e mëparshëm, por në rregull zakonisht të vështira, veçanërisht në re.
Kërkesat për bazën e të dhënave: zona e vetme për manovra.
Sinteza — përmirësojmë performancën e pjesëve individuale, duke pritur që në fund performanca e bazës së të dhënave të përmirësohet.
Hyrje lirike ose pse e gjithë kjo është e nevojshme
Si ndodh processi i zgjidhjes së incidenteve të performancës, nëse performanca e bazës së të dhënave nuk monitorohet:
Klienti -"na ndodhin gjëra të këqija, është e gjatë, na bëni që të jetë mirë"
Inxhinieri -"çfarë është keq?"
Klienti –"po kështu si tani (një orë më parë, dje, herën e kaluar), është ngadalë"
Inxhinieri – "kur ishte mirë?"
Klienti – "një javë (dy javë) më parë ishte mjaft mirë." (Kjo ishte një rast me fat)
Klienti – "dhe nuk e mbaj mend kur ishte mirë, por tani është keq" (Përgjigja e zakonshme)
Si rezultat del një pamje klasike:
Kush është fajtor dhe çfarë të bëjmë?
Për pjesën e parë të pyetjes është më e lehtë të përgjigjesh — gjithmonë është faji i inxhinierit DBA.
Për pjesën e dytë është gjithashtu e thjeshtë të përgjigjesh — nevojitet të implementohet një sistem monitorimi të performancës së bazës së të dhënave.
Ndodhet pyetja e parë — çfarë të monitorojmë?
Rruga 1. Do të monitorojmë GJITHÇKA
Ngarkesën e CPU, numrin e operacioneve të leximit/shkruajtjes së disqeve, madhësinë e memories të dedikuar, dhe një ton e ndryshme matësish që çdo sistem monitorimi më shumë ose më pak funksional mund të ofrojë.
Rezultati janë një grumbull grafikësh, tabelash përmbledhëse dhe njoftime të vazhdueshme në email, duke shkaktuar 100% angazhim të inxhinierit me zgjidhjen e shumë biletave të ngjashëm, të cilët zakonisht kanë formulimin standard - “Problem përkohësor. Nuk kërkohet veprim.” Por, të gjithë janë të zënë dhe gjithmonë ka diçka për të treguar klientit — puna është në zhvillim.
Rruga 2. Monitoroni vetëm atë që është e nevojshme, ndërsa ajo që nuk është e nevojshme, nuk duhet monitoruar.
Mund të monitoroni, disi ndryshe - vetëm entitetet dhe ngjarjet:
- Të cilat inxhinieri DBA mund të ndikojë.
- Për të cilat ekziston një algoritëm veprimi në rast të ndodhjes së një ngjarjeje ose ndryshimit të entitetit.
Duke u bazuar në këtë supozim dhe duke kujtuar “Hyrje filozofike” me qëllim që të shmangen përsëritjet e rregullta të “Hyrje lirike ose pse e gjithë kjo është e nevojshme” do të ishte e arsyeshme të monitoroni performancën e kërkesave individuale, për optimizim dhe analizë, që në fund do të çojë në përmirësimin e performancës së të gjithë bazës së të dhënave.
Por, për të përmirësuar një kërkesë të rëndë, që ndikon në performancën e përgjithshme të bazës së të dhënave, duhet së pari ta gjeni atë.
Kështu, lindin dy pyetje të ndërlidhura:
- cila kërkesë konsiderohet e rëndë
- si të kërkoni kërkesat e rëndë.
Sigurisht, një kërkesë e rëndë është ajo që përdor shumë burime të OS për të marrë rezultatet.
Tani kalojmë te pyetja e dytë — si të kërkoni dhe më pas të monitoroni kërkesat e rëndë?
Çfarë mundësish për monitorimin e kërkesave ka në PostgreSQL?
Në krahasim me Oracle, mundësitë janë pak, por prapë disa gjëra mund të bëhen.
PG_STAT_STATEMENTS
Për të gjetur dhe monitoruar kërkesat e rënda në PostgreSQL, është dizajnuar zgjerimi standard pg_stat_statements.
Pasi të instalohet zgjerimi, në bazën e të dhënave të synuara do të shfaqet një pamje me të njëjtin emër, e cila duhet të përdoret për qëllime monitorimi.
Kolonat e synuara të pg_stat_statements për ndërtimin e një sistemi monitorimi:
- queryid Kodi i brendshëm hash, i llogaritur sipas pemës së analizës së shprehjes.
- max_time Koha maksimale e shpenzuar për operatorin, në milisekonda.
Duke akumuluar dhe duke përdorur statistikat për këto dy kolona, mund të ndërtohet një sistem monitorimi.
Si përdoret pg_stat_statements për monitorimin e performancës së PostgreSQL?
Për monitorimin e performancës së kërkesave përdoret:
Në anën e bazës së të dhënave që synohet — pamja pg_stat_statements.
Nga ana e сервера dhe bazës së të dhënave të monitorimit — një set skriptesh bash dhe tabela shërbimi.
Hapi 1 — mbledhja e të dhënave statistikore
Në hostin e monitorimit, në mënyrë periodike ekzekutohet një skript që kopjon përmbajtjen e paraqitjes pg_stat_statements nga baza e të dhënave për pjesën destinuese në tabelën pg_stat_history në bazën e të dhënave të monitorimit.
Në këtë mënyrë, formohet një histori e ekzekutimeve të kërkesave, e cila mund të përdoret për të krijuar raporte të performancës dhe për të rregulluar metriken.
Hapi 2 — konfigurimi i metrikeve të performancës
Duke u bazuar në të dhënat e mbledhura, ne zgjedhim kërkesat që janë më kritike/vendimtare për klientin (aplikacionin). Pas miratimit me klientin, ne vendosim vlerat e metrikeve të performancës duke përdorur fushat queryid dhe max_time.
Rezultati — në fillim të monitorimit të performancës
- Skripti i monitorimit, kur ekzekutohet, kontrollon metriket e konfigurura të performancës duke krahasuar vlerën max_time të metrikes me vlerën nga paraqitja pg_stat_statements në bazën e të dhënave për pjesën destinuese.
- Nëse vlera në bazën e të dhënave për pjesën destinuese kalon vlerën e metrikes – krijohet një paralajmërim (incident në sistemin e tiketave)
Mundësia shtesë 1
Historia e planit të ekzekutimit të kërkesave
Për të zgjidhur incidentet e performancës, është shumë mirë të kemi një histori të ndryshimeve të planeve të ekzekutimit të kërkesave.
Për ruajtjen e historisë, përdoret tabela shërbimit log_query. Tabela plotësohet gjatë analizës së skedarit të ngarkuar të logut PostgreSQL. Ndryshe nga paraqitja pg_stat_statements, skedari i logut përmban tekstin e plotë me vlerat e parametrave të ekzekutimit, jo tekstin e normalizuar, duke i dhënë mundësinë të ruajë jo vetëm kohën dhe gjatësi të kërkesave, por edhe të ruajë planet e ekzekutimit në momentin aktual.
Mundësia shtesë 2
Procesi i vazhdueshëm i përmirësimit të performancës
Monitorimi i kërkesave të veçanta, në përgjithësi, nuk është i destinuar për të zgjidhur problemin e përmirësimit të vazhdueshëm të performancës së bazës së të dhënave si një e tërë, për shkak se kontrollon dhe zgjidh problemet e performancës vetëm për kërkesa të veçanta. Megjithatë, metoda mund të zgjerohet dhe të konfigurohet për të monitoruar kërkesat për të gjitha bazat e të dhënave.
Për këtë, është e nevojshme të introduktohen metrike të reja të performancës:
- Për ditët e fundit
- Për periudhën bazë
Skripti zgjidh kërkesat nga pamja pg_stat_statements në bazën e të dhënave të synuar dhe krahason vlerën e max_time me mesataren e max_time, në rastin e parë për ditët e fundit ose për periudhën e zgjedhur të kohës (baseline), në rastin e dytë.
Kështu, në rast të degradimit të performancës për çdo kërkesë, një paralajmërim do të formohet automatikisht, pa analizë manuale të raporteve.
Po çfarë lidhje ka me sintezën?
Në qasjen e përshkruar, siç parashikon metoda e sintezës — duke përmirësuar pjesë të veçanta të sistemit, ne përmirësojmë sistemin në tërësi.
- Kërkesa e ekzekutuar nga baza e të dhënave – teza
- Kërkesa e ndryshuar – antiteza
- Ndryshimi i gjendjes së sistemit — sinteza
Zhvillimi i sistemit
- Zgjerimi i statistikave të mbledhura duke shtuar historinë për pamjen sistemike pg_stat_activity
- Zgjerimi i statistikave të mbledhura duke shtuar historinë për statistikat e tabelave të veçanta të përfshira në kërkesa
- Integrimi me sistemin e monitorimit në облакы AWS
- Dhe gjithashtu, mund të mendoni për diçka tjetër…
Burimi: habr.com
