Süntees kui üks meetod PostgreSQL töökindluse parandamiseks

Filosoofiline sissejuhatus

Nagu teada, on olemas ainult kaks meetodit probleemide lahendamiseks:

1. Analüüsi meetod või deduktsioonimeetod, ehk üldisest spetsiifiliseks.
2. Süntesi meetod või induktsioonimeetod, ehk spetsiifilisest üldiseks.

Probleemi "andmebaasi jõudluse parandamine" lahendamiseks võib see välja näha järgmiselt.

Analüüs — lahendame probleemi osadeks ja püüame neid lahendades parandada andmebaasi jõudlust tervikuna.

Praktikas näeb analüüs enamasti välja järgmiselt:

• Tekkib probleem (jõudlusinsident)
• Kogume statistilist teavet andmebaasi seisundi kohta
• Otsime kitsaskohti
• Lahendame kitsaskohtade probleemid

Andmebaasi kitsaskohad — infrastruktuur (CPU, mälu, kettad, võrk, opsüsteem), seaded (postgresql.conf), päringud:

Infrastruktuur: inseneril on peaaegu nullvõimalusi mõjutada ja muuta.

Andmebaasi seaded: muutmise võimalused on veidi suuremad kui eelmisel juhul, kuid reeglina siiski üsna keerukad, eriti pilvteenustes.

Päringud andmebaasile: ainus manööverdusruum.

Süntes — parandame üksikute osade jõudlust, oodates, et seetõttu parandub ka andmebaasi jõudlus.

Lüüriline sissejuhatus või miks seda kõike on vaja

Kuidas toimub jõudlusinsidentide lahendamise protsess, kui andmebaasi jõudlust ei jälgita:

Klient - "meil on kõik halb, aeglane, tehke meile hästi"
Insener - "halb, mis see tähendab?"
Klient - "niimoodi nagu praegu (tund tagasi, eile, eelmisel korral oli), aeglaselt"
Insener – "millal oli hea?"
Klient – "nädal (kaks nädalat) tagasi oli hästi." (See oli vedamine)
Klient – "ja ma ei mäleta, millal oli hea, aga praegu on halb" (Tavaline vastus)

Tulemuseks on klassikaline pilt:

Kes on süüdi ja mida teha?

Esimesele küsimusele on kergem vastata — süüdi on alati DBA insener.

Teisele küsimusele on samuti mitte liiga keeruline vastata — tuleb rakendada andmebaasi jõudluse jälgimise süsteem.

Tekkib esimene küsimus — mida jälgida?

Tee 1. Jälgime KÕIKE

CPU koormust, diskilugemise/kirjutamise operatsioonide arvu, eraldatud mälu suurust ja veel megatonni erinevaid loendureid, mida iga natukenegi töötav jälgimise süsteem võib pakkuda.

Tulemuseks on hulk graafikuid, kokkuvõtteid ja pidevad teavitused e-posti kaudu, mis samas koormavad inseneri, kes peab lahendama rohkearvulisi sarnaseid tikette, mille sisu on enamasti standardne - "Ajutine probleem. Tegutsemine ei ole vajalik". Kuid kõik on hõivatud ja alati on midagi, mida kliendile näidata - töö käib.

Teine tee. Jälgida ainult seda, mis on vajalik, ja mitte jälgida seda, mis ei ole vajalik.

Saame jälgida natuke teisiti - ainult isendite ja sündmuste põhjal:

• Kus insener DBA saab midagi mõjutada.
• Kus on olemas tegevusalgoritm, kui sündmus või isendi muudetakse.

Võttes arvesse seda eeldust ja meenutades "Filosoofiline sissejuhatus" eesmärgiga vältida regulaarset kordamist "Lüüriline sissejuhatus või miks seda kõike on vaja" oleks mõistlik jälgida üksikute päringute jõudlust, et optimeerida ja analüüsida, mis lõpuks peaks parandama kogu andmebaasi jõudlust.

Kuid selleks, et parandada raskesti täidetavat päringut, mis mõjutab kogu andmebaasi jõudlust, tuleb see esmalt leida.

Seega tekib kaks omavahel seotud küsimust:

• kuidas määratleda, mis on raske päring
• kuidas otsida raskesti täidetavaid päringuid.

Ilmselgelt on raske päring see, mis kasutab palju süsteemiressursse, et tulemust saada.

Liigume teise küsimuse juurde - kuidas otsida ja seejärel jälgida raskesti täidetavaid päringuid?

Millised on päringute jälgimise võimalused PostgreSQL-is?

Võrreldes Oracle'iga on võimalusi vähe, kuid siiski on midagi võimalik teha.

PG_STAT_STATEMENTS

Raskete päringute leidmiseks ja jälgimiseks PostgreSQL-is on mõeldud standardne laiendus pg_stat_statements.

Pärast laienduse installimist ilmub sihtandmebaasis samanimeline vaade, mida tuleb kasutada jälgimise eesmärkidel.

Sihtveergude pg_stat_statements määramine jälgimissüsteemi ülesehitamiseks:

• queryid Sisemine hash-kood, mis on arvutatud käsu analüüsi puu põhjal.
• max_time Maksimaalne aeg, mis on kulunud käsule, millisekundites.

Kogudes ja kasutades statistikat nende kahe veeru põhjal, saab luua jälgimissüsteemi.

Kuidas kasutada pg_stat_statements PostgreSQL-i jõudluse jälgimiseks

Päringute jõudluse jälgimiseks kasutatakse:
Sihtandmebaasis - vaade pg_stat_statements.
Poolt serverilt ja jälgimisandmebaasi - bash-skriptide kogumit ja teenindustabeleid.

1. etapp — statistiliste andmete kogumine

Monitooringuhostil käivitatakse regulaarselt skript, mis kopeerib pg_stat_statements vaate sisu sihtandmebaasist monitooringu andmebaasi pg_stat_history tabelisse.

Nii moodustatakse individuaalsete päringute täitmise ajalugu, mida saab kasutada tulemuslikkuse aruannete koostamiseks ja mõõdikute seadmiseks.

2. etapp — tulemuslikkuse mõõdikute seadmine

Kogutud andmete põhjal valime päringud, mille täitmine on kliendi (rakenduse) jaoks kõige kriitilisem/olulisem. Kooskõlastades tellijaga, seame tulemuslikkuse mõõdikute väärtused, kasutades queryid ja max_time väljade väärtusi.

Tulemus — tulemuslikkuse monitooringu alustamine

1. Monitooringu skript käivitamisel kontrollib konfigureeritud tulemuslikkuse mõõdikuid, võrreldes mõõdiku max_time väärtust sihtandmebaasi pg_stat_statements vaate väärtustega.
2. Kui sihtandmebaasi väärtus ületab mõõdiku väärtuse — genereeritakse hoiatus (insident piletisüsteemis).

Lisavõimalus 1

Päringute täidete plaanide ajalugu

Tulemuslikkuse probleemide lahendamiseks on väga kasulik omada päringute täidete plaanide muutumise ajalugu.

Ajaloo säilitamiseks kasutatakse teenindustabelit log_query. Tabelit täidetakse PostgreSQL-i laaditud logifaili analüüsi käigus. Kuna logifaili erinevalt pg_stat_statements vaatest sisaldab see täisteksti koos täitmise parameetrite väärtustega, mitte normaliseeritud teksti, on võimalik salvestada mitte ainult päringute aega ja kestust, vaid ka hetkeseisuga täidete plaane.

Lisavõimalus 2

Pideva tulemuslikkuse parandamise protsess

Eristatud päringute monitooring ei ole üldiselt mõeldud andmebaasi tervikliku tulemuslikkuse pidevaks parandamiseks, kuna see kontrollib ja lahendab tulemuslikkuse probleeme ainult individuaalsete päringute jaoks. Siiski on võimalik metoodikat laiendada ja seada päringute monitooring kõigi andmebaaside jaoks.

Selleks tuleb lisada täiendavad tulemuslikkuse mõõdikud:

• Viimase nädala jooksul
• Aluse perioodi jooksul

Skript valib päringud pg_stat_statements vaate põhjal sihtandmebaasis ja võrreldab max_time väärtust keskmise max_time-ga, esimese puhul viimase päevade või valitud ajavahemiku (baseline) osas, teise puhul.

Seega, kui igasuguste päringute jõudlus halveneb, siis teade genereeritakse automaatselt, ilma käsitsi aruannete analüüsita.

Mis asja on sünteesi juures?

Nagu kirjeldatud lähenemises, parendame süsteemi üldiselt, parandades selle erinevaid osi, nagu sünteesimismeetod seda ette näeb.

• Andmebaasi poolt täidetav päring – tees
• Muudetud päring – antitees
• Süsteemi staatuse muutmine – süntees

Süsteemi areng

• Statistika täiendamine, lisades ajaloo pg_stat_activity süsteemivaatesse
• Statistika täiendamine, lisades ajaloo eraldi tabelite statistikale, mis osalevad päringutes
• Integreerimine AWS pilve monitoreerimissüsteemiga
• Ja veel, midagi võiks välja mõelda…

Allikas: habr.com