Introducere filosofică
După cum se știe, există doar două metode pentru rezolvarea problemelor:
- Metoda analizei sau metoda deducției, sau de la general la particular.
- Metoda sintezei sau metoda inducerii, sau de la particular la general.
Pentru a rezolva problema "îmbunătățirea performanței bazei de date", aceasta poate arăta astfel.
Analiză — descompunem problema în părți separate și, rezolvându-le, încercăm să îmbunătățim performanța bazei de date în ansamblu.
În practică, analiza arată cam așa:
- Apasă problema (incident de performanță)
- Colectăm informații statistice despre starea bazei de date
- Căutăm punctele slabe (bottlenecks)
- Rezolvăm problemele de la punctele slabe
Punctele slabe ale bazei de date — infrastructură (CPU, Memorie, Discuri, Rețea, OS), setări (postgresql.conf), interogări:
Infrastructură: posibilitățile de influență și schimbare pentru inginer — aproape nule.
Setări bază de date: posibilitățile de schimbare sunt puțin mai mari decât în cazul anterior, dar, de obicei, sunt totuși destul de dificile, mai ales în cloud.
Cererile la baza de date: singura zonă pentru manevre.
Sinteză — îmbunătățim performanța părților individuale, așteptând că, în consecință, performanța bazei de date să se îmbunătățească.
Introducere lirică sau de ce este necesar tot acest lucru
Cum decurge procesul de soluționare a incidentelor de performanță, dacă performanța bazei de date nu este monitorizată:
Clientul - "avem probleme, lent, faceți-ne bine"
Inginerul - "ce înseamnă rău?"
Clientul – "așa cum este acum (cu o oră în urmă, ieri, în ultima dată a fost), lent"
Inginerul – "dar când a fost bine?"
Clientul – "acum o săptămână (două săptămâni) a fost bine" (a avut noroc)
Clientul – "dar nu-mi amintesc când a fost bine, dar acum e rău" (răspuns obișnuit)
Ca rezultat, apare imaginea clasică:
Cine este de vină și ce trebuie făcut?
Pentru prima parte a întrebării, răspunsul este cel mai ușor — întotdeauna este de vină inginerul DBA.
Pentru a doua parte, răspunsul nu este prea complicat — trebuie implementat un sistem de monitorizare a performanței bazei de date.
Se pune prima întrebare — ce să monitorizăm?
Calea 1. Vrem să monitorizăm TOTUL
Încărcarea CPU, numărul operațiunilor de citire/scriere pe disc, dimensiunea memoriei alocate și o megatonă de alți indicatori pe care orice sistem de monitorizare mai mult sau mai puțin funcțional îi poate oferi.
Rezultatul este o mulțime de grafice, tabele pivot și notificări continue pe e-mail, iar inginerul este 100% ocupat cu rezolvarea unui număr mare de tichete asemănătoare, de regulă cu aceeași formulare standard — „Problemă temporară. Nu este necesară nicio acțiune”. În schimb, toți sunt ocupați și există întotdeauna ceva de arătat clientului — munca avansează.
Calea 2. Monitorizează doar ceea ce este necesar, iar ceea ce nu este necesar, nu trebuie monitorizat.
Se poate monitoriza, puțin diferit — doar entitățile și evenimentele:
- La care inginerul DBA poate influența.
- Pentru care există un algoritm de acțiune în cazul apariției unui eveniment sau al unei modificări a entității.
Pornind de la această presupunere și amintind de „Introducere filosofică„ cu scopul de a evita repetarea regulată a „Introducere lirică sau de ce este necesar tot acest lucru„, ar fi rațional să monitorizăm performanța anumitor interogări, pentru optimizare și analiză, ceea ce ar trebui, în cele din urmă, să conducă la îmbunătățirea vitezei generale a bazei de date.
Dar, pentru a îmbunătăți o interogare grea, care afectează performanța generală a bazei de date, trebuie mai întâi să o găsim.
Așadar, apar două întrebări interconectate:
- care interogare este considerată grea
- cum se caută interogările grele.
Este evident că o interogare grea este cea care folosește multe resurse ale sistemului de operare pentru a obține un rezultat.
Trecem la a doua întrebare — cum să căutăm și apoi să monitorizăm interogările grele?
Ce opțiuni pentru monitorizarea interogărilor există în PostgreSQL?
Comparativ cu Oracle, opțiunile sunt puține, dar totuși se poate face ceva.
PG_STAT_STATEMENTS
Pentru căutarea și monitorizarea interogărilor grele în PostgreSQL, există extensia standard pg_stat_statements.
După instalarea extensiei, în baza de date țintă apare o vedere omonimă, care trebuie utilizată în scopuri de monitorizare.
Coloanele țintă pg_stat_statements pentru construirea sistemului de monitorizare:
- queryid Cod hash intern, calculat pe baza arborilor de analiză a operatorilor
- max_time Timpul maxim petrecut pe operator, în milisecunde
Strângând și utilizând statistica pe aceste două coloane, se poate construi un sistem de monitorizare.
Cum este utilizat pg_stat_statements pentru monitorizarea performanței PostgreSQL
Pentru monitorizarea performanței interogărilor se utilizează:
Pe partea bazei de date țintă — vederea pg_stat_statements
Din partea server și a bazei de date de monitorizare — un set de scripturi bash și tabele de servicii.
Etapa 1 — colectarea datelor statistice
Pe gazda de monitorizare, un script este rulat în mod regulat prin cron, care copiază conținutul vizualizării pg_stat_statements din baza de date țintă în tabelul pg_stat_history din baza de date de monitorizare.
Astfel, se formează un istoric al executării cererilor individuale, care poate fi utilizat pentru generarea rapoartelor de performanță și configurarea metricilor.
Etapa 2 — configurarea metricilor de performanță
Pe baza datelor colectate, selectăm cererile a căror executare este cea mai critică/importantă pentru client (aplicație). De comun acord cu clientul, stabilim valorile metricilor de performanță folosind câmpurile queryid și max_time.
Rezultatul — începutul monitorizării performanței
- Scriptul de monitorizare, la pornire, verifică metricile de performanță configurate, comparând valoarea max_time a metricii cu valoarea din vizualizarea pg_stat_statements din baza de date țintă.
- Dacă valoarea din baza de date țintă depășește valoarea metricii – se generează un avertisment (incident în sistemul de ticketing)
Funcționalitate suplimentară 1
Istoricul planurilor de execuție a cererilor
Pentru a rezolva incidentele de performanță, este foarte util să avem un istoric al modificărilor planurilor de execuție a cererilor.
Pentru a stoca istoricul, se folosește o tabelă de servicii log_query. Tabela este completată în timpul analizei fișierului jurnal încărcat PostgreSQL. Deoarece în fișierul jurnal, spre deosebire de vizualizarea pg_stat_statements, apare textul complet cu valorile parametrilor de execuție și nu text normalizat, există posibilitatea de a păstra nu doar timpul și durata cererilor, ci și planurile de execuție la momentul actual.
Funcționalitate suplimentară 2
Proces continuu de îmbunătățire a performanței
Monitorizarea cererilor individuale, în general, nu este destinată soluționării problemei îmbunătățirii continue a performanței bazei de date în ansamblu, deoarece controlează și rezolvă problemele de performanță doar pentru cererile individuale. Totuși, metoda poate fi extinsă și setată pentru a monitoriza cererile pentru toate bazele de date.
Pentru aceasta, trebuie introduse metrici suplimentare de performanță:
- În ultimele zile
- Pentru perioada de bază
Scriptul selectează interogările din vizualizarea pg_stat_statements în baza de date țintă și compară valoarea max_time cu valoarea medie max_time, în primul caz pentru ultimele zile sau pentru perioada de timp aleasă (baseline), iar în al doilea caz.
Astfel, în cazul degradării performanței pentru orice interogare, un avertisment va fi generat automat, fără analiză manuală a rapoartelor.
Și ce legătură are sinteza cu asta?
În abordarea descrisă, așa cum sugerează metoda sintezei — îmbunătățind părțile individuale ale sistemului, îmbunătățim sistemul în ansamblu.
- Interogarea efectuată de baza de date – teza
- Interogarea modificată – antiteza
- Schimbarea stării sistemului — sinteza
Dezvoltarea sistemului
- Extinderea statisticilor colectate prin adăugarea istoricului pentru vizualizarea sistemului pg_stat_activity
- Extinderea statisticilor colectate prin adăugarea istoricului pentru statisticile tabelelor individuale implicate în interogări
- Integrarea cu sistemul de monitorizare din cloud AWS
- Și, mai departe, putem inventa ceva…
Sursa: habr.com
