Filosoofiline sissejuhatus
Nagu teada, on olemas kaks meetodit probleemide lahendamiseks:
- Analüüsimeetod või deduktiivne meetod, ehk üldisest eriliseks.
- Süntesimeetod või induktiivne meetod, ehk erilisest üldiseks.
Probleemi „andmebaasi jõudluse parandamine“ lahendamiseks võiks see välja näha järgmiselt.
Analüüs — jagame probleemi osadeks ja püüame neid lahendades üldiselt andmebaasi jõudlust parandada.
Praktikas näeb analüüs välja umbes selline:
- Tekkib probleem (jõudlusinsident)
- Kogume statistilist teavet andmebaasi seisundi kohta
- Otsime kitsaskohti
- Lahendame kitsaskohtadega seotud probleemid
Andmebaasi kitsaskohad — infrastruktuur (CPU, mälu, kettad, võrk, operatsioonisüsteem), seaded (postgresql.conf), päringud:
Infrastruktuur: inseneri muutmisvõimalused on peaaegu null.
Andmebaasi seadistused: muutmisvõimalused on veidi suuremad kui eelmisel juhul, kuid tavaliselt siiski üsna keerulised, eriti pilveteenustes.
Päringud andmebaasile: ainus manööverdusala.
Süntes — parandame üksikute osade jõudlust, lootes, et andmebaasi jõudlus paraneb.
Lüüriline sissejuhatus või miks seda kõike vaja on
Kuidas toimub jõudlust puudutavate probleemide lahendamise protsess, kui andmebaasi jõudlust ei jälgita:
Kliendi seisukoht - "meil on kõik halvasti, on aeglane, tehke meile hästi"
Insener - "aga mis on halb?"
Kliendi seisukoht – "nii on praegu (tund tagasi, eile, eelmisel korral oli), aeglane"
Insener – "aga millal oli hästi?"
Kliendi seisukoht – "nädal (kaks nädalat) tagasi oli päris hästi." (See oli õnneasi)
Kliendi seisukoht – "aga ma ei mäleta, millal oli hästi, aga praegu on halb" (Tavaline vastus)
Tulemusena saame klassikalise pildi:
Kes on süüdi ja mida teha?
Esimese küsimuse puhul on vastus kõige lihtsam — süüdi on alati DBA insener.
Teise osa küsimusele on vastus samuti üsna lihtne — on vaja rakendada andmebaasi jõudluse jälgimise süsteem.
Küsimus tekib — mida jälgida?
Teekond 1. Jälgime KÕIKE
CPU koormust, kettasalvestuse lugemis-/kirjutamisoperatsioonide arvu, reserveeritud mälu suurust ja veel meeletult erinevaid mõõdikuid, mida igasugused töötavad jälgimissüsteemid võivad pakkuda.
Tulemusena tekib hulk graafikuid, kokkuvõtteid ja pidevad teavitused e-postile ning 100% hõivatuse tõttu insener, kes lahendab hulga sarnaseid pileteid, kuigi enamikul juhtudel on need standardse vormuleeringuga — "Ajutine probleem. Tegutsemist ei ole vaja". Aga kõik on hõivatud ning alati on näidata kliendile — töö käib.
Teine tee. Jälgige ainult seda, mis on vajalik, ja seda, mis ei ole vajalik, ei tohiks jälgida.
Jälgimist on võimalik korraldada natuke teistmoodi—ainult üksuste ja sündmuste jaoks:
- Millele DBA insener saab mõjutada.
- Mille puhul on olemas tegevusalgoritm sündmuse või üksuse muutuse tekkimisel.
Võttes arvesse seda eeldust ja meenutades "Filosoofiline sissejuhatus" eesmärki vältida regulaarset kordamist "Lüüriline sissejuhatus või miks seda kõike vaja on", oleks mõistlik jälgida üksikute päringute jõudlust, et optimeerida ja analüüsida, mis lõpuks peaks viima kogu andmebaasi jõudluse paranemiseni.
Kuid et parandada suure koormusega päringut, mis mõjutab andmebaasi üldist tulemuslikkust, tuleb see esmalt tuvastada.
Seega tekib kaks omavahel seotud küsimust:
- milline päring loetakse suure koormusega
- kuidas otsida suure koormusega päringuid.
Ilmselgelt on suure koormusega päring see, mis kasutab tulemuse saamiseks palju süsteemi ressursse.
Liigume teise küsimuse juurde — kuidas otsida ja jälgida suure koormusega päringuid?
Millised on päringute jälgimise võimalused PostgreSQL-is?
Oracle'iga võrreldes on võimalusi veidi vähem, kuid siiski saab midagi teha.
PG_STAT_STATEMENTS
Suure koormusega päringute otsimiseks ja jälgimiseks on PostgreSQL-is määratud standardne laiendus pg_stat_statements.
Pärast laienduse installimist tekib sihtandmebaasis samanimeline vaade, mida tuleb kasutada jälgimise eesmärkidel.
Sihtcolumns pg_stat_statements monitooringu süsteemi väljatöötamiseks:
- queryid Sisemine hash-kood, mis on arvutatud operaatori süntaksipuust
- max_time Maximaalne aeg, mis on operaatori jaoks kulutatud, millisekundites
Kogudes ja kasutades statistikat nende kahe veeru kohta, saab ehitada jälgimissüsteemi.
Kuidas kasutatakse pg_stat_statements PostgreSQL jõudluse jälgimiseks
Küsimuste jõudluse jälgimiseks kasutatakse:
Sihtandmebaasi küljest - vaade pg_stat_statements
Jälgimise serverile ja andmebaasi puhul - bash-skriptide ja teenustabelite kogum.
1. etapp - statistiliste andmete kogumine
Jälgimise hostis käivitatakse regulaarselt skript, mis kopeerib pg_stat_statements vaate sisu sihtandmebaasist jälgimisandmebaasi tabelisse pg_stat_history.
Seega moodustatakse eraldi päringute sooritamise ajalugu, mida saab kasutada jõudlusaruannete koostamiseks ja mõõdikute seadistamiseks.
2. etapp - jõudluse mõõdikute seadistamine
Kogutud andmete põhjal valime välja päringud, mille täitmine on kliendi (rakenduse) jaoks kõige kriitilisem/olulisem. Klientidega kokkuleppimise järgi seame jõudluse mõõdikud queryid ja max_time väljade kaudu.
Tulemus - jõudluse jälgimise alustamine
- Jälgimiste skript kontrollib käivitamisel konfigureeritud jõudlusmõõdikuid, võrreldes max_time mõõdiku väärtust sihtandmebaasi pg_stat_statements esitluses oleva väärtusega.
- Kui väärtus sihtandmebaasis ületab mõõdiku väärtuse, genereeritakse hoiatus (insident piletite süsteemis).
Lisavõimalus 1
Küsimuste täitmisplaanide ajalugu
Jõudlusprobleemide edasiseks lahendamiseks on väga kasulik omada küsimuste täitmisplaanide muutmise ajalugu.
Ajaloo salvestamiseks kasutatakse teenustabelit log_query. Tabelit täidetakse PostgreSQL logifaili analüüsimisel. Kuna logifaili, erinevalt pg_stat_statements esitlusest, salvestatakse täisteksti koos täitmisparameetrite väärtustega, mitte normaliseeritud tekstina, on võimalik jälgida mitte ainult küsimuste aega ja kestust, vaid ka hoida täitmisplaane antud ajahetkel.
Lisavõimalus 2
Jätkuv jõudluse parendamise protsess
Konkreetsete päringute jälgimine ei ole üldiselt mõeldud andmebaasi jõudluse pideva parandamise ülesande lahendamiseks, kuna see kontrollib ja lahendab jõudluse probleeme ainult üheainsa päringu osas. Siiski on võimalik meetodit laiendada ja seadistada jälgimiseks kõiki andmebaase.
Selleks tuleb sisestada täiendavad jõudluse mõõdikud:
- Viimaste päevade jooksul
- Aluspõhja periood
Skript valib päringud sihitud andmebaasi pg_stat_statements vaate kaudu ja võrdleb max_time väärtust keskmise max_time väärtusega, esimeses juhul viimaste päevade jooksul või valitud ajavahemiku (baseline) jooksul, teises juhul.
Seega juhul, kui mõne päringu jõudlus halveneb, genereeritakse automaatselt hoiatust, ilma käsitsi aruannete analüüsita.
Aga mis seos on sünteesiga?
Kirjeldatud lähenemises, nagu sünteesi meetod ette näeb, parendades süsteemi üksikute osade abil, parendame süsteemi tervikuna.
- Andmebaasi täidetav päring – tees
- Muudetud päring – antitees
- Süsteemi seisundi muutmine — süntees
Süsteemi areng
- Statistika suurendamise laiendamine ajaloo lisamisega süsteemse kuvamise pg_stat_activity jaoks
- Statistika suurendamise laiendamine ajaloo lisamisega individuaalsete tabelite statistika jaoks, mis osalevad päringutes
- Integreerimine AWS-i pilve järelevalvesüsteemiga
- Ja veel, saame midagi välja mõelda…
Allikas: habr.com
