Filozófiai bevezetés
Mint tudják, csak két módszer létezik a problémák megoldására:
- Az elemzési módszer vagy a levonás módszere, vagy az általánostól a konkrétig.
- Szintézismódszer vagy indukciós módszer, vagy az egyeditől az általánosig.
Az „adatbázis teljesítményének javítása” probléma megoldása érdekében ez így nézhet ki.
Elemzés — a problémát külön részekre bontva elemezzük, és ezek megoldásával igyekszünk az adatbázis egészének teljesítményét javítani.
A gyakorlatban az elemzés valahogy így néz ki:
- Probléma történik (teljesítmény-incidens)
- Statisztikai információk gyűjtése az adatbázis állapotáról
- Szűk keresztmetszetek keresése
- A problémákat a szűk keresztmetszetekből oldjuk meg
Adatbázis szűk keresztmetszetek - infrastruktúra (CPU, memória, lemezek, hálózat, operációs rendszer), beállítások (postgresql.conf), lekérdezések:
Infrastruktúra: Egy mérnök befolyásának és változásának lehetősége szinte nulla.
Adatbázis beállítások: a változtatási lehetőségek valamivel nagyobbak, mint az előző esetben, de általában még mindig elég nehézkesek, főleg felhőben.
kérelmek az adatbázisba: csak mozgástér.
szintézis — javítjuk az egyes részek teljesítményét, arra számítva, hogy ennek eredményeként javulni fog az adatbázis teljesítménye.
Lírai bevezető, vagy miért van szükség erre
Mi a folyamat a teljesítményincidensek megoldására, ha az adatbázis teljesítményét nem figyeli a rendszer:
Ügyfél – „Nálunk minden rossz, túl sokáig tart, tegyen valami jót értünk”
Mérnök - "Ez milyen rossz?"
A vevő – „most így van (egy órája, tegnap, utoljára volt), lassan”
Mérnök – „mikor volt jó?”
Ügyfél – „egy hete (két hete) nem volt rossz. "(Szerencse)
Ügyfél – „Nem emlékszem, mikor volt jó, de most rossz” (Rendszeres válasz)
Az eredmény egy klasszikus kép:
Ki hibáztatható és mit tegyen?
A kérdés első részére a legkönnyebb válaszolni – mindig a DBA mérnöke a hibás.
A második részt szintén nem túl nehéz megválaszolni - egy adatbázis-teljesítmény-figyelő rendszert kell megvalósítania.
Felmerül az első kérdés - mit kell figyelni?
1. út. MINDENT figyelni fogunk
CPU terhelés, lemez olvasási/írási műveletek száma, lefoglalt memória mérete és további megatonna különböző számlálók, amelyeket bármely többé-kevésbé működő megfigyelő rendszer képes biztosítani.
Az eredmény egy csomó grafikon, összefoglaló táblázat és folyamatos e-mail értesítések, valamint a 100%-ban elfoglalt mérnök egy csomó azonos jegyet megold, de általában a szabványos megfogalmazással - „Ideiglenes probléma. Nincs szükség intézkedésre." De mindenki elfoglalt, és mindig van mit mutatni az ügyfélnek – a munka javában folyik.
2. mód. Csak azt figyelje, amire szükség van, és azt, amire nincs szükség, azt nem kell figyelni
Kicsit másként csak entitásokat és eseményeket figyelhet meg:
- Melyik DBA mérnök befolyásolhatja
- Amihez létezik egy műveleti algoritmus, amikor egy esemény bekövetkezik vagy egy entitás megváltozik.
E feltevés alapján és emlékezve "Filozófiai bevezetés"a rendszeres ismétlés elkerülése érdekében"Lírai bevezető, vagy miért van szükség erre„Célszerű lenne figyelemmel kísérni az egyes lekérdezések teljesítményét optimalizálás és elemzés céljából, ami végső soron a teljes adatbázis teljesítményének javulását eredményezi.
De az adatbázis általános teljesítményét befolyásoló nehéz lekérdezések javításához először meg kell találnia azt.
Tehát két egymással összefüggő kérdés merül fel:
- mely kérést nehéznek tartják
- hogyan kereshet nehéz kérdésekre.
Nyilvánvaló, hogy a nehéz lekérdezés olyan lekérdezés, amely sok operációs rendszer erőforrást használ az eredmény eléréséhez.
Térjünk át a második kérdésre – hogyan keressünk, majd figyeljünk a nehéz lekérdezésekre?
Milyen lekérdezésfigyelő képességekkel rendelkezik a PostgreSQL?
Az Oracle-hez képest kevés a lehetőség, de valamit mégis lehet tenni.
PG_STAT_STATEMENTS
A PostgreSQL-ben végzett nehéz lekérdezések kereséséhez és figyeléséhez a szabványos pg_stat_statements kiterjesztést szánjuk.
A bővítmény telepítése után egy azonos nevű nézet jelenik meg a céladatbázisban, amelyet monitorozási célokra kell használni.
Célozza meg a pg_stat_statements oszlopokat a megfigyelőrendszer felépítéséhez:
- queryid Az operátor értelmezőfájából számított belső hash kód
- max_time A nyilatkozatra fordított maximális idő ezredmásodpercben
E két oszlop statisztikai adatainak felhalmozásával és felhasználásával fel lehet építeni egy monitoring rendszert.
A pg_stat_statements használata a PostgreSQL teljesítményének figyelésére
A lekérdezés teljesítményének figyeléséhez használja a következőket:
A céladatbázis oldalán - pg_stat_statements nézet
Oldalról szerver és monitorozó adatbázisok - bash szkriptek és szolgáltatástáblák halmaza.
1. szakasz – statisztikai adatok gyűjtése
A cron megfigyelő gazdagépen rendszeresen elindul egy parancsfájl, amely a pg_stat_statements nézet tartalmát a céladatbázisból a megfigyelési adatbázis pg_stat_history táblájába másolja.
Ez létrehozza az egyes lekérdezések végrehajtásának előzményeit, amelyek felhasználhatók teljesítményjelentések generálására és metrikák konfigurálására.
2. szakasz – teljesítménymutatók beállítása
Az összegyűjtött adatok alapján kiválasztjuk azokat a lekérdezéseket, amelyek végrehajtása a kliens (alkalmazás) számára a legkritikusabb/legfontosabb. Az ügyféllel egyetértésben a queryid és max_time mezők használatával állítjuk be a teljesítménymutatók értékeit.
Eredmény – a teljesítményfigyelés kezdete
- A megfigyelési parancsfájl futás közben ellenőrzi a konfigurált teljesítménymérőket úgy, hogy összehasonlítja a metrika max_time értékét a céladatbázis pg_stat_statements nézetének értékével.
- Ha a céladatbázisban lévő érték meghaladja a metrika értékét, figyelmeztetés generálódik (incidens a jegyrendszerben)
További lehetőség 1
Tervelőzmények lekérdezése
A teljesítménnyel kapcsolatos incidensek későbbi megoldása érdekében érdemes a lekérdezés-végrehajtási terveket korábban megváltoztatni.
A log_query szolgáltatástábla az előzmények tárolására szolgál. A táblázat a betöltött PostgreSQL naplófájl elemzésekor töltődik fel. Mivel a naplófájl a pg_stat_statements nézettől eltérően a teljes szöveget tartalmazza a végrehajtási paraméterek értékeivel, nem pedig normalizált szöveget, lehetőség van nem csak a kérések időpontjának és időtartamának naplózására, hanem az aktuális végrehajtási tervek tárolására is. idő.
További lehetőség 2
Folyamatos teljesítményjavító folyamat
Az egyes lekérdezések figyelésének általánosságban nem az a célja, hogy megoldja az adatbázis egészének teljesítményének folyamatos javítását, mivel csak az egyes lekérdezések esetén figyeli és oldja meg a teljesítményproblémákat. Azonban kiterjesztheti a módszert, és konfigurálhatja a megfigyelési lekérdezéseket az összes adatbázishoz.
Ehhez további teljesítménymutatókat kell megadnia:
- Az utolsó napokra
- A bázisidőszakra
A szkript kiválasztja a lekérdezéseket a céladatbázis pg_stat_statements nézetéből, és összehasonlítja a max_time értéket az átlagos max_time értékkel, első esetben az utolsó napokra vagy a kiválasztott időszakra (alapvonalra), a második esetben.
Így bármely kérés teljesítményromlása esetén a rendszer automatikusan figyelmeztetést generál, a jelentések manuális elemzése nélkül.
Mi köze ehhez a szintézisnek?
A leírt megközelítésben, ahogy azt a szintézis módszer is sugallja, a rendszer egyes részeinek javításával a rendszer egészét javítjuk.
- Adatbázis által végrehajtott lekérdezés – absztrakt
- Módosított kérés – antitézis
- A rendszer állapotának megváltoztatása - szintézis
Rendszerfejlesztés
- Az összegyűjtött statisztikák bővítése előzmények hozzáadásával a pg_stat_activity rendszernézethez
- Az összegyűjtött statisztikák bővítése a lekérdezésekben részt vevő egyes táblák statisztikáinak előzményeinek hozzáadásával
- Integráció az AWS felhőfigyelő rendszerrel
- És mégis kitalálhat valamit...
Forrás: will.com
