ProHoster > Blog > Administrim > Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

Hyrje filozofike

Siç dihet, ekzistojnë vetëm dy metoda për zgjidhjen e problemeve:

  1. Metoda e analizës ose metoda e deduksionit, ose nga e përgjithshmja në të veçantën.
  2. 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:

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

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

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

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.

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

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?

Sintetizimi si një nga metodat për përmirësimin 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 serverĂ« 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

  1. 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.
  2. 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

Sintetizimi si një nga metodat për përmirësimin e performancës së PostgreSQL

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

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster