Hyrje filozofike
Siç dihet, ekzistojnë dy metoda për zgjidhjen e problemeve:
- Metoda e analizës ose metoda e deduktimit, nga e përgjithshmja në të veçantën.
- Metoda e sintezës ose metoda e induksionit, nga të veçantat 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 si më poshtë.
Analiza â analizojmĂ« problemin nĂ« pjesĂ« tĂ« veçanta dhe duke i zgjidhur ato, pĂ«rpiqemi tĂ« pĂ«rmirĂ«sojmĂ« performancĂ«n e pĂ«rgjithshme tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave.
Në praktikë, analiza duket përafërsisht kështu:
- Shfaqet një problem (incident performancës)
- Mblidhemi informacion statistikor mbi gjendjen e bazës së të dhënave
- Kërkojmë ngushtica (bottlenecks)
- Zgjidhim problemet e ngushticave
Ngushticat e bazĂ«s sĂ« tĂ« dhĂ«nave â infrastruktura (CPU, Memorie, Disqe, Rrjeti, OS), konfigurimet (postgresql.conf), pyetjet:
Infrastruktura: mundĂ«sitĂ« pĂ«r ndikim dhe ndryshim pĂ«r inxhinierin â pothuajse zero.
Cilësimet e bazës së të dhënave: mundësitë për ndryshime janë pak më të shumta sesa në rastin e mëparshëm, por zakonisht janë mjaft të vështira, veçanërisht në re.
Kërkesat për bazën e të dhënave: e vetmja zonë për manovra.
SintezĂ« â pĂ«rmirĂ«sojmĂ« performancĂ«n e pjesĂ«ve individuale, duke pritur qĂ« nĂ« pĂ«rfundim performanca e bazĂ«s sĂ« tĂ« dhĂ«nave tĂ« pĂ«rmirĂ«sohet.
Hyrje lirike ose pse na duhen të gjitha këto
Si ndodh procesi i zgjidhjes së incidenteve të performancës, nëse performanca e bazës së të dhënave nuk monitorohet:
Klienti - "gjendja jonë është keq, vonesa, na bëni të mirë"
Inxhinieri - "keq do të thotë si?"
Klienti â "ja si Ă«shtĂ« tani (para njĂ« ore, dje, nĂ« punĂ«n e kaluar), ngadalĂ«"
Inxhinieri â "kur ishte mirĂ«?"
Klienti â "para njĂ« jave (dy javĂ«) ishte mirĂ«." (Ishte fat)
Klienti â "nuk e mbaj mend kur ishte mirĂ«, por tani Ă«shtĂ« keq" (PĂ«rgjigja e zakonshme)
Si rezultat, përfundon një pamje klasike:
Kush është fajtor dhe çfarë të bëjmë?
Pjesa e parĂ« e pyetjes Ă«shtĂ« mĂ« e lehtĂ« pĂ«r t'u pĂ«rgjigjur â gjithmonĂ« Ă«shtĂ« inxhinieri DBA qĂ« Ă«shtĂ« fajtor.
Pjesa e dytĂ« gjithashtu nuk Ă«shtĂ« shumĂ« e vĂ«shtirĂ« â duhet tĂ« implementojmĂ« njĂ« sistem monitorimi pĂ«r performancĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave.
Shfaqet pyetja e parĂ« â ĂfarĂ« tĂ« monitorojmĂ«?
Rruga 1. Do të monitorojmë Tà GJITHA
Ngarkesën e CPU, numrin e operacioneve të leximit/shkrimit të diskut, madhësinë e memories së dedikuar, dhe një ton ndryshuesh kërkuesish të ndryshëm që çdo sistem monitorimi disi i funksionueshëm mund të ofrojë.
Si rezultat, merrni njĂ« grumbull grafikĂ«sh, tabelash pĂ«rmbledhĂ«se, dhe njoftime tĂ« vazhdueshme nĂ« email dhe ngarkesĂ« 100% pĂ«r inxhinierin pĂ«r tĂ« zgjidhur njĂ« grumbull biletash tĂ« ngjashme, megjithatĂ«, zakonisht me formulime standarde - "ĂĂ«shtje tĂ« pĂ«rkohshme. AsnjĂ« veprim i nevojshĂ«m". MegjithatĂ«, tĂ« gjithĂ« janĂ« tĂ« angazhuar, dhe gjithmonĂ« ka diçka pĂ«r tĂ« treguar pĂ«r klientin â puna po culminon.
Rruga 2. Monitoroni vetëm atë që është e nevojshme, dhe atë që nuk është e nevojshme, nuk duhet ta monitoroni
Mund të monitoroni, disi ndryshe - vetëm entitetet dhe ngjarjet:
- Për të cilat inxhinieri DBA mund të ndikojë
- Për të cilat ekziston një algoritëm veprimi në rast se ndodhin ngjarje ose ndryshime në entitet.
Duke e marrë këtë supozim dhe duke kujtuar "Hyrje filozofike" me qëllim që të shmangim përsëritjen e rregullt të "Hyrje lirike ose pse na duhen të gjitha këto", do të ishte e arsyeshme të monitoronim performancën e pyetjeve të veçanta, për optimizim dhe analizë, që në fund do të duhet 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ë, e cila ndikon në performancën e përgjithshme të bazës së të dhënave, duhet së pari ta gjejmë atë.
Pra, shfaqen dy pyetje të lidhura:
- Cila kërkesë konsiderohet e rëndë
- Si të kërkojmë kërkesat e rënda.
Natyrisht, një kërkesë e rëndë është ajo që përdor shumë burime të OS për të marrë rezultatin.
KalojmĂ« nĂ« pyetjen e dytĂ« â si tĂ« kĂ«rkojmĂ« dhe pastaj tĂ« monitorojmĂ« kĂ«rkesat e rĂ«nda?
Cilat janë mundësitë për monitorimin e pyetjeve në PostgreSQL?
Në krahasim me Oracle, mundësitë janë pak, por megjithatë disa gjëra mund të bëhen.
PG_STAT_STATEMENTS
Për të gjetur dhe monitoruar kërkesat e rënda në PostgreSQL, është zgjerimi standart pg_stat_statements.
Pas instalimit të zgjerimit në bazën e të dhënave qëllim, shfaqet një pamje e quajtur njësoj, e cila duhet të përdoret për qëllimet e monitorimit.
Kolonat e synuara pg_stat_statements për ndërtimin e një sistemi monitorimi:
- queryid Hesh kodi internal, i llogaritur mbi pemën e analizës së operatorit
- max_time Koha maksimale e kaluar për operatorin, në milisekonda
Duke akumuluar dhe përdorur statistikat mbi këto dy kolona, mund të ndërtojmë një sistem monitorimi.
Si përdoret pg_stat_statements për monitorimin e performancës në PostgreSQL
Për të monitoruar performancën e pyetjeve, përdoren:
NĂ« anĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave qĂ«llim â pamja pg_stat_statements
Nga ana e server dhe bazĂ«s sĂ« tĂ« dhĂ«nave tĂ« monitorimit â njĂ« grup skenesh bash dhe tabela shĂ«rbimi.
Faza 1 â mbledhja e tĂ« dhĂ«nave statistikore
Në serverin e monitorimit, një skript ekzekutohet rregullisht përmes cron që kopjon përmbajtjen e shfaqjes pg_stat_statements nga baza e të dhënave objektiv në tabelën pg_stat_history të bazës së të dhënave të monitorimit.
Kështu, formohet një histori e ekzekutimeve të kërkesave individuale, e cila mund të përdoret për të krijuar raporte mbi performancën dhe për të optimizuar metrikat.
Faza 2 â konfigurimi i metrikave tĂ« performancĂ«s
Bazuar në të dhënat e mbledhura, ne zgjedhim kërkesat të cilat janë më kritike/të rëndësishme për klientin (aplikacionin). Në përputhje me atë që është rënë dakord me porositësin, ne vendosim vlerat e metrikave të performancës duke përdorur fushat queryid dhe max_time.
Rezultati â nisja e monitorimit tĂ« performancĂ«s
- Skripti i monitorimit, në fillim të ekzekutimit, kontrollon metrikat e performancës të konfiguruara, duke krahasuar vlerën max_time të metrikës me vlerën nga shfaqja pg_stat_statements në bazën e të dhënave objektiv.
- NĂ«se vlera nĂ« bazĂ«n e tĂ« dhĂ«nave objektiv mbi kalon vlerĂ«n e metrikĂ«s â formohet njĂ« paralajmĂ«rim (incident nĂ« sistemin e biletave)
Mundësia shtesë 1
Historia e planeve të ekzekutimit të kërkesave
Për zgjidhjen e incidenteve të performancës, është shumë e dobishme të kemi historinë e ndryshimeve të planeve të ekzekutimit të kërkesave.
Për ruajtjen e historisë përdoret tabela ndihmëse log_query. Tabela mbushet gjatë analizës së skedarit të ngarkuar të regjistrave të PostgreSQL. Ndryshe nga shfaqja pg_stat_statements, në skedarin e regjistrit përfshihet teksti i plotë me vlerat e parametrave të ekzekutimit, dhe jo teksti i normalizuar, duke ofruar mundësinë për të regjistruar jo vetëm kohën dhe gjatëshmërinë e kërkesave, por edhe për të mbajtur 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 individuale, në përgjithësi, nuk është i krijuar për të zgjidhur problemin e përmirësimit të vazhdueshëm të performancës së bazës së të dhënave në tërësi, pasi ai kontrollon dhe zgjidh problemet e performancës vetëm për kërkesa të veçanta. Megjithatë, metoda mund të zgjerzohet dhe të konfigurohet monitorimi i kërkesave për të gjitha bazat e të dhënave.
Për këtë, është e nevojshme të futen metrika të tjera të performancës:
- Në ditët e fundit
- Për periudhën bazë
Skripti zgjedh kërkesat nga shfaqja pg_stat_statements në bazën e të dhënave objektiv dhe krahason vlerën max_time me vlerën mesatare max_time, në rastin e parë për ditët e fundit ose për periudhën e zgjedhur (baseline), dhe në të dytin.
Kështu, në rast se ndodh degradimi i performancës për çdo kërkesë, një paralajmërim do të formohet automatikisht, pa analizë manuale të raporteve.
E çfarë lidhje ka me sintezën?
NĂ« qasjen e pĂ«rshkruar, ashtu siç parashikon metoda e sintezĂ«s â duke pĂ«rmirĂ«suar pjesĂ«t e 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 modifikuar â antiteza
- Ndryshimi i gjendjes sĂ« sistemit â sinteza
Zhvillimi i sistemit
- Zgjerimi i statistikave të mbledhura duke shtuar historinë për shfaqjen sistematike pg_stat_activity
- Zgjerimi i statistikave të mbledhura duke shtuar historinë për statistikat e tabelave të veçanta që marrin pjesë në kërkesa
- Integrimi me sistemin e monitorimit në AWS
- Dhe për më tepër, mund të mendohet diçka tjetër...
Burimi: habr.com
