Azt javaslom, hogy olvassa el Alexey Lesovsky jelentésének átiratát a Data Egrettől „A PostgreSQL monitorozás alapjai”
Ebben a jelentésben Alekszej Leszovszkij a haladás utáni statisztikák legfontosabb pontjairól fog beszélni, mit jelentenek ezek, és miért kell jelen lenniük a monitoringban; arról, hogy milyen grafikonoknak kell szerepelniük a megfigyelésben, hogyan kell hozzáadni őket és hogyan kell értelmezni őket. A jelentés hasznos lesz az adatbázis-adminisztrátorok, rendszergazdák és fejlesztők számára, akik érdeklődnek a Postgres hibaelhárítása iránt.
A nevem Alexey Lesovsky, a Data Egret céget képviselem.
Néhány szót magamról. Nagyon régen kezdtem rendszergazdaként.
Felügyeltem mindenféle Linux rendszert, foglalkoztam a Linuxhoz kapcsolódó különféle dolgokkal, például virtualizációval, monitorozással, proxykkal stb. De valamikor elkezdtem többet foglalkozni adatbázisokkal, a PostgreSQL-lel. Nagyon megkedveltem őt. És valamikor munkaidőm nagy részét a PostgreSQL-en kezdtem dolgozni. Így fokozatosan PostgreSQL DBA lettem.
Pályafutásom során pedig mindig is érdekeltek a statisztikák, a monitorozás és a telemetria témái. És amikor rendszergazda voltam, nagyon szorosan együttműködtem a Zabbixszel. És írtam egy kis forgatókönyvet, mint pl . Nagyon népszerű volt a maga idejében. És ott nagyon különböző fontos dolgokat lehetett figyelni, nem csak a Linuxot, hanem különféle összetevőket is.
Most a PostgreSQL-en dolgozom. Már írok egy másik dolgot, ami lehetővé teszi a PostgreSQL statisztikákkal való munkát. Ez az úgynevezett (cikk Habréról - ).
Egy kis bevezető megjegyzés. Milyen helyzetekben vannak ügyfeleink, ügyfeleink? Valamilyen baleset van az adatbázissal kapcsolatban. És amikor már helyreállt az adatbázis, jön az osztályvezető vagy a fejlesztési vezető, és azt mondja: "Barátaim, figyelnünk kell az adatbázist, mert valami rossz történt, és meg kell akadályozni, hogy ez a jövőben megtörténjen." És itt kezdődik az érdekes folyamat, amikor kiválasztunk egy megfigyelőrendszert vagy egy meglévő felügyeleti rendszert adaptálunk úgy, hogy figyelemmel kísérhessük adatbázisunkat - PostgreSQL, MySQL vagy néhány más. A kollégák pedig javasolni kezdik: „Hallottam, hogy van ilyen és olyan adatbázis. Használjuk." A kollégák vitatkozni kezdenek egymással. És a végén kiderül, hogy kiválasztunk valamilyen adatbázist, de a PostgreSQL monitorozás elég gyengén jelenik meg benne, és mindig kell valamit hozzátenni. Vegyen néhány adattárat a GitHubból, klónozza őket, adaptálja a szkripteket, és valahogy testreszabja őket. És a végén valamiféle kézi munka lesz.
Ezért ebben az előadásban megpróbálok némi ismeretet adni arról, hogyan válasszuk ki a monitorozást nem csak a PostgreSQL-hez, hanem az adatbázishoz is. És megadja azt a tudást, amely lehetővé teszi a monitorozás befejezését annak érdekében, hogy némi hasznot húzzon belőle, hogy haszonnal figyelhesse adatbázisát, hogy azonnal megelőzze az esetlegesen felmerülő vészhelyzeteket.
A jelentésben szereplő ötletek pedig közvetlenül adaptálhatók bármilyen adatbázishoz, legyen az DBMS vagy noSQL. Ezért nem csak a PostgreSQL létezik, hanem sok recept lesz arra vonatkozóan, hogyan kell ezt megtenni a PostgreSQL-ben. Lesznek példák lekérdezésekre, példák entitásokra, amelyeket a PostgreSQL képes megfigyelni. És ha a DBMS-edben ugyanazok a dolgok vannak, amelyek lehetővé teszik, hogy megfigyelésbe helyezd őket, akkor adaptálhatod, hozzáadhatod és jó lesz.
Nem leszek benne a riportban
beszélni a mutatók szállításáról és tárolásáról. Az adatok utófeldolgozásáról és a felhasználónak való bemutatásáról nem mondok semmit. És nem mondok semmit a riasztásról.
De ahogy a történet előrehalad, különböző képernyőképeket fogok mutatni a meglévő monitorozásról, és valahogy kritizálni fogom őket. Ennek ellenére igyekszem nem nevezni márkákat, nehogy reklámot vagy antireklámot hozzak létre ezeknek a termékeknek. Ezért minden véletlen egybeesés, és a képzeletedre van bízva.
Először is nézzük meg, mi az a megfigyelés. A monitorozás nagyon fontos dolog. Ezt mindenki megérti. Ugyanakkor a monitorozás nem kapcsolódik üzleti termékhez, és nem befolyásolja közvetlenül a vállalat nyereségét, ezért a monitorozásra mindig maradványalapon van szánva idő. Ha van időnk, akkor figyelünk, ha nincs időnk, akkor ok, rakjuk a lemaradásba, és egyszer visszatérünk ezekhez a feladatokhoz.
Ezért gyakorlatunk szerint, amikor az ügyfelekkel foglalkozunk, a monitorozás gyakran hiányos, és nem tartalmaz olyan érdekességeket, amelyek segíthetnének abban, hogy jobban tudjunk dolgozni az adatbázissal. Ezért a monitorozást mindig be kell fejezni.
Az adatbázisok olyan összetett dolgok, amelyeket szintén figyelni kell, mert az adatbázisok információ tárháza. Az információ pedig nagyon fontos a cég számára, semmilyen módon nem vész el. Ugyanakkor az adatbázisok nagyon összetett szoftverek. Nagyszámú alkatrészből állnak. És ezen összetevők közül sokat figyelni kell.
Ha kifejezetten a PostgreSQL-ről beszélünk, akkor azt egy nagyszámú komponensből álló séma formájában ábrázolhatjuk. Ezek az összetevők kölcsönhatásba lépnek egymással. Ugyanakkor a PostgreSQL rendelkezik az úgynevezett Stats Collector alrendszerrel, amely lehetővé teszi, hogy statisztikákat gyűjtsön ezen alrendszerek működéséről, és valamilyen felületet biztosítson az adminisztrátor vagy felhasználó számára, hogy megtekinthesse ezeket a statisztikákat.
Ezek a statisztikák bizonyos függvény- és nézetkészletek formájában jelennek meg. Ezeket táblázatoknak is nevezhetjük. Vagyis egy normál psql kliens használatával csatlakozhat az adatbázishoz, kiválaszthatja ezeket a funkciókat és nézeteket, és néhány konkrét számot kaphat a PostgreSQL alrendszerek működéséről.
Ezeket a számokat hozzáadhatja kedvenc megfigyelőrendszeréhez, grafikonokat rajzolhat, függvényeket adhat hozzá, és hosszú távon elemzést kaphat.
De ebben a jelentésben nem térek ki teljesen ezekre a funkciókra, mert az egész napot igénybe vehet. Szó szerint két, három vagy négy dologgal fogok foglalkozni, és elmondom, hogyan segítik ezek a felügyelet jobbá tételét.
És ha már adatbázis-felügyeletről beszélünk, akkor mit kell figyelni? Először is figyelnünk kell a rendelkezésre állást, mert az adatbázis egy olyan szolgáltatás, amely az ügyfelek számára hozzáférést biztosít az adatokhoz, és figyelemmel kell kísérnünk a rendelkezésre állást, illetve annak minőségi és mennyiségi jellemzőit is meg kell adni.
Figyelnünk kell az adatbázisunkhoz csatlakozó klienseket is, mert lehetnek normál kliensek és káros kliensek is, amelyek károsíthatják az adatbázist. Ezeket is figyelemmel kell kísérni, tevékenységüket nyomon kell követni.
Amikor a kliensek csatlakoznak az adatbázishoz, nyilvánvaló, hogy elkezdenek dolgozni az adatainkkal, ezért figyelemmel kell kísérnünk, hogy a kliensek hogyan dolgoznak az adatokkal: milyen táblákkal, és kisebb mértékben milyen indexekkel. Azaz értékelnünk kell az ügyfeleink által létrehozott munkaterhelést.
De a munkaterhelés természetesen kérésekből is áll. Az alkalmazások csatlakoznak az adatbázishoz, lekérdezések segítségével érik el az adatokat, ezért fontos kiértékelni, hogy milyen lekérdezések vannak az adatbázisban, figyelni kell a megfelelőségüket, hogy nincsenek-e ferdén megírva, egyes opciókat át kell-e írni és úgy tenni, hogy gyorsabban működjenek és jobb teljesítménnyel.
És mivel adatbázisról beszélünk, az adatbázis mindig háttérfolyamat. A háttérfolyamatok segítenek az adatbázis-teljesítmény jó szinten tartásában, így működésükhöz bizonyos mennyiségű erőforrásra van szükségük. Ugyanakkor átfedhetik az ügyfélkérés erőforrásait, így a mohó háttérfolyamatok közvetlenül befolyásolhatják az ügyfélkérések teljesítményét. Ezért ezeket is figyelni és nyomon kell követni, hogy ne legyenek torzulások a háttérfolyamatok tekintetében.
És mindez az adatbázis-figyelés szempontjából a rendszermetrikában marad. De figyelembe véve, hogy infrastruktúránk nagy része a felhőkbe költözik, az egyes gazdagépek rendszermutatói mindig háttérbe szorulnak. De az adatbázisokban továbbra is relevánsak, és természetesen a rendszer mérőszámait is figyelni kell.
A rendszermérőkkel nagyjából minden rendben van, már minden modern felügyeleti rendszer támogatja ezeket a mérőszámokat, de általánosságban elmondható, hogy egyes összetevők még mindig nem elegendőek, és néhány dolgot hozzá kell adni. Kitérek rájuk is, több dia is lesz róluk.
A terv első pontja az akadálymentesítés. Mi az akadálymentesítés? Az elérhetőség értelmezésemben a bázis kapcsolat kiszolgálási képessége, azaz a bázis felemelkedik, szolgáltatásként fogadja el a kapcsolatokat az ügyfelektől. Ez az elérhetőség pedig bizonyos jellemzők alapján értékelhető. Nagyon kényelmes ezeket a jellemzőket a műszerfalakon megjeleníteni.
Mindenki tudja, mi az a műszerfal. Ekkor vetett egy pillantást a képernyőre, amelyen összefoglalja a szükséges információkat. És azonnal megállapíthatja, hogy van-e probléma az adatbázisban vagy sem.
Ennek megfelelően az adatbázis elérhetőségét és más kulcsfontosságú jellemzőket mindig meg kell jeleníteni a műszerfalakon, hogy ezek az információk mindig kéznél legyenek és mindig elérhetőek legyenek az Ön számára. Néhány további részlet, amelyek már segítik az incidensek kivizsgálását, egyes vészhelyzetek kivizsgálásakor ezeket már el kell helyezni a másodlagos műszerfalakra, vagy el kell rejteni azokat a részletes hivatkozásokat, amelyek harmadik féltől származó megfigyelőrendszerekhez vezetnek.
Példa egy jól ismert megfigyelő rendszerre. Ez egy nagyon klassz megfigyelő rendszer. Rengeteg adatot gyűjt, de az én szemszögemből furcsa fogalma van az irányítópultokról. Van egy link az „irányítópult létrehozásához”. De amikor létrehoz egy irányítópultot, akkor létrehoz egy listát két oszlopból, egy grafikonlistát. És ha meg kell nézni valamit, akkor elkezd kattintani az egérrel, görgetni, keresni a kívánt diagramot. Ez pedig időt vesz igénybe, azaz nincsenek műszerfalak, mint olyanok. Csak diagramlisták vannak.
Mit kell hozzáadni ezekhez az irányítópultokhoz? Kezdheti egy olyan jellemzővel, mint a válaszidő. A PostgreSQL-nek a pg_stat_statements nézete van. Alapértelmezés szerint le van tiltva, de ez az egyik fontos rendszernézet, amelyet mindig engedélyezni és használni kell. Információkat tárol az adatbázisban végrehajtott összes futó lekérdezésről.
Ennek megfelelően abból indulhatunk ki, hogy az összes kérés teljes végrehajtási idejét vehetjük, és a fenti mezők segítségével eloszthatjuk a kérések számával. De ez az átlagos hőmérséklet a kórházban. Kiindulhatunk más mezőkből is - minimális lekérdezés végrehajtási idő, maximum és medián. És még percentiliseket is építhetünk, a PostgreSQL rendelkezik ehhez megfelelő függvényekkel. És kaphatunk néhány olyan számot, amelyek a már teljesített kérésekre jellemzik adatbázisunk válaszidejét, azaz nem a 'select 1'-es hamis kérést hajtjuk végre és a válaszidőt nézzük, hanem a már teljesített kérések válaszidejét elemezzük és sorsolunk. vagy külön ábra, vagy ez alapján építünk grafikont.
Szintén fontos figyelemmel kísérni a rendszer által jelenleg generált hibák számát. És ehhez használhatja a pg_stat_database nézetet. Az xact_rollback mezőre összpontosítunk. Ez a mező nem csak az adatbázisban előforduló visszagörgetések számát mutatja, hanem figyelembe veszi a hibák számát is. Viszonylagosan meg tudjuk jeleníteni ezt az ábrát a műszerfalunkon, és megnézhetjük, hány hibánk van jelenleg. Ha sok a hiba, akkor ez jó ok arra, hogy megvizsgálja a naplókat, és megnézze, milyen hibákról van szó, és miért fordulnak elő, majd befektetni és megoldani őket.
Hozzáadhat olyan dolgot, mint a fordulatszámmérő. Ezek a tranzakciók száma másodpercenként és a kérések száma másodpercenként. Viszonylagosan ezeket a számokat használhatja az adatbázis aktuális teljesítményeként, és megfigyelheti, hogy vannak-e csúcsok a kérésekben, csúcsok a tranzakciókban, vagy fordítva, hogy az adatbázis nincs-e alulterhelve, mert valamelyik háttérrendszer meghibásodott. Fontos, hogy mindig ezt az ábrát nézzük, és ne feledjük, hogy a projektünk esetében ez a fajta teljesítmény normális, de a fenti és alatti értékek már valamilyen problémás és érthetetlen, ami azt jelenti, hogy meg kell vizsgálnunk, hogy miért olyan magas.
A tranzakciók számának becsléséhez ismét hivatkozhatunk a pg_stat_database nézetre. Összeadhatjuk a véglegesítések és a visszagörgetések számát, és megkaphatjuk a másodpercenkénti tranzakciók számát.
Mindenki megérti, hogy egy tranzakcióba több kérés is belefér? Ezért a TPS és a QPS kissé különbözik.
A másodpercenkénti kérések száma a pg_stat_statements fájlból leolvasható, és egyszerűen kiszámíthatja az összes teljesített kérés összegét. Jól látható, hogy az aktuális értéket összehasonlítjuk az előzővel, kivonjuk, megkapjuk a deltát, és megkapjuk a mennyiséget.
Igény szerint további mérőszámokat is hozzáadhat, amelyek szintén segítenek az adatbázisunk elérhetőségének értékelésében, és nyomon követni, hogy történt-e leállás.
Az egyik ilyen mutató az üzemidő. De az üzemidő a PostgreSQL-ben kissé bonyolult. Megmondom miért. Amikor a PostgreSQL elindult, az üzemidő megkezdi a jelentéskészítést. De ha egy ponton például egy feladat futott éjszaka, jött egy OOM-killer, és erőszakkal leállította a PostgreSQL gyermekfolyamatát, akkor ebben az esetben a PostgreSQL megszakítja az összes kliens kapcsolatát, alaphelyzetbe állítja a szilánkos memóriaterületet és megkezdi a helyreállítást az utolsó ellenőrzőpont. És amíg ez az ellenőrzőpontból való kilábalás tart, az adatbázis nem fogad el kapcsolatokat, vagyis ez a helyzet leállásként értékelhető. De az üzemidő számláló nem nullázódik, mert az első pillanattól kezdve figyelembe veszi a postmaster indítási idejét. Ezért az ilyen helyzetek kihagyhatók.
Figyelnie kell a vákuummunkások számát is. Mindenki tudja, hogy mi az autovacuum a PostgreSQL-ben? Ez egy érdekes alrendszer a PostgreSQL-ben. Sok cikk született róla, sok riport készült. Sok vita folyik a vákuumról és annak működéséről. Sokan szükséges rossznak tartják. De hát ez így van. Ez a szemétgyűjtő egyfajta analógja, amely megtisztítja a sorok elavult verzióit, amelyekre semmilyen tranzakcióhoz nincs szükség, és helyet szabadít fel a táblákban és az indexekben az új sorok számára.
Miért kell figyelni? Mert a vákuum néha nagyon fáj. Ez nagy mennyiségű erőforrást emészt fel, és ennek következtében az ügyfelek kérései kezdenek szenvedni.
És figyelni kell a pg_stat_activity nézeten keresztül, amelyről a következő részben fogok beszélni. Ez a nézet az adatbázis aktuális tevékenységét mutatja. Ezen a tevékenységen keresztül pedig nyomon tudjuk követni a jelenleg működő porszívók számát. Nyomon követhetjük a vákuumokat, és láthatjuk, hogy ha túlléptük a határértéket, akkor ez ok arra, hogy belenézzünk a PostgreSQL beállításaiba, és valahogy optimalizáljuk a vákuum működését.
Egy másik dolog a PostgreSQL-lel kapcsolatban, hogy a PostgreSQL nagyon beteg a hosszú tranzakcióktól. Főleg olyan tranzakciókból, amelyek sokáig lógnak és nem csinálnak semmit. Ez az úgynevezett stat idle-in-transaction. Egy ilyen tranzakció zárakat tart, és megakadályozza a vákuum működését. Ennek eredményeként az asztalok megduzzadnak és megnövekednek. És az ezekkel a táblákkal működő lekérdezések lassabban működnek, mert a sorok összes régi verzióját át kell lapátolni a memóriából a lemezre és vissza. Ezért a leghosszabb tranzakciók, a leghosszabb vákuumkérések idejét, időtartamát is figyelni kell. És ha látunk néhány nagyon régóta futó folyamatot, már több mint 10-20-30 percet egy OLTP terhelésnél, akkor figyelni kell rájuk és erőszakosan le kell állítani, vagy optimalizálni az alkalmazást, hogy nem hívják, és ne lógjanak olyan sokáig. Analitikai terhelésnél 10-20-30 perc a normális, vannak hosszabbak is.
Ezután lehetőségünk van a csatlakoztatott ügyfelekkel. Ha már létrehoztunk egy irányítópultot, és közzétettük rajta a legfontosabb elérhetőségi mutatókat, ott további információkat is hozzáadhatunk a csatlakoztatott ügyfelekről.
A csatlakoztatott kliensekkel kapcsolatos információk azért fontosak, mert a PostgreSQL szemszögéből nézve az ügyfelek különbözőek. Vannak jó ügyfelek és vannak rossz ügyfelek.
Egy egyszerű példa. Ügyfél által értem az alkalmazást. Az alkalmazás csatlakozott az adatbázishoz és azonnal elkezdi oda küldeni kéréseit, az adatbázis feldolgozza és végrehajtja azokat, az eredményeket pedig visszaküldi a kliensnek. Ezek jó és korrekt ügyfelek.
Vannak helyzetek, amikor az ügyfél csatlakozott, tartja a kapcsolatot, de nem csinál semmit. Tétlen állapotban van.
De vannak rossz ügyfelek. Például ugyanaz a kliens csatlakozott, megnyitott egy tranzakciót, csinált valamit az adatbázisban, majd bement a kódba, például, hogy hozzáférjen egy külső forráshoz vagy feldolgozza az ott kapott adatokat. De nem zárta le a tranzakciót. És a tranzakció lefagy az adatbázisban, és egy zárban van a vonalon. Ez egy rossz állapot. És ha hirtelen egy alkalmazás valahol egy kivétellel meghibásodik, akkor a tranzakció nagyon hosszú ideig nyitva maradhat. Ez pedig közvetlenül befolyásolja a PostgreSQL teljesítményét. A PostgreSQL lassabb lesz. Ezért fontos az ilyen ügyfelek időben történő nyomon követése és munkájuk erőszakos megszüntetése. És optimalizálnia kell az alkalmazást, hogy ilyen helyzetek ne forduljanak elő.
Más rossz ügyfelek várakozó ügyfelek. De a körülmények miatt rosszakká válnak. Például egy egyszerű tétlen tranzakció: meg tud nyitni egy tranzakciót, néhány soron zárolást vehet fel, majd valahol a kódban meghiúsul, függő tranzakciót hagyva hátra. Egy másik kliens jön, és ugyanazokat az adatokat kéri, de ő zárolásba ütközik, mert az a függő tranzakció már zárolást tartalmaz néhány kötelező soron. A második tranzakció pedig várakozik, amíg az első tranzakció befejeződik, vagy a rendszergazda erőszakkal lezárja. Ezért a függőben lévő tranzakciók felhalmozódhatnak, és kitölthetik az adatbázis-kapcsolati korlátot. Ha pedig betelt a limit, az alkalmazás már nem tud együttműködni az adatbázissal. Ez már vészhelyzet a projekt számára. Ezért a rossz ügyfeleket nyomon kell követni, és időben reagálni kell rájuk.
Egy másik példa a megfigyelésre. És itt már van egy tisztességes műszerfal. A csatlakozásokról fent van információ. DB csatlakozás – 8 db. És ez minden. Arról nincs információnk, hogy mely kliensek aktívak, mely kliensek csak tétlenek, semmit sem csinálnak. A függőben lévő tranzakciókról és a függőben lévő kapcsolatokról nincs információ, vagyis ez egy ábra, amely a kapcsolatok számát mutatja, és ennyi. Aztán találd ki magad.
Ennek megfelelően ahhoz, hogy ezeket az információkat a megfigyeléshez hozzáadhassa, el kell érnie a pg_stat_activity rendszernézetet. Ha sok időt töltesz a PostgreSQL-ben, akkor ez egy nagyon jó nézet, amely a barátod lehet, mert megmutatja a PostgreSQL aktuális tevékenységét, vagyis azt, hogy mi történik benne. Minden folyamathoz külön sor tartozik, amely a folyamattal kapcsolatos információkat mutatja: melyik gépről jött létre a kapcsolat, milyen felhasználóval, milyen néven, mikor indult a tranzakció, milyen kérés fut éppen, milyen kérést hajtottak végre utoljára. Ennek megfelelően a stat mező segítségével értékelhetjük az ügyfél állapotát. Relatív értelemben csoportosíthatunk e mező szerint, és megkaphatjuk azokat a statisztikákat, amelyek jelenleg az adatbázisban vannak, és azoknak a kapcsolatoknak a számát, amelyeknél ez a statisztika szerepel az adatbázisban. A már beérkezett számokat pedig elküldhetjük a monitorozásunknak, és ezek alapján grafikonokat rajzolhatunk.
Fontos a tranzakció időtartamának értékelése is. Már mondtam, hogy fontos a vákuum időtartamának értékelése, de a tranzakciókat ugyanúgy értékelik. Vannak xact_start és query_start mezők. Viszonylagosan a tranzakció kezdési időpontját és a kérés kezdő időpontját mutatják. Vegyük a now() függvényt, amely az aktuális időbélyeget mutatja, és kivonjuk a tranzakció és a kérés időbélyegét. És megkapjuk a tranzakció időtartamát, a kérés időtartamát.
Ha hosszú tranzakciókat látunk, azokat már végre kell hajtanunk. OLTP-terhelés esetén a hosszú tranzakciók már 1-2-3 percnél is hosszabbak. OLAP-munkaterhelés esetén a hosszú tranzakciók normálisak, de ha ezek végrehajtása több mint két órát vesz igénybe, akkor ez is annak a jele, hogy valahol ferdeség van.
Miután az ügyfelek csatlakoztak az adatbázishoz, elkezdenek dolgozni az adatainkkal. Hozzáférnek a táblákhoz, hozzáférnek az indexekhez, hogy adatokat kapjanak a táblából. És fontos annak értékelése, hogy az ügyfelek hogyan lépnek kapcsolatba ezekkel az adatokkal.
Erre azért van szükség, hogy értékeljük leterheltségünket, és hozzávetőlegesen megértsük, mely táblázatok a „legforróbbak” számunkra. Erre például olyan helyzetekben van szükség, amikor „forró” asztalokat szeretnénk elhelyezni valamilyen gyors SSD tárolón. Például néhány régen nem használt archív táblát át lehet helyezni valamilyen „hideg” archívumba, SATA meghajtókra és ott hagyni őket, szükség szerint hozzáférnek.
Ez az anomáliák észleléséhez is hasznos bármely kiadás és telepítés után. Tegyük fel, hogy a projekt kiadott néhány új funkciót. Például új funkciókat adtunk hozzá az adatbázis kezeléséhez. Ha pedig táblázathasználati grafikonokat ábrázolunk, akkor ezeken a grafikonokon könnyen észlelhetjük ezeket az anomáliákat. Például frissítheti a sorozatokat vagy törölheti a sorozatokat. Nagyon látható lesz.
A „lebegő” statisztikákban is észlelhet anomáliákat. Mit jelent? A PostgreSQL nagyon erős és nagyon jó lekérdezéstervezővel rendelkezik. A fejlesztők pedig sok időt fordítanak a fejlesztésére. Hogyan működik? A jó tervek elkészítése érdekében a PostgreSQL statisztikát gyűjt az adatok táblázatokban való eloszlásáról egy bizonyos időintervallumban és bizonyos gyakorisággal. Ezek a leggyakoribb értékek: az egyedi értékek száma, a NULL-ra vonatkozó információ a táblázatban, sok információ.
Ezen statisztikák alapján a tervező több lekérdezést készít, kiválasztja a legoptimálisabbat, és ezt a lekérdezési tervet használja magának a lekérdezésnek a végrehajtásához és az adatok visszaadásához.
És előfordul, hogy a statisztikák „lebegnek”. A minőségi és mennyiségi adatok valahogy változtak a táblázatban, de a statisztikákat nem gyűjtötték össze. A kialakított tervek pedig nem biztos, hogy optimálisak. Ha pedig az összegyűjtött monitorozás alapján, a táblázatok alapján a terveink szuboptimálisnak bizonyulnak, láthatjuk majd ezeket az anomáliákat. Például valahol minőségileg megváltoztak az adatok, és az index helyett egy szekvenciális áthaladást kezdtek el használni a táblázaton, pl. ha egy lekérdezésnek csak 100 sort kell visszaadnia (a korlát 100), akkor a rendszer teljes keresést hajt végre erre a lekérdezésre. Ez pedig mindig nagyon rossz hatással van a teljesítményre.
És ezt láthatjuk a monitorozásban. És már nézze meg ezt a lekérdezést, futtasson hozzá magyarázatot, gyűjtsön statisztikákat, építsen fel egy új kiegészítő indexet. És már válaszol is erre a problémára. Ezért fontos.
Egy másik példa a megfigyelésre. Szerintem sokan felismerték, mert nagyon népszerű. Kik használják projektjeikben ? Ki használja ezt a terméket a Prometheusszal együtt? A helyzet az, hogy ennek a megfigyelésnek a szabványos tárolójában van egy irányítópult a PostgreSQL-lel való együttműködéshez - Prométheusz. De van egy rossz részlet.
Számos grafikon létezik. A bájtokat pedig egységként jelöljük, azaz 5 grafikon van. Ezek a következők: Adatok beszúrása, Adatok frissítése, Adatok törlése, Adatok lekérése és Adatok visszaküldése. A mértékegység mértéke bájt. De a helyzet az, hogy a PostgreSQL statisztikája sorokban (sorokban) adja vissza az adatokat. És ennek megfelelően ezek a grafikonok nagyon jó módja annak, hogy többször, tízszer alábecsüljük a terhelést, mert a sor nem bájt, hanem egy string, sok bájtból áll, és mindig változó hosszúságú. Vagyis a terhelés bájtokban történő kiszámítása sorok segítségével irreális feladat vagy nagyon nehéz. Ezért amikor műszerfalat vagy beépített megfigyelést használ, mindig fontos megérteni, hogy az megfelelően működik, és helyesen értékelt adatokat ad vissza.
Hogyan lehet statisztikákat készíteni ezekről a táblázatokról? Erre a célra a PostgreSQL rendelkezik egy bizonyos nézetcsaláddal. És a fő nézet az . User_tables – ez a felhasználó nevében létrehozott táblákat jelenti. Ezzel szemben vannak olyan rendszernézetek, amelyeket maga a PostgreSQL használ. És van egy összefoglaló táblázat Alltables, amely tartalmazza a rendszer és a felhasználói adatokat is. Bármelyikből kiindulhat, amelyik a legjobban tetszik.
A fenti mezők segítségével megbecsülheti a beszúrások, frissítések és törlések számát. Az általam használt irányítópult példája ezeket a mezőket használja a munkaterhelés jellemzőinek értékelésére. Ezért mi is építhetünk rájuk. De érdemes megjegyezni, hogy ezek sorok, nem bájtok, tehát nem tehetjük meg csak bájtokban.
Ezen adatok alapján építhetünk úgynevezett TopN táblákat. Például Top-5, Top-10. És nyomon követheti azokat a forró asztalokat, amelyeket jobban újrahasznosítanak, mint mások. Például 5 „forró” táblázat a beszúráshoz. Ezeknek a TopN-tábláknak a segítségével kiértékeljük a munkaterhelésünket, és ki tudjuk értékelni a terhelési sorozatokat minden kiadás, frissítés és üzembe helyezés után.
A táblázat méretének értékelése is fontos, mert a fejlesztők néha új funkciót vezetnek be, és a táblázataink kezdenek megduzzadni nagy méretükben, mivel úgy döntöttek, hogy további adatmennyiséget adnak hozzá, de nem jósolták meg, hogy ez hogyan fog történni. befolyásolja az adatbázis méretét. Az ilyen esetek számunkra is meglepetések.
És most egy kis kérdés hozzád. Milyen kérdés merül fel, ha az adatbázis-kiszolgáló terhelését észleli? Mi a következő kérdésed?
De valójában a kérdés a következőképpen vetődik fel. Milyen kéréseket okoz a terhelés? Vagyis nem érdekes nézegetni azokat a folyamatokat, amiket a terhelés okoz. Nyilvánvaló, hogy ha a gazdagépnek van adatbázisa, akkor ott fut az adatbázis, és egyértelmű, hogy ott csak az adatbázisok kerülnek selejtezésre. Ha megnyitjuk a Topot, látni fogjuk azon folyamatok listáját a PostgreSQL-ben, amelyek csinálnak valamit. A Topból nem derül ki, hogy mit csinálnak.
Ennek megfelelően meg kell találni azokat a lekérdezéseket, amelyek a legnagyobb terhelést okozzák, mert a tuning lekérdezések általában több profitot adnak, mint a PostgreSQL vagy az operációs rendszer konfigurációjának, vagy akár a hardver hangolása. Becslésem szerint ez körülbelül 80-85-90%. És ez sokkal gyorsabban megtörténik. Gyorsabb egy kérés javítása, mint a konfiguráció javítása, az újraindítás ütemezése, különösen, ha az adatbázis nem indítható újra, vagy a hardver hozzáadása. Könnyebb valahol átírni a lekérdezést, vagy indexet hozzáadni, hogy jobb eredményt érjen el ebből a lekérdezésből.
Ennek megfelelően figyelemmel kell kísérni a kérelmeket és azok megfelelőségét. Vegyünk egy másik példát a megfigyelésre. És úgy tűnik, itt is kiváló a megfigyelés. Van információ a replikációról, van információ az áteresztőképességről, a blokkolásról, az erőforrás-kihasználásról. Minden rendben van, de a kérésekről nincs információ. Nem világos, hogy milyen lekérdezések futnak az adatbázisunkban, mennyi ideig futnak, hány ilyen lekérdezés van. Mindig szükségünk van erre az információra a megfigyelésünk során.
Ezen információk megszerzéséhez használhatjuk a pg_stat_statements modult. Ez alapján sokféle grafikont készíthet. Például információkat kaphat a leggyakoribb lekérdezésekről, vagyis azokról a lekérdezésekről, amelyeket leggyakrabban hajtanak végre. Igen, a telepítések után is nagyon hasznos megnézni, és megérteni, ha megugrott a kérések száma.
Figyelemmel kísérheti a leghosszabb lekérdezéseket, vagyis azokat, amelyek teljesítése a leghosszabb ideig tart. A processzoron futnak, I/O-t fogyasztanak. Ezt a total_time, mean_time, blk_write_time és blk_read_time mezők használatával is kiértékelhetjük.
Az erőforrás-felhasználás szempontjából a legsúlyosabb kéréseket, a lemezről olvasókat, a memóriával működőket, vagy éppen ellenkezőleg, írási terhelést hozunk létre, ki tudjuk értékelni és figyelni.
A legbőkezűbb kéréseket el tudjuk értékelni. Ezek azok a lekérdezések, amelyek nagy számú sort adnak vissza. Ez lehet például egy olyan kérés, ahol elfelejtettek korlátot beállítani. És egyszerűen visszaadja a tábla vagy lekérdezés teljes tartalmát a lekérdezett táblákon keresztül.
Emellett figyelheti az ideiglenes fájlokat vagy ideiglenes táblákat használó lekérdezéseket is.
És még mindig vannak háttérfolyamataink. A háttérfolyamatok elsősorban ellenőrzőpontok, vagy ellenőrzőpontoknak is nevezik őket, ezek az autovákuum és a replikáció.
Egy másik példa a megfigyelésre. Van egy Karbantartás lap a bal oldalon, lépjen rá, és remélem, hogy talál valami hasznosat. De itt csak a vákuumos működés és a statisztikai adatok gyűjtésének ideje van, semmi több. Ez nagyon szegényes információ, ezért mindig szükségünk van arra, hogy az adatbázisunkban információval rendelkezzünk arról, hogyan működnek a háttérfolyamatok, és van-e probléma a munkájukból.
Amikor az ellenőrzőpontokat nézzük, emlékeznünk kell arra, hogy az ellenőrzőpontok a piszkos oldalakat a szilánkos memóriaterületről a lemezre öblítik, majd ellenőrzőpontot hoznak létre. És ez az ellenőrzőpont használható helyreállítási helyként, ha a PostgreSQL hirtelen leállt vészhelyzetben.
Ennek megfelelően annak érdekében, hogy az összes „piszkos” oldalt a lemezre öblítse, bizonyos mennyiségű írást kell végeznie. És általában a nagy mennyiségű memóriával rendelkező rendszereken ez sok. És ha nagyon gyakran végezzük az ellenőrzőpontokat rövid időközönként, akkor a lemez teljesítménye jelentősen csökken. Az ügyfelek kérései pedig forráshiányban szenvednek. Versenyezni fognak az erőforrásokért, és hiányzik a termelékenység.
Ennek megfelelően a pg_stat_bgwriter segítségével a megadott mezőket használva nyomon követhetjük az előforduló ellenőrzőpontok számát. És ha sok ellenőrzőpontunk van egy bizonyos idő alatt (10-15-20 perc alatt, fél óra alatt), például 3-4-5, akkor ez már gondot jelenthet. És már meg kell nézni az adatbázisban, a konfigurációban, hogy mi okozza az ellenőrzőpontok ilyen bőségét. Talán valami nagy felvétel készül. A terhelést már tudjuk értékelni, mert már felvettük a terhelési grafikonokat. Már módosíthatjuk az ellenőrzőpont paramétereit, és megbizonyosodhatunk arról, hogy ne befolyásolják nagymértékben a lekérdezés teljesítményét.
Ismét visszatérek az autovákuumhoz, mert ez egy olyan dolog, mint mondtam, amely könnyen összeadja mind a lemez, mind a lekérdezési teljesítményt, ezért mindig fontos megbecsülni az autovákuum mennyiségét.
Az adatbázisban szereplő autovákuumos dolgozók száma korlátozott. Alapértelmezés szerint három van belőlük, tehát ha mindig három dolgozónk dolgozik az adatbázisban, ez azt jelenti, hogy az autovákuumunk nincs beállítva, emelni kell a limiteket, felül kell vizsgálni az autovákuum beállításait és bele kell menni a konfigurációba.
Fontos felmérni, hogy milyen vákuummunkásaink vannak. Vagy a felhasználó indította el, jött a DBA, és manuálisan elindított valami vákuumot, és ez terhelést hozott létre. Van valami problémánk. Vagy ennyi a porszívók száma, amelyek lecsavarják a tranzakciószámlálót. A PostgreSQL egyes verzióinál ezek nagyon nagy vákuumok. És könnyen összeadhatják a teljesítményt, mert elolvassák a teljes táblázatot, átvizsgálják a táblázat összes blokkját.
És természetesen a porszívózás időtartama. Ha vannak tartós porszívóink, amelyek nagyon sokáig működnek, akkor ez azt jelenti, hogy ismét oda kell figyelnünk a vákuum konfigurációjára, és esetleg át kell gondolnunk a beállításait. Ugyanis előfordulhat olyan helyzet, amikor a vákuum sokáig (3-4 óráig) működik az asztalon, de a vákuum működése alatt ismét nagy mennyiségű holt sor sikerült felhalmozódni a táblázatban. És amint a vákuum elkészült, újra fel kell porszívóznia ezt az asztalt. És elérkeztünk egy helyzethez – egy végtelen vákuumhoz. És ebben az esetben a vákuum nem tud megbirkózni a munkájával, és a táblázatok mérete fokozatosan megduzzad, bár a hasznos adatok mennyisége változatlan marad. Ezért a hosszú vákuum során mindig megnézzük a konfigurációt és igyekszünk optimalizálni, ugyanakkor úgy, hogy a kliens kérések teljesítése ne szenvedjen csorbát.
Manapság gyakorlatilag nincs olyan PostgreSQL-telepítés, amely ne rendelkezik streaming replikációval. A replikáció az a folyamat, amely során adatokat helyezünk át a mesterről a replikára.
A PostgreSQL replikációja tranzakciós naplón keresztül történik. A varázsló létrehoz egy tranzakciós naplót. A tranzakciós napló a hálózati kapcsolaton keresztül eljut a replikához, majd reprodukálódik a replikán. Ez egyszerű.
Ennek megfelelően a pg_stat_replication nézet a replikációs késés figyelésére szolgál. De nem minden egyszerű vele. A 10-es verzióban a nézet több változáson ment keresztül. Először is, néhány mezőt átneveztek. És néhány mező hozzáadásra került. A 10-es verzióban olyan mezők jelentek meg, amelyek lehetővé teszik a replikációs késés másodpercek alatti becslését. Nagyon kényelmes. A 10-es verzió előtt meg lehetett becsülni a replikációs késést bájtokban. Ez az opció a 10-es verzióban marad, azaz kiválaszthatja, hogy mi a kényelmesebb az Ön számára - becsülje meg a késést bájtokban vagy becsülje meg a késést másodpercben. Sokan csinálják mindkettőt.
Ennek ellenére a replikációs késleltetés értékeléséhez ismernie kell a napló pozícióját a tranzakcióban. És ezek a tranzakciónapló-pozíciók pontosan a pg_stat_replication nézetben vannak. Viszonylagosan két pontot vehetünk fel a tranzakciós naplóban a pg_xlog_location_diff() függvény használatával. Számítsa ki a köztük lévő deltát, és kapja meg a replikációs késést bájtokban. Nagyon kényelmes és egyszerű.
A 10-es verzióban ennek a függvénynek a neve pg_wal_lsn_diff(). Általában minden olyan függvényben, nézetben és segédprogramban, ahol az „xlog” szó megtalálható, a „wal” értékre cserélték. Ez vonatkozik a nézetekre és a funkciókra is. Ez egy ilyen újítás.
Ráadásul a 10-es verzióban olyan sorokat adtak hozzá, amelyek kifejezetten a késést mutatják. Ezek a következők: írási késleltetés, flush lag, replay lag. Vagyis fontos figyelni ezeket a dolgokat. Ha azt látjuk, hogy replikációs késleltetésünk van, akkor meg kell vizsgálnunk, miért jelent meg, honnan jött, és meg kell javítanunk a problémát.
A rendszermutatókkal szinte minden rendben van. Amikor a megfigyelés elkezdődik, a rendszermérőkkel kezdődik. Ez a processzorok, a memória, a csere, a hálózat és a lemez selejtezése. Sok paraméter azonban alapértelmezés szerint nincs ott.
Ha minden rendben van az újrahasznosítási folyamattal, akkor problémák vannak a lemez újrahasznosításával. A megfigyelő fejlesztők általában információkat adnak hozzá az átviteli sebességről. Ez lehet iops-ban vagy bájtban. De elfelejtik a késleltetést és a lemezeszközök kihasználását. Ezek sokkal fontosabb paraméterek, amelyek segítségével kiértékelhetjük, hogy lemezeink mennyire terheltek és milyen lassúak. Ha magas a késleltetésünk, akkor ez azt jelenti, hogy problémák vannak a lemezekkel. Ha magas a kihasználtságunk, az azt jelenti, hogy a lemezek nem bírnak. Ezek jobb jellemzők, mint a teljesítmény.
Sőt, ezek a statisztikák a /proc fájlrendszerből is beszerezhetők, ahogy az újrahasznosítási processzorok esetében is történik. Nem tudom, hogy ezt az információt miért nem adják hozzá a megfigyeléshez. Ennek ellenére fontos, hogy ez szerepeljen a megfigyelésben.
Ugyanez vonatkozik a hálózati interfészekre is. A hálózati átviteli sebességről csomagokban, bájtokban van információ, de ennek ellenére nincs információ a késleltetésről és a kihasználtságról, pedig ez is hasznos információ.
Minden ellenőrzésnek vannak hátrányai. És függetlenül attól, hogy milyen ellenőrzést végez, az mindig nem fog megfelelni bizonyos kritériumoknak. Ennek ellenére fejlődnek, új funkciók és új dolgok kerülnek hozzáadásra, ezért válasszon valamit, és fejezze be.
És a befejezéshez mindig rendelkeznie kell arról, hogy mit jelentenek a szolgáltatott statisztikák, és hogyan használhatja őket problémák megoldására.
És néhány kulcsfontosságú pont:
- Mindig figyelnie kell a rendelkezésre állást, és rendelkeznie kell irányítópultokkal, így gyorsan felmérheti, hogy minden rendben van-e az adatbázissal.
- Mindig tudnia kell, hogy milyen ügyfelek dolgoznak az adatbázisával, hogy kiszűrje és lelője a rossz ügyfeleket.
- Fontos értékelni, hogy ezek az ügyfelek hogyan dolgoznak az adatokkal. Kell, hogy legyen elképzelése a munkaterheléséről.
- Fontos értékelni, hogy ez a terhelés hogyan alakul ki, milyen lekérdezések segítségével. Kiértékelheti a lekérdezéseket, optimalizálhatja őket, szerkesztheti őket, indexeket készíthet hozzájuk. Ez nagyon fontos.
- A háttérfolyamatok negatívan befolyásolhatják az ügyfelek kéréseit, ezért fontos figyelemmel kísérni, hogy nem használnak-e túl sok erőforrást.
- A rendszermetrikák lehetővé teszik, hogy terveket készítsen a szerverek méretezésére és kapacitásának növelésére, ezért fontos ezek nyomon követése és értékelése is.
Ha érdekli ez a téma, akkor kövesse ezeket a linkeket.
- ez a statisztikai gyűjtő hivatalos dokumentációja. Az összes statisztikai nézet leírása és az összes mező leírása található. Elolvashatja, megértheti és elemzi őket. Ezek alapján készítse el grafikonjait, és adja hozzá őket a megfigyeléshez.
Példák kérésre:
Ez a mi vállalati adattárunk és az enyém. Példalekérdezéseket tartalmaznak. Ott nincsenek lekérdezések a select* from sorozatból. Léteznek már kész lekérdezések összekapcsolással, érdekes függvényekkel, amelyek lehetővé teszik, hogy a nyers számokat olvasható, kényelmes értékké alakítsuk, azaz ezek bájtok, idő. Felveheti, megnézheti, elemezheti, hozzáadhatja a monitorozáshoz, ezek alapján építheti fel a monitorozását.
kérdések
Kérdés: Azt mondtad, hogy nem fogsz márkákat hirdetni, de továbbra is kíváncsi vagyok - milyen műszerfalakat használ a projektjei során?
Válasz: Változó. Előfordul, hogy egy ügyfélhez érkezünk, és már megvan a saját monitorozása. És tanácsot adunk az ügyfeleknek, hogy mit kell hozzátenni a megfigyeléshez. A legrosszabb a helyzet Zabbixszel. Mert nem képes TopN grafikonokat építeni. Mi magunk használjuk , mert konzultáltunk ezekkel a srácokkal a megfigyelésről. Technikai specifikációink alapján figyelték a PostgreSQL-t. Saját kisállat-projektemet írom, amely a Prometheuson keresztül gyűjt adatokat és megjeleníti azokat . Az a feladatom, hogy létrehozzam a saját exportőrömet a Prometheusban, majd mindent rendereljek a Grafanában.
Kérdés: Vannak-e analógjai az AWR jelentéseknek vagy... összesítésnek? Tudsz valami ilyesmiről?
Válasz: Igen, tudom, mi az AWR, klassz dolog. Jelenleg számos kerékpár létezik, amelyek megközelítőleg a következő modellt valósítják meg. Bizonyos időközönként egyes alapvonalak ugyanabba a PostgreSQL-be vagy egy külön tárolóba íródnak. Az interneten rákereshetsz a google-ra, ott vannak. Az egyik ilyen dolog fejlesztője az sql.ru fórumon ül a PostgreSQL szálban. Ott elkaphatod. Igen, vannak ilyenek, használhatók. Plusz benne Írok egy olyan dolgot is, amely lehetővé teszi, hogy ugyanazt tedd.
PS1 Ha postgres_exportert használsz, milyen irányítópultot használsz? Több is van belőlük. Már elavultak. Lehet, hogy a közösség létrehoz egy frissített sablont?
A PS2 eltávolítva a pganalyze-t, mert ez egy szabadalmaztatott SaaS-ajánlat, amely a teljesítményfigyelésre és az automatikus hangolási javaslatokra összpontosít.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Melyik saját hosztolt postgresql monitorozást (műszerfallal) tartja a legjobbnak?
-
30,0%Zabbix + kiegészítések Alexey Lesovsky-tól vagy zabbix 4.4 vagy libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%A pganalyze egy védett SaaS – nem tudom törölni1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 felhasználó szavazott. 26 felhasználó tartózkodott.
Forrás: will.com