{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"A PostgreSQL monitoroz\u00e1s alapjai. Alexej Leszovszkij","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Javaslom, hogy ismerje meg Alexey Lesovsky jelent\u00e9s\u00e9nek \u00f6sszefoglal\u00f3j\u00e1t a Data Egret-t\u0151l \"PostgreSQL monitoring alapjai\"<\/strong><\/p>\n

<\/p>\n

A jelent\u00e9sben Alexey Lesovsky bemutatja a PostgreSQL statisztik\u00e1k kulcsfontoss\u00e1g\u00fa elemeit, annak jelent\u00e9s\u00e9t \u00e9s azt, hogy mi\u00e9rt kell ezeknek szerepelni\u00fck a monitoringban; eml\u00edteni fogja, hogy milyen grafikonoknak kell szerepelni\u00fck a figyel\u00e9s sor\u00e1n, hogyan lehet hozz\u00e1adni \u0151ket \u00e9s hogyan kell \u00e9rtelmezni \u0151ket. A jelent\u00e9s hasznos lesz az adatb\u00e1zis-adminisztr\u00e1torok, rendszeradminisztr\u00e1torok \u00e9s fejleszt\u0151k sz\u00e1m\u00e1ra, akik \u00e9rdekl\u0151dnek a Postgres hibakeres\u00e9se ir\u00e1nt.<\/p>\n

\n

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"A<\/p>\n

<\/p>\n

Az \u00e9n nevem Alexey Lesovsky, a Data Egret c\u00e9get k\u00e9pviselem. <\/p>\n

<\/p>\n

R\u00f6viden magamr\u00f3l. R\u00e9ges-r\u00e9gen rendszergazdak\u00e9nt kezdtem. <\/p>\n

<\/p>\n

K\u00fcl\u00f6nb\u00f6z\u0151 Linux rendszereket adminisztr\u00e1ltam, \u00e9s foglalkoztam k\u00fcl\u00f6nb\u00f6z\u0151 Linuxhoz kapcsol\u00f3d\u00f3 dolgokkal, mint p\u00e9ld\u00e1ul virtualiz\u00e1ci\u00f3val, monitoroz\u00e1ssal, proxyval stb. De egy id\u0151 ut\u00e1n egyre ink\u00e1bb az adatb\u00e1zisokkal kezdtem foglalkozni, k\u00fcl\u00f6n\u00f6sen a PostgreSQL-lel. Nagyon tetszett. Id\u0151vel a munk\u00e1m jelent\u0151s r\u00e9sz\u00e9t a PostgreSQL-nek szenteltem, \u00edgy fokozatosan PostgreSQL DBA lettem.<\/p>\n

<\/p>\n

Karrierem sor\u00e1n mindig is foglalkoztatott a statisztika, monitoroz\u00e1s, telemetria kivon\u00e1s\u00e1nak t\u00e9m\u00e1ja. Amikor rendszergazda voltam, nagyon szoros kapcsolatban voltam a Zabbix-szal. \u00cdrtam egy kis script gy\u0171jtem\u00e9nyt, mint zabbix-extensions<\/a><\/noindex>. Ez abban az id\u0151ben el\u00e9g n\u00e9pszer\u0171 volt. Ezen kereszt\u00fcl k\u00fcl\u00f6nb\u00f6z\u0151 fontos dolgokat lehetett monitorozni, nemcsak Linuxot, hanem m\u00e1s komponenseket is.<\/p>\n

<\/p>\n

Jelenleg a PostgreSQL-lel foglalkozom. M\u00e1r \u00edrok egy m\u00e1sik eszk\u00f6zt, ami lehet\u0151v\u00e9 teszi a PostgreSQL statisztik\u00e1j\u00e1val val\u00f3 munk\u00e1t. Ezt h\u00edvj\u00e1k pgCenter<\/a><\/noindex> (cikk a Habr\u00e9n \u2014 PostgreSQL statisztika idegek \u00e9s stressz n\u00e9lk\u00fcl<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

R\u00f6vid bevezet\u0151. Milyen helyzetek szoktak el\u0151fordulni \u00fcgyfeleinkn\u00e9l? Valamilyen hiba l\u00e9p fel az adatb\u00e1zissal kapcsolatban. Miut\u00e1n helyre\u00e1ll\u00edtott\u00e1k az adatb\u00e1zist, a r\u00e9szleg vezet\u0151je vagy a fejleszt\u00e9si vezet\u0151 meg\u00e9rkezik, \u00e9s azt mondja: \u201eBar\u00e1tok, monitorozni kellene az adatb\u00e1zist, mert t\u00f6rt\u00e9nt valami rossz, \u00e9s meg kellene akad\u00e1lyozni, hogy a j\u00f6v\u0151ben hasonl\u00f3 esetek t\u00f6rt\u00e9njenek.\u201d Itt kezd\u0151dik az izgalmas folyamat a monitoroz\u00f3 rendszer kiv\u00e1laszt\u00e1s\u00e1ban vagy a megl\u00e9v\u0151 rendszer adapt\u00e1l\u00e1s\u00e1ban, hogy monitorozhassuk az adatb\u00e1zisunkat \u2013 legyen az PostgreSQL, MySQL vagy m\u00e1s. A koll\u00e9g\u00e1k kezdenek javaslatokat tenni: \u201eHallottam, hogy l\u00e9tezik egy ilyen adatb\u00e1zis. Haszn\u00e1ljuk azt.\u201d A koll\u00e9g\u00e1k elkezdenek vitatkozni egym\u00e1ssal. V\u00e9g\u00fcl kiv\u00e1lasztunk egy adatb\u00e1zist, de a PostgreSQL monitoroz\u00e1s benne meglehet\u0151sen gyenge, \u00e9s mindig sz\u00fcks\u00e9g van valamilyen kieg\u00e9sz\u00edt\u00e9sre. Repo-kat kell venn\u00fcnk a GitHubr\u00f3l, kl\u00f3noznunk kell azokat, \u00e1t kell alak\u00edtanunk a szkripteket, valahogy be kell \u00e1ll\u00edtanunk. Ennek eredm\u00e9nyek\u00e9ppen ez k\u00e9zi munk\u00e1v\u00e1 v\u00e1lik. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Ez\u00e9rt ebben a besz\u00e1mol\u00f3ban megpr\u00f3b\u00e1lom \u00e1tadni azokat a tud\u00e1sokat, amelyek r\u00e9v\u00e9n nemcsak PostgreSQL, hanem m\u00e1s adatb\u00e1zisok monitoroz\u00e1s\u00e1t is v\u00e1laszthatjuk. Olyan tud\u00e1st k\u00edv\u00e1nok adni, ami lehet\u0151v\u00e9 teszi, hogy t\u00f6k\u00e9letes\u00edts\u00fck a monitoroz\u00e1si rendszer\u00fcnket, hogy hasznot nyerhess\u00fcnk bel\u0151le, \u00e9s id\u0151ben figyelmeztethess\u00fcnk a k\u00f6zelg\u0151 viharokra, amelyek felmer\u00fclhetnek. <\/p>\n

<\/p>\n

A besz\u00e1mol\u00f3ban szerepl\u0151 \u00f6tletek k\u00f6zvetlen\u00fcl alkalmazhat\u00f3k b\u00e1rmely adatb\u00e1zisra, legyen az rel\u00e1ci\u00f3s adatb\u00e1zis vagy noSQL. Teh\u00e1t itt nemcsak PostgreSQL lesz, hanem sok recept is arr\u00f3l, hogyan lehet ezt megval\u00f3s\u00edtani PostgreSQL-ben. P\u00e9ld\u00e1k lesznek lek\u00e9rdez\u00e9sekre, entit\u00e1sokra, amelyek jelen vannak a PostgreSQL-ben monitoroz\u00e1shoz. Ha az \u00f6n adatb\u00e1zisa rendelkezik hasonl\u00f3 funkci\u00f3kkal, amelyeket bele lehet illeszteni a monitoroz\u00e1sba, azokat is alkalmazhatja, hozz\u00e1adhatja, \u00e9s akkor minden rendben lesz.<\/p>\n

<\/p>\n

\"AA besz\u00e1mol\u00f3ban nem fogok
\nmes\u00e9lni arr\u00f3l, hogyan sz\u00e1ll\u00edtsuk \u00e9s t\u00e1roljuk a metrik\u00e1kat. Nem fogok semmit mondani az adatok ut\u00f3feldolgoz\u00e1s\u00e1r\u00f3l vagy azok felhaszn\u00e1l\u00f3k sz\u00e1m\u00e1ra t\u00f6rt\u00e9n\u0151 megjelen\u00edt\u00e9s\u00e9r\u0151l. \u00c9s nem fogok semmit mondani az \u00e9rtes\u00edt\u00e9sekr\u0151l.
\nA t\u00f6rt\u00e9net sor\u00e1n k\u00fcl\u00f6nb\u00f6z\u0151 monitoroz\u00e1sokr\u00f3l fogok k\u00e9perny\u0151k\u00e9peket mutatni, \u00e9s bizonyos kritik\u00e1kat fogalmazok meg. Ennek ellen\u00e9re megpr\u00f3b\u00e1lom elker\u00fclni a m\u00e1rk\u00e1k eml\u00edt\u00e9s\u00e9t, hogy ne hozzak l\u00e9tre rekl\u00e1mot vagy negat\u00edv rekl\u00e1mot ezen term\u00e9kek sz\u00e1m\u00e1ra. \u00cdgy teh\u00e1t minden egybees\u00e9s v\u00e9letlenszer\u0171, \u00e9s a fant\u00e1zi\u00e1jukra b\u00edzzuk \u0151ket.
\n\"A
\nEl\u0151sz\u00f6r is tiszt\u00e1zzuk, mi is az a monitoroz\u00e1s. A monitoroz\u00e1s egy nagyon fontos dolog, amivel rendelkezni kell. Ezt mindenki \u00e9rti. Ugyanakkor a monitoroz\u00e1s nem tartozik a v\u00e1llalati term\u00e9kek k\u00f6z\u00e9, \u00e9s k\u00f6zvetlen hat\u00e1ssal nincs a c\u00e9g profitj\u00e1ra, ez\u00e9rt a monitoroz\u00e1sra mindig a fennmarad\u00f3 id\u0151b\u0151l jut id\u0151. Ha van id\u0151nk, foglalkozunk a monitoroz\u00e1ssal, ha nincs id\u0151nk, akkor rendben, betessz\u00fck a h\u00e1tral\u00e9kba, \u00e9s egy nap visszat\u00e9r\u00fcnk ezekhez a feladatokhoz. <\/p>\n

<\/p>\n

Ez\u00e9rt a gyakorlatunk alapj\u00e1n, amikor \u00fcgyfelekhez megy\u00fcnk, a monitoroz\u00e1s gyakran alulfejlesztett, \u00e9s nem rendelkezik olyan \u00e9rdekes dolgokkal, amelyek seg\u00edten\u00e9nek jobban v\u00e9gezni a munk\u00e1t az adatb\u00e1zissal. Ez\u00e9rt a monitoroz\u00e1st mindig finom\u00edtani kell. <\/p>\n

<\/p>\n

Az adatb\u00e1zisok olyan bonyolult dolgok, amelyeket szint\u00e9n monitorozni kell, mert az adatb\u00e1zisok inform\u00e1ci\u00f3t\u00e1rol\u00f3k\u00e9nt funkcion\u00e1lnak. Az inform\u00e1ci\u00f3 nagyon fontos a c\u00e9g sz\u00e1m\u00e1ra, \u00e9s semmik\u00e9ppen sem szabad elvesz\u00edteni. Ugyanakkor az adatb\u00e1zisok nagyon \u00f6sszetett szoftverdarabok. Sok \u00f6sszetev\u0151b\u0151l \u00e1llnak. \u00c9s ezek k\u00f6z\u00fcl sok \u00f6sszetev\u0151t figyelemmel kell k\u00eds\u00e9rni. <\/p>\n

<\/p>\n

\"AHa kifejezetten a PostgreSQL-r\u00f3l besz\u00e9l\u00fcnk, akkor azt egy olyan s\u00e9ma form\u00e1j\u00e1ban lehet \u00e1br\u00e1zolni, amely sok \u00f6sszetev\u0151b\u0151l \u00e1ll. Ezek az \u00f6sszetev\u0151k k\u00f6lcs\u00f6nhat\u00e1sban \u00e1llnak egym\u00e1ssal. Ugyanakkor a PostgreSQL-ben l\u00e9tezik egy \u00fagynevezett Stats Collector alrendszer, amely lehet\u0151v\u00e9 teszi e alrendszerek m\u0171k\u00f6d\u00e9s\u00e9nek statisztik\u00e1j\u00e1nak gy\u0171jt\u00e9s\u00e9t, \u00e9s valamilyen fel\u00fcletet biztos\u00edt az adminisztr\u00e1tor vagy a felhaszn\u00e1l\u00f3 sz\u00e1m\u00e1ra, hogy megtekinthesse ezeket a statisztik\u00e1kat. <\/p>\n

<\/p>\n

Ez a statisztika egy funkci\u00f3k \u00e9s n\u00e9zetek (view) halmazak\u00e9nt van megjelen\u00edtve. Ezeket t\u00e1bl\u00e1zatokk\u00e9nt is nevezhetj\u00fck. Teh\u00e1t egy egyszer\u0171 psql kliens seg\u00edts\u00e9g\u00e9vel csatlakozhat az adatb\u00e1zishoz, v\u00e9grehajthat egy select parancsot ezekre a funkci\u00f3kra \u00e9s n\u00e9zetekre, \u00e9s konkr\u00e9t sz\u00e1madatokat kap a PostgreSQL alrendszerek m\u0171k\u00f6d\u00e9s\u00e9r\u0151l. <\/p>\n

<\/p>\n

Ezeket a sz\u00e1madatokat hozz\u00e1adhatja a kedvenc monitoroz\u00f3 rendszer\u00e9hez, grafikonokat rajzolhat, funkci\u00f3kat adhat hozz\u00e1, \u00e9s hossz\u00fa t\u00e1v\u00fa elemz\u00e9st kaphat. <\/p>\n

<\/p>\n

De a jelent\u00e9sben nem fogom r\u00e9szletezni ezeket a funkci\u00f3kat, mert ez eg\u00e9sz napot ig\u00e9nybe vehet. Csak k\u00e9t-h\u00e1rom-n\u00e9gy dologra fogok koncentr\u00e1lni, \u00e9s elmondom, hogyan seg\u00edtenek a jobb monitoroz\u00e1sban.
\n\"A
\nHa a datab\u00e1zis monitoroz\u00e1s\u00e1r\u00f3l besz\u00e9l\u00fcnk, mit kell figyelni? El\u0151sz\u00f6r is a rendelkez\u00e9sre \u00e1ll\u00e1st kell monitorozni, mert az adatb\u00e1zis egy szolg\u00e1ltat\u00e1s, amely hozz\u00e1f\u00e9r\u00e9st biztos\u00edt az adatokhoz az \u00fcgyfelek sz\u00e1m\u00e1ra, \u00e9s figyelni kell a rendelkez\u00e9sre \u00e1ll\u00e1st, valamint bizonyos min\u0151s\u00e9gi \u00e9s mennyis\u00e9gi jellemz\u0151it is. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Azt is monitorozni kell, hogy h\u00e1ny \u00fcgyf\u00e9l csatlakozik az adatb\u00e1zisunkhoz, mert ezek lehetnek norm\u00e1lis \u00fcgyfelek, de lehetnek k\u00e1ros \u00fcgyfelek is, akik k\u00e1rt okozhatnak az adatb\u00e1zisban. \u0150ket is figyelni \u00e9s nyomon k\u00f6vetni kell.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Amikor az \u00fcgyfelek csatlakoznak az adatb\u00e1zishoz, nyilv\u00e1nval\u00f3, hogy dolgozni kezdenek az adatokkal, ez\u00e9rt figyelni kell arra is, hogyan dolgoznak az \u00fcgyfelek az adatokkal: mely t\u00e1bl\u00e1kkal \u00e9s kisebb m\u00e9rt\u00e9kben milyen indexekkel. Azaz meg kell vizsg\u00e1lnunk az \u00fcgyfeleink \u00e1ltal l\u00e9trehozott munkaterhel\u00e9st.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

De a munkaterhel\u00e9s term\u00e9szetesen lek\u00e9rdez\u00e9sekb\u0151l \u00e1ll. Az alkalmaz\u00e1sok csatlakoznak az adatb\u00e1zishoz, \u00e9s lek\u00e9rdez\u00e9seken kereszt\u00fcl k\u00e9rdezik le az adatokat, ez\u00e9rt fontos, hogy \u00e9rt\u00e9kelj\u00fck, milyen lek\u00e9rdez\u00e9sek vannak az adatb\u00e1zisunkban, figyelj\u00fck azok megfelel\u0151s\u00e9g\u00e9t \u00e9s hogy nincsenek-e el\u00edr\u00e1sok, \u00e9s hogy bizonyos lehet\u0151s\u00e9geket \u00e1t kell \u00edrni, hogy gyorsabban \u00e9s jobb teljes\u00edtm\u00e9nnyel m\u0171k\u00f6djenek. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

\u00c9s mivel az adatb\u00e1zisr\u00f3l besz\u00e9l\u00fcnk, az adatb\u00e1zis mindig h\u00e1tt\u00e9rfolyamatokat is jelent. A h\u00e1tt\u00e9rfolyamatok lehet\u0151v\u00e9 teszik, hogy az adatb\u00e1zis teljes\u00edtm\u00e9nye j\u00f3 szinten maradjon, ez\u00e9rt m\u0171k\u00f6d\u00e9s\u00fckh\u00f6z sz\u00fcks\u00e9ges n\u00e9mi er\u0151forr\u00e1s. Ugyanakkor \u00e1tfed\u00e9sbe ker\u00fclhetnek az \u00fcgyf\u00e9llek\u00e9rdez\u00e9sek er\u0151forr\u00e1saival, \u00edgy a hajlamos h\u00e1tt\u00e9rfolyamatok k\u00f6zvetlen\u00fcl befoly\u00e1solhatj\u00e1k az \u00fcgyf\u00e9llek\u00e9rdez\u00e9sek teljes\u00edtm\u00e9ny\u00e9t. Ez\u00e9rt ezeket is figyelni \u00e9s nyomon k\u00f6vetni kell, hogy ne legyenek elt\u00e9r\u00e9sek a h\u00e1tt\u00e9rfolyamatokkal kapcsolatban. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

A rendszeres metrik\u00e1k tekintet\u00e9ben a database monitoring tov\u00e1bbra is a rendszeres metrik\u00e1kban marad. De figyelembe v\u00e9ve, hogy az infrastrukt\u00far\u00e1nk jelent\u0151s r\u00e9sze a felh\u0151be k\u00f6lt\u00f6zik, egy k\u00fcl\u00f6n \u00e1llom\u00e1s rendszeres metrik\u00e1i mindig m\u00e1sodlagoss\u00e1 v\u00e1lnak. M\u00e9gis, az adatb\u00e1zisok eset\u00e9ben ezek tov\u00e1bbra is aktu\u00e1lisak, \u00e9s term\u00e9szetesen a rendszeres metrik\u00e1k figyel\u00e9se is sz\u00fcks\u00e9ges. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

A rendszeres metrik\u00e1k viszonylag j\u00f3l \u00e1llnak, a legt\u00f6bb modern monitoring rendszer m\u00e1r t\u00e1mogatja ezeket a metrik\u00e1kat, de \u00f6sszess\u00e9g\u00e9ben n\u00e9h\u00e1ny komponens m\u00e9gis hi\u00e1nyzik, \u00e9s bizonyos dolgokat hozz\u00e1 kell adni. Err\u0151l is besz\u00e9lni fogok, n\u00e9h\u00e1ny di\u00e1n fogok eml\u00edteni \u0151ket. <\/p>\n

<\/p>\n

\"A
\nA terv els\u0151 pontja az el\u00e9rhet\u0151s\u00e9g. Mi az el\u00e9rhet\u0151s\u00e9g? Az el\u00e9rhet\u0151s\u00e9g sz\u00e1momra azt jelenti, hogy az adatb\u00e1zis k\u00e9pes kiszolg\u00e1lni a kapcsolatokat, azaz az adatb\u00e1zis \u00fczemel, mint egy szolg\u00e1ltat\u00e1s, \u00e9s fogadja az \u00fcgyfelek kapcsolatait. Ezt az el\u00e9rhet\u0151s\u00e9get n\u00e9h\u00e1ny jellemz\u0151 alapj\u00e1n lehet \u00e9rt\u00e9kelni. Ezeket a jellemz\u0151ket nagyon k\u00e9nyelmesen megjelen\u00edthetj\u00fck a m\u0171szerfalakon. <\/p>\n

<\/p>\n

\"A
\nMindenki tudja, mi az a m\u0171szerfal. Amikor egy pillant\u00e1st vetsz a k\u00e9perny\u0151re, amelyen az \u00f6sszes sz\u00fcks\u00e9ges inform\u00e1ci\u00f3 \u00f6ssze van gy\u0171jtve. Azonnal meg tudod \u00e1llap\u00edtani \u2013 van-e probl\u00e9ma az adatb\u00e1zisban vagy nincs.
\nEnnek megfelel\u0151en az adatb\u00e1zis el\u00e9rhet\u0151s\u00e9g\u00e9t \u00e9s m\u00e1s kulcsfontoss\u00e1g\u00fa jellemz\u0151it mindig be kell emelni a m\u0171szerfalakra, hogy ez az inform\u00e1ci\u00f3 mindig k\u00e9zn\u00e9l legyen. N\u00e9h\u00e1ny tov\u00e1bbi r\u00e9szlet, amely seg\u00edthet a incidensek, illetve az esem\u00e9nyek nyomoz\u00e1s\u00e1ban, m\u00e1r m\u00e1sodlagos m\u0171szerfalakon kell hogy legyen, vagy el kell rejteni a drilldown linkeken, amelyek k\u00fcls\u0151 monitoring rendszerekre vezetnek. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Egy j\u00f3l ismert monitoring rendszer p\u00e9ld\u00e1ja. Ez egy nagyon men\u0151 monitoring rendszer. Nagyon sok adatot gy\u0171jt, de v\u00e9lem\u00e9nyem szerint furcsa a m\u0171szerfalak fogalma. Van egy \"m\u0171szerfal l\u00e9trehoz\u00e1sa\" link. De amikor te l\u00e9trehozol egy m\u0171szerfalat, akkor l\u00e9trehozol egy list\u00e1t, amely k\u00e9t oszlopb\u00f3l \u00e1ll, egy grafikonokb\u00f3l \u00e1ll\u00f3 list\u00e1t. \u00c9s amikor meg akarsz n\u00e9zni valamit, akkor elkezdesz kattintani, lapozni, keresni a sz\u00fcks\u00e9ges grafikont. Erre id\u0151t kell ford\u00edtani, azaz ilyen \u00e9rtelemben nincsenek val\u00f3di m\u0171szerfalak. Csak grafikonok list\u00e1i l\u00e9teznek.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Mi sz\u00fcks\u00e9ges hozz\u00e1adni ezekhez a m\u0171szerfalakhoz? Kezdhetj\u00fck a v\u00e1laszid\u0151vel, amely egy fontos jellemz\u0151. A PostgreSQL-ben van egy n\u00e9zet, a pg_stat_statements. Alap\u00e9rtelmez\u00e9s szerint ez ki van kapcsolva, de ez egy fontos rendszer n\u00e9zet, amelyet mindig be kell kapcsolni \u00e9s haszn\u00e1lni. Inform\u00e1ci\u00f3t t\u00e1rol az \u00f6sszes v\u00e9grehajtott lek\u00e9rdez\u00e9sr\u0151l, amelyek az adatb\u00e1zisban teljes\u00fcltek. <\/p>\n

<\/p>\n

Ennek megfelel\u0151en kiindulhatunk abb\u00f3l, hogy az \u00f6sszes lek\u00e9rdez\u00e9s v\u00e9grehajt\u00e1si idej\u00e9t \u00f6sszeadjuk, \u00e9s elosztjuk a lek\u00e9rdez\u00e9sek sz\u00e1m\u00e1val a fenti mez\u0151k seg\u00edts\u00e9g\u00e9vel. De ez egy \u00e1tlagos h\u0151m\u00e9rs\u00e9klet a k\u00f3rh\u00e1zban. M\u00e1s mez\u0151kb\u0151l is kiindulhatunk - p\u00e9ld\u00e1ul a lek\u00e9rdez\u00e9sek minim\u00e1lis, maxim\u00e1lis \u00e9s medi\u00e1n v\u00e9grehajt\u00e1si idej\u00e9b\u0151l. S\u0151t, percentiliseket is \u00e9p\u00edthet\u00fcnk, a PostgreSQL-ben vannak olyan funkci\u00f3k, amelyek ezt lehet\u0151v\u00e9 teszik. \u00cdgy n\u00e9h\u00e1ny sz\u00e1mot kaphatunk, amelyek jellemzik az adatb\u00e1zisunk v\u00e1laszidej\u00e9t az m\u00e1r v\u00e9grehajtott lek\u00e9rdez\u00e9sek alapj\u00e1n, azaz nem v\u00e9gz\u00fcnk hamis lek\u00e9rdez\u00e9st, mint a 'select 1', \u00e9s n\u00e9zz\u00fck a v\u00e1laszid\u0151t, hanem az m\u00e1r v\u00e9grehajtott lek\u00e9rdez\u00e9sek v\u00e1laszidej\u00e9t elemezz\u00fck, \u00e9s megjelen\u00edtj\u00fck vagy k\u00fcl\u00f6n sz\u00e1mk\u00e9nt, vagy grafikonk\u00e9nt \u00e1br\u00e1zoljuk. <\/p>\n

<\/p>\n

Fontos nyomon k\u00f6vetni a rendszer \u00e1ltal jelenleg gener\u00e1lt hib\u00e1k sz\u00e1m\u00e1t is. Ehhez haszn\u00e1lhatjuk a pg_stat_database n\u00e9zetet. Az xact_rollback mez\u0151re \u00f6sszpontos\u00edtunk. Ez a mez\u0151 nemcsak az adatb\u00e1zisban t\u00f6rt\u00e9nt rollbackek sz\u00e1m\u00e1t mutatja, hanem a hib\u00e1k sz\u00e1m\u00e1t is figyelembe veszi. M\u00e1s sz\u00f3val, ezt a sz\u00e1mot megjelen\u00edthetj\u00fck a m\u0171szerfalunkon, \u00e9s figyelhetj\u00fck, h\u00e1ny hib\u00e1nk van jelenleg. Ha sok hiba van, az m\u00e1r j\u00f3 ok arra, hogy megn\u00e9zz\u00fck a napl\u00f3kat, \u00e9s l\u00e1ssuk, mik azok a hib\u00e1k \u00e9s mi\u00e9rt t\u00f6rt\u00e9nnek, majd pedig nyomozzunk \u00e9s megoldjuk \u0151ket.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Hozz\u00e1adhatunk egy tachom\u00e9tert is. Ez a tranzakci\u00f3k sz\u00e1m\u00e1t m\u00e1sodpercenk\u00e9nt \u00e9s a lek\u00e9rdez\u00e9sek sz\u00e1m\u00e1t m\u00e1sodpercenk\u00e9nt m\u00e9ri. M\u00e1s sz\u00f3val, ezeket a sz\u00e1mokat haszn\u00e1lhatja az adatb\u00e1zis\u00e1nak aktu\u00e1lis teljes\u00edtm\u00e9ny\u00e9nek meghat\u00e1roz\u00e1s\u00e1ra, \u00e9s figyelheti, hogy vannak-e lek\u00e9rdez\u00e9sek, tranzakci\u00f3s cs\u00facsok, vagy \u00e9ppen ellenkez\u0151leg, az adatb\u00e1zis alul van terhelve, mert egy backend le\u00e1llt. Ezt a sz\u00e1mot mindig figyelemmel kell k\u00eds\u00e9rni, \u00e9s eml\u00e9kezni kell, hogy a projekt\u00fcnk sz\u00e1m\u00e1ra ez a teljes\u00edtm\u00e9ny norm\u00e1lis, m\u00edg a magasabb \u00e9s alacsonyabb \u00e9rt\u00e9kek m\u00e1r probl\u00e9m\u00e1snak t\u0171nnek, ez\u00e1ltal figyelmet ig\u00e9nyel, hogy mi\u00e9rt is vannak ilyen sz\u00e1mok.<\/p>\n

<\/p>\n

A tranzakci\u00f3k sz\u00e1m\u00e1nak \u00e9rt\u00e9kel\u00e9s\u00e9hez ism\u00e9telten h\u00edvhatjuk a pg_stat_database n\u00e9zetet. \u00d6sszeadhatjuk a commitok \u00e9s a rollbackek sz\u00e1m\u00e1t, \u00edgy megkaphatjuk a m\u00e1sodpercenk\u00e9nti tranzakci\u00f3k sz\u00e1m\u00e1t. <\/p>\n

<\/p>\n

Mindenki tudja, hogy egy tranzakci\u00f3ba t\u00f6bb k\u00e9r\u00e9s is belef\u00e9r? Ez\u00e9rt a TPS \u00e9s QPS kicsit elt\u00e9r\u0151ek. <\/p>\n

<\/p>\n

A m\u00e1sodpercenk\u00e9nti k\u00e9r\u00e9sek sz\u00e1m\u00e1t a pg_stat_statements seg\u00edts\u00e9g\u00e9vel nyerhetj\u00fck ki, \u00e9s egyszer\u0171en \u00f6sszeadhatjuk az \u00f6sszes v\u00e9grehajtott k\u00e9r\u00e9s sz\u00e1m\u00e1t. Nyilv\u00e1nval\u00f3, hogy az aktu\u00e1lis \u00e9rt\u00e9ket a kor\u00e1bbi \u00e9rt\u00e9kkel \u00f6sszehasonl\u00edtva kivonjuk, \u00edgy megkapjuk a delt\u00e1t, ami a mennyis\u00e9get adja.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Lehet\u0151s\u00e9g\u00fcnk van tov\u00e1bbi metrik\u00e1k hozz\u00e1ad\u00e1s\u00e1ra, amelyek seg\u00edtenek \u00e9rt\u00e9kelni az adatb\u00e1zisunk el\u00e9rhet\u0151s\u00e9g\u00e9t \u00e9s nyomon k\u00f6vetni, hogy t\u00f6rt\u00e9nt-e valamilyen le\u00e1ll\u00e1s. <\/p>\n

<\/p>\n

Egyik ilyen metrika az uptime. Az uptime a PostgreSQL-ben kicsit tr\u00fckk\u00f6s dolog. Elmondom, mi\u00e9rt. Amikor a PostgreSQL elindul, elkezd\u0151dik az uptime sz\u00e1m\u00edt\u00e1sa. De ha egy adott pillanatban, p\u00e9ld\u00e1ul \u00e9jjel v\u00e9grehajt\u00e1sra ker\u00fclt egy feladat, \u00e9s a OOM-killer k\u00e9nyszer\u00edtett m\u00f3don le\u00e1ll\u00edtotta a PostgreSQL gyermekfolyamat\u00e1t, akkor a PostgreSQL az \u00f6sszes kliens kapcsolatot megsz\u00fcnteti, vissza\u00e1ll\u00edtja a sharded mem\u00f3ria ter\u00fclet\u00e9t \u00e9s az utols\u00f3 ellen\u0151rz\u00e9si pontr\u00f3l kezd helyre\u00e1ll\u00edtani. Am\u00edg ez a helyre\u00e1ll\u00edt\u00e1s tart, az adatb\u00e1zis nem fogad kapcsolatokat, teh\u00e1t ezt a helyzetet le\u00e1ll\u00e1sk\u00e9nt lehet \u00e9rt\u00e9kelni. De az uptime sz\u00e1ml\u00e1l\u00f3 nem fog null\u00e1z\u00f3dni, mert figyelembe veszi a postmaster ind\u00edt\u00e1s\u00e1nak id\u0151pontj\u00e1t az els\u0151 pillanatt\u00f3l kezdve. Ez\u00e9rt az ilyen helyzetek kihagyhat\u00f3k.<\/p>\n

<\/p>\n

A munkav\u00e1llal\u00f3k sz\u00e1m\u00e1t is figyelemmel kell k\u00eds\u00e9rni. Mindenki tudja, mi az az autovacuum a PostgreSQL-ben? Ez egy \u00e9rdekes alrendszer a PostgreSQL-ben. R\u00f3la sok cikk k\u00e9sz\u00fclt, sz\u00e1mos el\u0151ad\u00e1s tartalmazza. Sok vita van a v\u00e1kuumr\u00f3l, arr\u00f3l, hogyan kell m\u0171k\u00f6dnie. Sokan sz\u00fcks\u00e9gtelen rossznak tartj\u00e1k. De \u00edgy van. Ez valami anal\u00f3g a szem\u00e9ttiszt\u00edt\u00f3val, amely tiszt\u00edtja az elavult sorverzi\u00f3kat, amelyekre egyik tranzakci\u00f3 sem tart ig\u00e9nyt, \u00e9s helyet szabad\u00edt fel a t\u00e1bl\u00e1kban \u00e9s indexekben az \u00faj sorok sz\u00e1m\u00e1ra. <\/p>\n

<\/p>\n

Mi\u00e9rt fontos ezt figyelemmel k\u00eds\u00e9rni? Mert a v\u00e1kuum n\u00e9ha nagyon f\u00e1jdalmas lehet. Nagy mennyis\u00e9g\u0171 er\u0151forr\u00e1st ig\u00e9nyel, \u00e9s emiatt a kliens k\u00e9rd\u00e9sek szenvednek. <\/p>\n

<\/p>\n

A pg_stat_activity n\u00e9zet seg\u00edts\u00e9g\u00e9vel kell figyelemmel k\u00eds\u00e9rni, amelyr\u0151l a k\u00f6vetkez\u0151 szakaszban fogok besz\u00e9lni. Ez a n\u00e9zet megmutatja az adatb\u00e1zis aktu\u00e1lis aktivit\u00e1s\u00e1t. Ezen kereszt\u00fcl nyomon tudjuk k\u00f6vetni, h\u00e1ny v\u00e1kuum fut \u00e9ppen most. Nyomon tudjuk k\u00f6vetni a v\u00e1kuumokat, \u00e9s l\u00e1tni fogjuk, hogy ha t\u00fall\u00e9pj\u00fck a korl\u00e1tot, akkor ez okot ad a PostgreSQL be\u00e1ll\u00edt\u00e1sainak ellen\u0151rz\u00e9s\u00e9re \u00e9s a v\u00e1kuum m\u0171k\u00f6d\u00e9s\u00e9nek optimaliz\u00e1l\u00e1s\u00e1ra. <\/p>\n

<\/p>\n

A PostgreSQL egy m\u00e1sik saj\u00e1toss\u00e1ga, hogy a hossz\u00fa tranzakci\u00f3kt\u00f3l nagyon s\u00falyosan szenved. K\u00fcl\u00f6n\u00f6sen azokt\u00f3l a tranzakci\u00f3kt\u00f3l, amelyek sok\u00e1ig fognak \u00e9s semmit sem csin\u00e1lnak. Ezeket stat idle-in-transaction n\u00e9ven ismerj\u00fck. Egy ilyen tranzakci\u00f3 z\u00e1rol\u00e1sokat tart, ami akad\u00e1lyozza a v\u00e1kuum m\u0171k\u00f6d\u00e9s\u00e9t. Ennek k\u00f6vetkezm\u00e9nyek\u00e9nt a t\u00e1bl\u00e1k megn\u0151nek, m\u00e9ret\u00fck n\u0151. Az ezekkel a t\u00e1bl\u00e1kkal dolgoz\u00f3 lek\u00e9rdez\u00e9sek egyre lassabb\u00e1 v\u00e1lnak, mert minden r\u00e9gi verzi\u00f3t ki kell \u00e1sni a mem\u00f3ri\u00e1b\u00f3l a lemezre \u00e9s vissza.<\/strong> Ez\u00e9rt figyelni kell a leghosszabb tranzakci\u00f3k, a leghosszabb v\u00e1kuumlek\u00e9rdez\u00e9sek id\u0151tartam\u00e1t is. Ha olyan folyamatokat l\u00e1tunk, amelyek m\u00e1r nagyon hossz\u00fa ideje, t\u00f6bb mint 10-20-30 percig futnak az OLTP terhel\u00e9s alatt, akkor r\u00e1juk figyelmet kell ford\u00edtani, \u00e9s k\u00e9nyszer\u00edteni kell a befejez\u00e9s\u00fcket, vagy optimaliz\u00e1lni kell az alkalmaz\u00e1st, hogy ne h\u00edvt\u00e1k \u0151ket meg, \u00e9s ne l\u00f3gjanak olyan sok\u00e1ig.<\/strong> Analitikai terhel\u00e9s eset\u00e9n a 10-20-30 perc norm\u00e1lis, ott el\u0151fordulhatnak enn\u00e9l hosszabb id\u0151tartamok is. <\/p>\n

<\/p>\n

\"A
\nTov\u00e1bb\u00e1 van lehet\u0151s\u00e9g\u00fcnk az \u00fcgyfelekkel val\u00f3 kapcsol\u00f3d\u00e1s nyomon k\u00f6vet\u00e9s\u00e9re. Amikor m\u00e1r l\u00e9trehoztuk a m\u0171szerfalat, \u00e9s figyelembe vett\u00fck a rendelkez\u00e9sre \u00e1ll\u00e1s kulcsfontoss\u00e1g\u00fa mutat\u00f3it, tov\u00e1bbi inform\u00e1ci\u00f3kat is hozz\u00e1adhatunk a csatlakoztatott \u00fcgyfelekr\u0151l. <\/p>\n

<\/p>\n

A csatlakoztatott \u00fcgyfelekr\u0151l sz\u00f3l\u00f3 inform\u00e1ci\u00f3 az\u00e9rt fontos, mert a PostgreSQL szempontj\u00e1b\u00f3l az \u00fcgyfelek k\u00fcl\u00f6nb\u00f6z\u0151ek lehetnek. Vannak j\u00f3 \u00fcgyfelek \u00e9s rossz \u00fcgyfelek. <\/p>\n

<\/p>\n

Egyszer\u0171 p\u00e9lda. \u00dcgyf\u00e9l alatt \u00e9rtem az alkalmaz\u00e1st. Az alkalmaz\u00e1s csatlakozott az adatb\u00e1zishoz, \u00e9s azonnal elkezdi k\u00fcldeni a k\u00e9rd\u00e9seit, az adatb\u00e1zis feldolgozza azokat \u00e9s visszak\u00fcldi az eredm\u00e9nyeket az \u00fcgyf\u00e9lnek. Ezek j\u00f3 \u00e9s helyes \u00fcgyfelek. <\/p>\n

<\/p>\n

El\u0151fordulhat, hogy az \u00fcgyf\u00e9l csatlakozott, fenntartja a kapcsolatot, de k\u00f6zben semmit sem csin\u00e1l. Ez \u00e1llapot idle-ben van. <\/p>\n

<\/p>\n

De vannak rossz \u00fcgyfelek is. P\u00e9ld\u00e1ul, ugyanaz az \u00fcgyf\u00e9l csatlakozott, megnyitott egy tranzakci\u00f3t, v\u00e9gzett valamit az adatb\u00e1zisban, majd visszament a k\u00f3dhoz, hogy mondjuk, egy k\u00fcls\u0151 forr\u00e1shoz forduljon vagy adatfeldolgoz\u00e1st v\u00e9gezzen. De ek\u00f6zben nem z\u00e1rta le a tranzakci\u00f3t. \u00cdgy a tranzakci\u00f3 l\u00f3g az adatb\u00e1zisban, \u00e9s blokkol\u00e1st tart fent egy sorra. Ez rossz \u00e1llapot. Ha az alkalmaz\u00e1s valahol bel\u00fcl megbukik egy kiv\u00e9tel (Exception) miatt, a tranzakci\u00f3 nagyon sok\u00e1ig nyitva maradhat. Ez k\u00f6zvetlen hat\u00e1ssal van a PostgreSQL teljes\u00edtm\u00e9ny\u00e9re. A PostgreSQL lassabban fog m\u0171k\u00f6dni. Ez\u00e9rt fontos, hogy az ilyen \u00fcgyfeleket id\u0151ben nyomon k\u00f6vess\u00fck \u00e9s k\u00e9nyszer\u00edts\u00fck az \u0151 munk\u00e1juk befejez\u00e9s\u00e9re. Az alkalmaz\u00e1sunkat is optimaliz\u00e1lni kell, hogy ne forduljanak el\u0151 ilyen helyzetek. <\/p>\n

<\/p>\n

M\u00e1s rossz \u00fcgyfelek a v\u00e1rakoz\u00f3 \u00fcgyfelek. De \u0151k a k\u00f6r\u00fclm\u00e9nyek miatt v\u00e1lnak rossz \u00fcgyfelekk\u00e9. P\u00e9ld\u00e1ul egy egyszer\u0171 v\u00e1rakoz\u00f3 tranzakci\u00f3: meg tud nyitni egy tranzakci\u00f3t, le tudja blokkolni bizonyos sorokat, majd valahol a k\u00f3dban megbukik, \u00e9s l\u00f3g\u00f3 tranzakci\u00f3 marad. Egy m\u00e1sik \u00fcgyf\u00e9l j\u00f6n, megk\u00e9ri ugyanazokat az adatokat, de tal\u00e1lkozik a blokkol\u00e1ssal, mert az a l\u00f3g\u00f3 tranzakci\u00f3 m\u00e1r blokkol\u00e1s alatt tart bizonyos sz\u00fcks\u00e9ges sorokat. A m\u00e1sodik tranzakci\u00f3 \u00edgy v\u00e1rakozni fog, am\u00edg az els\u0151 tranzakci\u00f3 befejez\u0151dik vagy az adminisztr\u00e1tor k\u00e9nyszer\u00edtve z\u00e1rja be. \u00cdgy a v\u00e1rakoz\u00f3 tranzakci\u00f3k felhalmoz\u00f3dhatnak, \u00e9s t\u00fall\u00e9phetik az adatb\u00e1zis kapcsolatok limitj\u00e9t. Amikor a limit \u00e1tl\u00e9p\u00e9sre ker\u00fcl, az alkalmaz\u00e1s m\u00e1r nem tud dolgozni az adatb\u00e1zissal. Ez m\u00e1r v\u00e9szhelyzet a projekt sz\u00e1m\u00e1ra. Ez\u00e9rt fontos figyelni a rossz \u00fcgyfelekre, \u00e9s id\u0151ben reag\u00e1lni r\u00e1juk. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Egy m\u00e1sik p\u00e9lda a monitoroz\u00e1sra. Itt m\u00e1r egy rendezett ir\u00e1ny\u00edt\u00f3pult van. Fent tal\u00e1lhat\u00f3 az inform\u00e1ci\u00f3 a kapcsolatok sz\u00e1m\u00e1r\u00f3l. DB connection \u2013 8 darab. \u00c9s ennyi. Nincs inform\u00e1ci\u00f3nk arr\u00f3l, hogy mely \u00fcgyfelek akt\u00edvak, melyek csak t\u00e9tlenek \u00e9s nem csin\u00e1lnak semmit. Nincs adat a l\u00f3g\u00f3 tranzakci\u00f3kr\u00f3l \u00e9s a v\u00e1rakoz\u00f3 kapcsolatok sz\u00e1m\u00e1r\u00f3l, azaz ez egy olyan sz\u00e1m, amely megmutatja a kapcsolatok sz\u00e1m\u00e1t \u00e9s ennyit. A tov\u00e1bbiakban tal\u00e1lgassanak csak.
\n\"A
\nEz\u00e9rt, hogy ezt az inform\u00e1ci\u00f3t a monitoroz\u00e1sba beilleszthess\u00fck, a pg_stat_activity rendszer n\u00e9zethez kell fordulnunk. Ha sok id\u0151t t\u00f6lt\u00f6tt\u00e9l PostgreSQL-ben, ez egy nagyon hasznos n\u00e9zet, amely a bar\u00e1todd\u00e1 v\u00e1lhat, mivel megmutatja a PostgreSQL jelenlegi tev\u00e9kenys\u00e9g\u00e9t, azaz mi t\u00f6rt\u00e9nik benne. Minden folyamatnak van egy k\u00fcl\u00f6n sora, amely inform\u00e1ci\u00f3t ad az adott folyamatr\u00f3l: milyen g\u00e9pr\u0151l t\u00f6rt\u00e9nt a csatlakoz\u00e1s, mely felhaszn\u00e1l\u00f3val, milyen n\u00e9v alatt, mikor indult a tranzakci\u00f3, milyen lek\u00e9rdez\u00e9s folyik \u00e9ppen, \u00e9s mi volt az utols\u00f3 v\u00e9grehajtott lek\u00e9rdez\u00e9s. \u00cdgy a kliens \u00e1llapot\u00e1t az stat mez\u0151 alapj\u00e1n tudjuk \u00e9rt\u00e9kelni. M\u00e1s sz\u00f3val, csoportos\u00edt\u00e1st v\u00e9gezhet\u00fcnk e mez\u0151 szerint, \u00e9s megkaphatjuk azokat a statisztik\u00e1kat, amelyek most a adatb\u00e1zisban vannak, \u00e9s a csatlakoz\u00e1sok sz\u00e1m\u00e1t, amelyek e statisztik\u00e1val rendelkeznek az adatb\u00e1zisban. A kapott sz\u00e1mokat pedig elk\u00fcldhetj\u00fck a monitoroz\u00f3nkba, \u00e9s grafikonokat k\u00e9sz\u00edthet\u00fcnk bel\u0151l\u00fck.
\nA tranzakci\u00f3k id\u0151tartam\u00e1nak \u00e9rt\u00e9kel\u00e9se is fontos. M\u00e1r besz\u00e9ltem arr\u00f3l, hogy a takar\u00edt\u00e1s id\u0151tartam\u00e1t fontos m\u00e9rni, de a tranzakci\u00f3k \u00e9rt\u00e9kel\u00e9se pontosan ugyan\u00edgy t\u00f6rt\u00e9nik. Vannak xact_start \u00e9s query_start mez\u0151k. Ezek felejts\u00fck el, a tranzakci\u00f3k \u00e9s a lek\u00e9rdez\u00e9sek ind\u00edt\u00e1si idej\u00e9t mutatj\u00e1k. Az now() f\u00fcggv\u00e9nyt vessz\u00fck, amely a jelenlegi id\u0151b\u00e9lyeget mutatja, \u00e9s kivonjuk a tranzakci\u00f3 \u00e9s a lek\u00e9rdez\u00e9s timestamp-j\u00e9t. \u00cdgy megkapjuk a tranzakci\u00f3 id\u0151tartam\u00e1t, valamint a lek\u00e9rdez\u00e9s id\u0151tartam\u00e1t. <\/p>\n

<\/p>\n

Ha hossz\u00fa tranzakci\u00f3kat l\u00e1tunk, m\u00e1r be kell fejezn\u00fcnk \u0151ket. OLTP terhel\u00e9s eset\u00e9n a hossz\u00fa tranzakci\u00f3k m\u00e1r 1-2-3 percn\u00e9l hosszabbak.<\/strong>. OLAP terhel\u00e9s eset\u00e9n a hossz\u00fa tranzakci\u00f3k norm\u00e1lisak, de ha azok k\u00e9t \u00f3r\u00e1n\u00e1l tov\u00e1bb futnak, az is jelzi, hogy valahol probl\u00e9ma van.<\/strong> <\/p>\n

<\/p>\n

\"A
\nAmikor az \u00fcgyfelek csatlakoznak az adatb\u00e1zishoz, elkezdik feldolgozni az adatainkat. Hozz\u00e1f\u00e9rnek a t\u00e1bl\u00e1khoz, hozz\u00e1f\u00e9rnek az indexekhez, hogy adatokat nyerjenek ki a t\u00e1bl\u00e1b\u00f3l. Fontos \u00e9rt\u00e9kelni, hogyan dolgoznak az \u00fcgyfelek ezekkel az adatokkal.<\/p>\n

<\/p>\n

Ez arra szolg\u00e1l, hogy \u00e9rt\u00e9kelj\u00fck a munkaterhel\u00e9s\u00fcnket, \u00e9s nagyj\u00e1b\u00f3l meg\u00e9rts\u00fck, hogy mely t\u00e1bl\u00e1k a leg\"forr\u00f3bbak\". P\u00e9ld\u00e1ul, amikor a \"forr\u00f3\" t\u00e1bl\u00e1kat szeretn\u00e9nk egy gyors SSD t\u00e1rol\u00f3ra helyezni. Azok a r\u00e9gi arch\u00edv t\u00e1bl\u00e1k, amelyeket m\u00e1r r\u00e9g\u00f3ta nem haszn\u00e1lunk, \u00e1thelyezhet\u0151k egy \"hideg\" arch\u00edvumba, SATA lemezekre, ahol \u00e9lhetnek, \u00e9s csak sz\u00fcks\u00e9g eset\u00e9n hivatkozunk r\u00e1juk. <\/p>\n

<\/p>\n

Ez hasznos anom\u00e1li\u00e1k \u00e9szlel\u00e9s\u00e9re is a k\u00fcl\u00f6nf\u00e9le kiad\u00e1sok \u00e9s telep\u00edt\u00e9sek ut\u00e1n. Tegy\u00fck fel, hogy a projekt kiadott egy \u00faj funkci\u00f3t. P\u00e9ld\u00e1ul, hozz\u00e1adtak egy \u00faj funkci\u00f3t az adatb\u00e1zissal val\u00f3 munk\u00e1hoz. Ha grafikonokat k\u00e9sz\u00edt\u00fcnk a t\u00e1bl\u00e1k haszn\u00e1lat\u00e1r\u00f3l, k\u00f6nnyen \u00e9szlelhetj\u00fck ezeket az anom\u00e1li\u00e1kat a grafikonokon. P\u00e9ld\u00e1ul, a friss\u00edt\u00e9si vagy t\u00f6rl\u00e9si cs\u00facsokat. Ez nagyon j\u00f3l l\u00e1that\u00f3 lesz.<\/p>\n

<\/p>\n

Anom\u00e1li\u00e1kat lehet felfedezni a \"m\u00f3dosult\" statisztik\u00e1k eset\u00e9n is. Mit jelent ez? A PostgreSQL-ben nagyon er\u0151s \u00e9s j\u00f3 lek\u00e9rdez\u00e9s-tervez\u0151 tal\u00e1lhat\u00f3. A fejleszt\u0151k sok id\u0151t sz\u00e1nnak a fejleszt\u00e9s\u00e9re. Hogyan m\u0171k\u00f6dik? Ahhoz, hogy j\u00f3 terveket k\u00e9sz\u00edtsen, a PostgreSQL egy bizonyos id\u0151intervallumban, rendszeresen gy\u0171jti a statisztik\u00e1kat az adatok eloszl\u00e1s\u00e1r\u00f3l a t\u00e1bl\u00e1kban. Ezek a leggyakoribb \u00e9rt\u00e9kek: egyedi \u00e9rt\u00e9kek sz\u00e1ma, NULL-inform\u00e1ci\u00f3 a t\u00e1bl\u00e1zatban, rengeteg inform\u00e1ci\u00f3. <\/p>\n

<\/p>\n

Ezek alapj\u00e1n a tervez\u0151 k\u00fcl\u00f6nb\u00f6z\u0151 lek\u00e9rdez\u00e9seket \u00e9p\u00edt, v\u00e1lasztja ki a legoptim\u00e1lisabbat, \u00e9s ezt a lek\u00e9rdez\u00e9si tervet haszn\u00e1lja a lek\u00e9rdez\u00e9s v\u00e9grehajt\u00e1s\u00e1hoz \u00e9s az adatok visszaad\u00e1s\u00e1hoz. <\/p>\n

<\/p>\n

El\u0151fordulhat, hogy a statisztika \"el\u00faszik\". Az adatok min\u0151s\u00e9ge \u00e9s mennyis\u00e9ge megv\u00e1ltozott a t\u00e1bl\u00e1ban, de a statisztik\u00e1t nem gy\u0171jt\u00f6tt\u00e9k \u00f6ssze. \u00cdgy a l\u00e9trehozott tervek nem optim\u00e1lisak lehetnek. Ha a terveink nem optim\u00e1lisak a gy\u0171jt\u00f6tt megfigyel\u00e9sek alapj\u00e1n, a t\u00e1bl\u00e1kn\u00e1l l\u00e1thatjuk ezeket az anom\u00e1li\u00e1kat. P\u00e9ld\u00e1ul, ha valahol l\u00e9nyegesen megv\u00e1ltoztak az adatok, \u00e9s az index helyett a t\u00e1bl\u00e1n val\u00f3 soros \u00e1thalad\u00e1s kezdett el haszn\u00e1l\u00f3dni, teh\u00e1t, ha a lek\u00e9rdez\u00e9snek csak 100 sort kell visszaadnia (limittel 100), akkor ehhez a lek\u00e9rdez\u00e9shez teljes \u00e1tvizsg\u00e1l\u00e1st kell v\u00e9gezni. Ez mindig nagyon rossz hat\u00e1ssal van a teljes\u00edtm\u00e9nyre. <\/p>\n

<\/p>\n

\u00c9s ezt l\u00e1thatjuk a megfigyel\u00e9s sor\u00e1n. M\u00e1r megn\u00e9zhetj\u00fck ezt a lek\u00e9rdez\u00e9st, elv\u00e9gezhetj\u00fck rajta az explain-t, \u00f6sszegy\u0171jthetj\u00fck a statisztik\u00e1kat, l\u00e9trehozhatunk egy \u00faj, kieg\u00e9sz\u00edt\u0151 indexet. \u00c9s m\u00e1r reag\u00e1lhatunk erre a probl\u00e9m\u00e1ra. Ez\u00e9rt ez fontos. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Egy m\u00e1sik p\u00e9lda a megfigyel\u00e9sre. Azt hiszem, sokan m\u00e1r ismerik, mert nagyon n\u00e9pszer\u0171. Ki haszn\u00e1lja a projektjeiben? Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. De van itt egy rossz r\u00e9szlet. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

T\u00f6bb grafikon van. \u00c9s az egys\u00e9g\u00fckk\u00e9nt byte-ok vannak megadva, azaz 5 grafikon van. Ezek: Insert data, Update data, Delete data, Fetch data \u00e9s Return data. Az egys\u00e9g m\u00e9r\u00e9se byte-okban van. De az a helyzet, hogy a PostgreSQL statisztik\u00e1i tuple-k\u00e9nt (sorokban) szolg\u00e1ltatj\u00e1k az adatokat. Ennek megfelel\u0151en ezek a grafikonok nagyon j\u00f3 m\u00f3dj\u00e1t jelenthetik a munkaterhel\u00e9s jelent\u0151s cs\u00f6kkent\u00e9s\u00e9nek, mert a tuple nem byte, a tuple egy sor, az sok byte, \u00e9s mindig v\u00e1ltoz\u00f3 hossz\u00fas\u00e1g\u00fa. Azaz a munkaterhel\u00e9s byte-okban val\u00f3 kisz\u00e1m\u00edt\u00e1sa tuple-k seg\u00edts\u00e9g\u00e9vel irre\u00e1lis feladat vagy nagyon neh\u00e9z. Ez\u00e9rt amikor dashboard-ot vagy be\u00e9p\u00edtett megfigyel\u00e9st haszn\u00e1l, mindig fontos meg\u00e9rteni, hogy az helyesen m\u0171k\u00f6dik, \u00e9s helyesen \u00e9rt\u00e9kelt adatokat ad vissza. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Hogyan nyerhet\u00fcnk statisztik\u00e1kat ezeken a t\u00e1bl\u00e1kon? Erre a PostgreSQL-ben van egy bizonyos csal\u00e1d n\u00e9zet. A f\u0151 n\u00e9zet pedig az pg_stat_user_tables<\/a><\/noindex>. A user_tables azt jelenti, hogy a felhaszn\u00e1l\u00f3 \u00e1ltal l\u00e9trehozott t\u00e1bl\u00e1k. Ezzel szemben l\u00e9teznek rendszerszint\u0171 n\u00e9zetek, amelyeket maguk a PostgreSQL haszn\u00e1lnak. \u00c9s van egy \u00f6sszes\u00edt\u0151 t\u00e1bl\u00e1zat, az Alltables, amely tartalmazza mind a rendszerszint\u0171, mind a felhaszn\u00e1l\u00f3i t\u00e1bl\u00e1kat. B\u00e1rmelyikb\u0151l kiindulhat, ami a legjobban tetszik.<\/p>\n

<\/p>\n

A fent eml\u00edtett mez\u0151k alapj\u00e1n \u00e9rt\u00e9kelhetj\u00fck az insert, update \u00e9s delete mennyis\u00e9g\u00e9t. Az a dashboard p\u00e9lda, amit haszn\u00e1ltam, pontosan ezeket a mez\u0151ket haszn\u00e1lja a munkaterhel\u00e9s jellemz\u0151inek \u00e9rt\u00e9kel\u00e9s\u00e9re. Ez\u00e9rt mi is t\u00e1maszkodhatunk ezekre. De \u00e9rdemes eml\u00e9kezni arra, hogy ezek tuple-k, nem byte-ok, ez\u00e9rt nem tudjuk egyszer\u0171en byte-k\u00e9nt kezelni \u0151ket.<\/p>\n

<\/p>\n

Ezeken az adatokon alapulva elk\u00e9sz\u00edthetj\u00fck az \u00fagynevezett TopN t\u00e1bl\u00e1zatokat. P\u00e9ld\u00e1ul Top-5, Top-10. \u00c9s nyomon k\u00f6vethetj\u00fck azokat a \u201eforr\u00f3\u201d t\u00e1bl\u00e1kat, amelyek jobban haszn\u00e1l\u00f3dnak, mint a t\u00f6bbiek. P\u00e9ld\u00e1ul az 5 \u201eforr\u00f3\u201d t\u00e1bla besz\u00far\u00e1sa. \u00c9s ezeken a TopN t\u00e1bl\u00e1zatokon kereszt\u00fcl \u00e9rt\u00e9kelj\u00fck a munkaterhel\u00e9s\u00fcnket, \u00e9s nyomon k\u00f6vethetj\u00fck a munkaterhel\u00e9s ingadoz\u00e1sait k\u00fcl\u00f6nb\u00f6z\u0151 kiad\u00e1sok \u00e9s friss\u00edt\u00e9sek, valamint deployok ut\u00e1n. <\/p>\n

<\/p>\n

Fontos, hogy \u00e9rt\u00e9kelj\u00fck a t\u00e1bl\u00e1zatok m\u00e9ret\u00e9t, mert n\u00e9ha a fejleszt\u0151k \u00faj funkci\u00f3kat vezetnek be, \u00e9s a t\u00e1bl\u00e1zataink megn\u00f6vekednek az \u00faj adatok miatt, an\u00e9lk\u00fcl hogy el\u0151re megj\u00f3solt\u00e1k volna, hogyan fog ez hatni az adatb\u00e1zis m\u00e9ret\u00e9re. Az ilyen esetek n\u00e9ha meglepet\u00e9sek lehetnek sz\u00e1munkra. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Most j\u00f6n egy kis k\u00e9rd\u00e9s az \u00f6n sz\u00e1m\u00e1ra. Milyen k\u00e9rd\u00e9s mer\u00fcl fel, amikor \u00e9szreveszi a terhel\u00e9st az adatb\u00e1zis szerver\u00e9n? Mi a k\u00f6vetkez\u0151 k\u00e9rd\u00e9s, ami felmer\u00fcl \u00f6nben? <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

De a k\u00f6vetkez\u0151 k\u00e9rd\u00e9s \u00edgy mer\u00fcl fel. Milyen lek\u00e9rdez\u00e9sek okozz\u00e1k a terhel\u00e9st? Teh\u00e1t, nem \u00e9rdekes n\u00e9zni a folyamatokat, amelyek terhel\u00e9st okoznak. Nyilv\u00e1nval\u00f3, hogy ha a hoston adatb\u00e1zis van, akkor az adatb\u00e1zis fut \u00e9s \u00e9rtelemszer\u0171en csak az adatb\u00e1zisok fogj\u00e1k lefoglalni a rendszert. Ha megn\u00e9zz\u00fck a Top parancsot, akkor l\u00e1tni fogjuk a PostgreSQL folyamatainak list\u00e1j\u00e1t, amelyek valamit csin\u00e1lnak. A Top-b\u00f3l azonban nem lesz vil\u00e1gos, hogy mit csin\u00e1lnak. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Ez\u00e9rt fel kell ismerni azokat a lek\u00e9rdez\u00e9seket, amelyek a legnagyobb terhel\u00e9st okozz\u00e1k, mert a lek\u00e9rdez\u00e9sek optimaliz\u00e1l\u00e1sa \u00e1ltal\u00e1ban nagyobb hasznot hoz, mint a PostgreSQL vagy az oper\u00e1ci\u00f3s rendszer konfigur\u00e1ci\u00f3j\u00e1nak optimaliz\u00e1l\u00e1sa, esetleg a hardver optimaliz\u00e1l\u00e1sa. Szerintem ez k\u00f6r\u00fclbel\u00fcl 80-85-90%-ot jelent. R\u00e1ad\u00e1sul ezt sokkal gyorsabban lehet elv\u00e9gezni. Gyorsabb m\u00f3dos\u00edtani egy lek\u00e9rdez\u00e9st, mint a konfigur\u00e1ci\u00f3t m\u00f3dos\u00edtani, \u00fajraind\u00edt\u00e1st tervezni, k\u00fcl\u00f6n\u00f6sen, ha az adatb\u00e1zist nem lehet \u00fajraind\u00edtani, vagy ha hardvert kell hozz\u00e1adni. Egyszer\u0171bb valahol \u00e1t\u00edrni a lek\u00e9rdez\u00e9st vagy indexet hozz\u00e1adni, hogy jobb eredm\u00e9nyt kapjunk a lek\u00e9rdez\u00e9sb\u0151l. <\/p>\n

<\/p>\n

\"A
\nEz\u00e9rt sz\u00fcks\u00e9g van a lek\u00e9rdez\u00e9sek \u00e9s azok \u00e9sszer\u0171s\u00e9g\u00e9nek figyel\u00e9s\u00e9re. Vegy\u00fcnk egy m\u00e1sik p\u00e9ld\u00e1t a monitoroz\u00e1sra. \u00c9s itt is, l\u00e1tsz\u00f3lag kit\u0171n\u0151 a monitoroz\u00e1s. Van inform\u00e1ci\u00f3 a replik\u00e1ci\u00f3r\u00f3l, az \u00e1tviteli sebess\u00e9gr\u0151l, a z\u00e1rol\u00e1sokr\u00f3l, az er\u0151forr\u00e1sok kihaszn\u00e1l\u00e1s\u00e1r\u00f3l. Minden csod\u00e1latos, de nincs inform\u00e1ci\u00f3 a lek\u00e9rdez\u00e9sekr\u0151l. Nem vil\u00e1gos, hogy milyen lek\u00e9rdez\u00e9sek futnak az adatb\u00e1zisunkban, mennyi ideig tartanak, h\u00e1ny ilyen lek\u00e9rdez\u00e9s van. Mindig sz\u00fcks\u00e9g van erre az inform\u00e1ci\u00f3ra a monitoroz\u00e1sban. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

\u00c9s ennek az inform\u00e1ci\u00f3nak a megszerz\u00e9s\u00e9hez haszn\u00e1lhatjuk a pg_stat_statements modult. Ennek alapj\u00e1n k\u00fcl\u00f6nf\u00e9le grafikonokat \u00e9p\u00edthet\u00fcnk. P\u00e9ld\u00e1ul inform\u00e1ci\u00f3t nyerhet\u00fcnk a leggyakoribb lek\u00e9rdez\u00e9sekr\u0151l, azaz azokr\u00f3l a lek\u00e9rdez\u00e9sekr\u0151l, amelyeket a leggyakrabban futtatnak. Igen, a telep\u00edt\u00e9sek ut\u00e1n is nagyon hasznos r\u00e1n\u00e9zni \u00e9s meg\u00e9rteni, hogy van-e valamilyen hirtelen k\u00e9rd\u00e9srobban\u00e1s. <\/p>\n

<\/p>\n

Megmonitorozhatjuk a leghosszabb lek\u00e9rdez\u00e9seket, azaz azokat, amelyek a leghosszabb ideig futnak. Ezek a processzoron dolgoznak, \u00e9s ig\u00e9nylik a bemeneti-kimeneti m\u0171veleteket. Ezt is \u00e9rt\u00e9kelhetj\u00fck a total_time, mean_time, blk_write_time \u00e9s blk_read_time mez\u0151k alapj\u00e1n. <\/p>\n

<\/p>\n

\u00c9rt\u00e9kelhetj\u00fck \u00e9s monitorozhatjuk a legnagyobb er\u0151forr\u00e1s-ig\u00e9ny\u0171 lek\u00e9rdez\u00e9seket, azokat, amelyek lemezr\u0151l olvasnak, amelyek a mem\u00f3riahaszn\u00e1lattal foglalkoznak, vagy \u00e9ppen ellenkez\u0151leg, valamilyen \u00edr\u00e1si terhel\u00e9st gener\u00e1lnak.<\/p>\n

<\/p>\n

\u00c9rt\u00e9kelhetj\u00fck a legb\u0151kez\u0171bb lek\u00e9rdez\u00e9seket is. Ezek azok a lek\u00e9rdez\u00e9sek, amelyek nagy mennyis\u00e9g\u0171 sort adnak vissza. P\u00e9ld\u00e1ul lehet egy olyan lek\u00e9rdez\u00e9s, ahol elfelejtett\u00e9k megadni a limitet. Ez egyszer\u0171en visszaadja az \u00f6sszes t\u00e1bl\u00e1zat tartalm\u00e1t, vagy a k\u00e9rt t\u00e1bl\u00e1zatok nyom\u00e1n a lek\u00e9rdez\u00e9st.<\/p>\n

<\/p>\n

Monitorozhatjuk a lek\u00e9rdez\u00e9seket is, amelyek ideiglenes f\u00e1jlokat vagy ideiglenes t\u00e1bl\u00e1zatokat haszn\u00e1lnak. <\/p>\n

<\/p>\n

\"A
\nMaradtak a h\u00e1tt\u00e9rfolyamatok is. A h\u00e1tt\u00e9rfolyamatok els\u0151sorban a checkpointok, amelyeket ellen\u0151rz\u0151 pontoknak is h\u00edvnak, az autovacuum \u00e9s a replik\u00e1ci\u00f3. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Egy m\u00e1sik p\u00e9lda a monitoroz\u00e1sra. Balra tal\u00e1lhat\u00f3 a Karbantart\u00e1s f\u00fcl, \u00e1tv\u00e1lthatunk, \u00e9s rem\u00e9lj\u00fck, hogy tal\u00e1lunk valami hasznosat. De itt csak a v\u00e1kuum id\u0151tartama \u00e9s a statisztikai gy\u0171jt\u00e9s ideje tal\u00e1lhat\u00f3, m\u00e1s semmi. Ez nagyon szeg\u00e9nyes inform\u00e1ci\u00f3, ez\u00e9rt mindig sz\u00fcks\u00e9g van arra, hogy meg\u00e9rts\u00fck, hogyan m\u0171k\u00f6dnek a h\u00e1tt\u00e9rfolyamatok az adatb\u00e1zisunkban, \u00e9s hogy vannak-e probl\u00e9m\u00e1k a m\u0171k\u00f6d\u00e9s\u00fckkel. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Amikor a checkpointokat vizsg\u00e1ljuk, eml\u00e9kezn\u00fcnk kell arra, hogy a checkpointok a 'piszkos' oldalakat a shardolt mem\u00f3ri\u00e1b\u00f3l a lemezre \u00edrj\u00e1k, majd l\u00e9trehoznak egy checkpointot. Ez a checkpoint m\u00e1r k\u00e9s\u0151bb felhaszn\u00e1lhat\u00f3 egy hely, amikor a PostgreSQL v\u00e1ratlanul le\u00e1llt. <\/p>\n

<\/p>\n

Teh\u00e1t ahhoz, hogy az \u00f6sszes \u201episzkos\u201d oldalt le tudjuk \u00edrni a lemezre, bizonyos mennyis\u00e9g\u0171 \u00edr\u00e1si m\u0171veletet kell v\u00e9gezni. \u00c1ltal\u00e1ban, ha sok a mem\u00f3ria, az nagyon sok. Ha a csekkpontok nagyon gyakran t\u00f6rt\u00e9nnek r\u00f6vid id\u0151intervallumokban, akkor a lemez teljes\u00edtm\u00e9nye jelent\u0151sen cs\u00f6kken. Ez pedig a klienslek\u00e9r\u00e9seket is h\u00e1tr\u00e1nyosan \u00e9rinti, mivel az er\u0151forr\u00e1sok\u00e9rt k\u00fczdenek, \u00e9s nem lesz elegend\u0151 teljes\u00edtm\u00e9ny\u00fck. <\/p>\n

<\/p>\n

\u00cdgy a pg_stat_bgwriter seg\u00edts\u00e9g\u00e9vel nyomon k\u00f6vethetj\u00fck a csekkpontok sz\u00e1m\u00e1t a megadott mez\u0151k alapj\u00e1n. Ha egy adott id\u0151intervallumban (p\u00e9ld\u00e1ul 10-15-20 perc, f\u00e9l \u00f3ra) t\u00fal sok csekkpont t\u00f6rt\u00e9nik, mondjuk 3-4-5 darab, akkor ez m\u00e1r probl\u00e9ma lehet. Ekkor \u00e9rdemes megn\u00e9zni az adatb\u00e1zist \u00e9s a konfigur\u00e1ci\u00f3t, hogy mi okozhatja ezt a sok csekkpontot. Lehet, hogy nagy \u00edr\u00e1si m\u0171veletek zajlanak. A munkaterhel\u00e9s alapj\u00e1n m\u00e1r tudunk \u00e9rt\u00e9kelni, mivel a munkaterhel\u00e9si grafikonok is fel lettek v\u00e9ve. Ki tudjuk finom\u00edtani a csekkpontok be\u00e1ll\u00edt\u00e1sait, \u00e9s \u00fagy m\u00f3dos\u00edtani, hogy ne befoly\u00e1solj\u00e1k jelent\u0151sen a lek\u00e9r\u00e9sek teljes\u00edtm\u00e9ny\u00e9t.<\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Ism\u00e9t a vacuum automatiz\u00e1l\u00e1sr\u00f3l besz\u00e9lek, mert ez egy olyan dolog, amely, mint m\u00e1r eml\u00edtettem, k\u00f6nnyen befoly\u00e1solhatja a lemezek \u00e9s a lek\u00e9r\u00e9sek teljes\u00edtm\u00e9ny\u00e9t, ez\u00e9rt mindig fontos \u00e9rt\u00e9kelni az autovacuum mennyis\u00e9g\u00e9t. <\/p>\n

<\/p>\n

Az autovacuum munk\u00e1sainak sz\u00e1ma az adatb\u00e1zisban korl\u00e1tozott. Alap\u00e9rtelmez\u00e9s szerint h\u00e1rom van, teh\u00e1t ha folyamatosan h\u00e1rom munk\u00e1s dolgozik az adatb\u00e1zison, az azt jelenti, hogy az autovacuum nincs megfelel\u0151en be\u00e1ll\u00edtva, emelni kell a korl\u00e1tokat, fel\u00fcl kell vizsg\u00e1lni az autovacuum be\u00e1ll\u00edt\u00e1sait, \u00e9s m\u00e1r bele kell n\u00e9zni a konfigur\u00e1ci\u00f3ba.
\nFontos \u00e9rt\u00e9kelni, hogy mely autovacuum munk\u00e1sok m\u0171k\u00f6dnek. Lehet, hogy egy felhaszn\u00e1l\u00f3 \u00e1ltal ind\u00edtott vacuumr\u00f3l van sz\u00f3, a DBA k\u00e9zzel ind\u00edtotta el azt, \u00e9s ez terhel\u00e9st okozott. Vagy az is lehet, hogy a tranzakci\u00f3sz\u00e1ml\u00e1l\u00f3t visszatekert vacuumokkal van dolgunk. N\u00e9h\u00e1ny PostgreSQL verzi\u00f3n\u00e1l ezek nagyon nehezek. K\u00f6nnyen el\u0151id\u00e9zhetik a teljes\u00edtm\u00e9ny cs\u00f6kken\u00e9s\u00e9t, mert az eg\u00e9sz t\u00e1bl\u00e1t \u00e1t kell n\u00e9zni\u00fck, \u00e9s a t\u00e1bl\u00e1zat \u00f6sszes blokkj\u00e1t be kell j\u00e1rniuk. <\/p>\n

<\/p>\n

\u00c9s term\u00e9szetesen a v\u00e1kuumok id\u0151tartama. Ha hossz\u00fa v\u00e1kuumaink vannak, amelyek nagyon sok\u00e1ig m\u0171k\u00f6dnek, akkor \u00e9rdemes \u00fajra a v\u00e1kuum konfigur\u00e1ci\u00f3j\u00e1ra figyelni, \u00e9s esetleg fel\u00fclvizsg\u00e1lni a be\u00e1ll\u00edt\u00e1sait. Mert el\u0151fordulhat olyan helyzet, amikor a v\u00e1kuum hossz\u00fa ideig dolgozik egy t\u00e1bl\u00e1n (3-4 \u00f3ra), de a v\u00e1kuum alatt a t\u00e1bl\u00e1ban \u00fajra nagy mennyis\u00e9g\u0171 halott sor gy\u0171lhet \u00f6ssze. \u00c9s ahogy a v\u00e1kuum befejez\u0151dik, \u00fajra v\u00e1kuumozni kell ezt a t\u00e1bl\u00e1t. \u00c9s eljutunk a helyzethez - v\u00e9gtelen v\u00e1kuum. Ilyen esetben a v\u00e1kuum nem tud megbirk\u00f3zni a feladat\u00e1val, \u00e9s a t\u00e1bl\u00e1k fokozatosan n\u00f6vekednek, holott a hasznos adatok mennyis\u00e9ge v\u00e1ltozatlan marad. Ez\u00e9rt a hossz\u00fa v\u00e1kuumok eset\u00e9n mindig figyel\u00fcnk a konfigur\u00e1ci\u00f3ra, \u00e9s pr\u00f3b\u00e1ljuk optimaliz\u00e1lni, de \u00fagy, hogy a kliens lek\u00e9rdez\u00e9sek teljes\u00edtm\u00e9nye ne szenvedjen. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

Jelenleg szinte nincs olyan PostgreSQL telep\u00edt\u00e9s, ahol ne lenne streamelt replik\u00e1ci\u00f3. A replik\u00e1ci\u00f3 az adatok \u00e1tvitel\u00e9nek folyamata a mesterb\u0151l a replik\u00e1ba.<\/p>\n

<\/p>\n

A replik\u00e1ci\u00f3 PostgreSQL-ben a tranzakci\u00f3s napl\u00f3 r\u00e9v\u00e9n val\u00f3sul meg. A mester tranzakci\u00f3s napl\u00f3t gener\u00e1l. A tranzakci\u00f3s napl\u00f3 a h\u00e1l\u00f3zati kapcsolaton kereszt\u00fcl a replik\u00e1ba \u00e9rkezik, majd a replik\u00e1n \u00fajra megjelenik. Egyszer\u0171. <\/p>\n

<\/p>\n

Ennek megfelel\u0151en a replik\u00e1ci\u00f3s k\u00e9s\u00e9s figyel\u00e9s\u00e9re a pg_stat_replication n\u00e9zetet haszn\u00e1lj\u00e1k. De nem minden olyan egyszer\u0171 vele. A 10-es verzi\u00f3ban a n\u00e9zet n\u00e9h\u00e1ny v\u00e1ltoz\u00e1son ment kereszt\u00fcl. El\u0151sz\u00f6r is, n\u00e9h\u00e1ny mez\u0151t \u00e1tneveztek. \u00c9s n\u00e9h\u00e1ny mez\u0151 hozz\u00e1 lett adva. A 10-es verzi\u00f3ban megjelentek olyan mez\u0151k, amelyek lehet\u0151v\u00e9 teszik a replik\u00e1ci\u00f3s k\u00e9s\u00e9s m\u00e1sodpercekben val\u00f3 \u00e9rt\u00e9kel\u00e9s\u00e9t. Ez nagyon k\u00e9nyelmes. A 10-es verzi\u00f3 el\u0151tt a replik\u00e1ci\u00f3s k\u00e9s\u00e9s b\u00e1jtokban val\u00f3 \u00e9rt\u00e9kel\u00e9s\u00e9re volt lehet\u0151s\u00e9g. Ez a lehet\u0151s\u00e9g megmaradt a 10-es verzi\u00f3ban, teh\u00e1t v\u00e1laszthatja, mi a k\u00e9nyelmesebb - \u00e9rt\u00e9kelni a k\u00e9s\u00e9st b\u00e1jtokban vagy m\u00e1sodpercekben. Sokan mindkett\u0151t csin\u00e1lj\u00e1k.<\/p>\n

<\/p>\n

Mindazon\u00e1ltal ahhoz, hogy \u00e9rt\u00e9kelni tudjuk a replik\u00e1ci\u00f3s k\u00e9s\u00e9st, tudni kell a tranzakci\u00f3s napl\u00f3 poz\u00edci\u00f3j\u00e1t. Ezek a tranzakci\u00f3s napl\u00f3 poz\u00edci\u00f3k \u00e9ppen a pg_stat_replication n\u00e9zetben tal\u00e1lhat\u00f3k. Mondhatni, a pg_xlog_location_diff() f\u00fcggv\u00e9ny seg\u00edts\u00e9g\u00e9vel k\u00e9t pontot vehet\u00fcnk a tranzakci\u00f3s napl\u00f3ban. Kisz\u00e1m\u00edthatjuk a delta k\u00f6z\u00f6tti k\u00fcl\u00f6nbs\u00e9get, \u00e9s megkaphatjuk a replik\u00e1ci\u00f3s k\u00e9s\u00e9st b\u00e1jtokban. Ez nagyon k\u00e9nyelmes \u00e9s egyszer\u0171. <\/p>\n

<\/p>\n

A 10. verzi\u00f3ban ezt a funkci\u00f3t pg_wal_lsn_diff()-ra keresztelt\u00e9k \u00e1t. \u00c1ltal\u00e1ban minden olyan funkci\u00f3ban, n\u00e9zetben, eszk\u00f6zben, ahol az \u201exlog\u201d sz\u00f3 el\u0151fordult, azt \u201ewal\u201d-ra cser\u00e9lt\u00e9k. Ez \u00e9rv\u00e9nyes a n\u00e9zetekre \u00e9s a funkci\u00f3kra is. Ez egy \u00faj fejleszt\u00e9s. <\/p>\n

<\/p>\n

R\u00e1ad\u00e1sul a 10. verzi\u00f3ban \u00faj sorok ker\u00fcltek bevezet\u00e9sre, amelyek konkr\u00e9tan a k\u00e9s\u00e9st mutatj\u00e1k. Ezek a write lag, flush lag, replay lag. Vagyis ezeket fontos figyelni. Ha azt l\u00e1tjuk, hogy a replik\u00e1ci\u00f3 k\u00e9slekedik, akkor meg kell vizsg\u00e1lni, hogy mi okozta ezt, honnan sz\u00e1rmazik, \u00e9s meg kell sz\u00fcntetni a probl\u00e9m\u00e1t. <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

A rendszeres metrik\u00e1k szinte minden rendben van. Amikor b\u00e1rmilyen fel\u00fcgyeleti rendszer l\u00e9trej\u00f6n, a rendszeres metrik\u00e1k figyel\u00e9s\u00e9vel kezd\u0151dik. Ez mag\u00e1ban foglalja a processzorok, mem\u00f3ria, swap, h\u00e1l\u00f3zat \u00e9s lemez kihaszn\u00e1lts\u00e1g\u00e1t. De sz\u00e1mos param\u00e9ter alap\u00e9rtelmez\u00e9s szerint hi\u00e1nyzik. <\/p>\n

<\/p>\n

Ha a folyamat kihaszn\u00e1lts\u00e1ga rendben van, a lemez kihaszn\u00e1lts\u00e1g\u00e1val probl\u00e9m\u00e1k vannak. \u00c1ltal\u00e1ban a fejleszt\u0151k be\u00e9p\u00edtik az \u00e1tbocs\u00e1t\u00f3k\u00e9pess\u00e9g inform\u00e1ci\u00f3it, ami lehet IOPS-ban vagy byte-okban. De elfelejtik a k\u00e9sleltet\u00e9st \u00e9s a lemez eszk\u00f6z\u00f6k kihaszn\u00e1lts\u00e1g\u00e1t. Ezek sokkal fontosabb param\u00e9terek, amelyek lehet\u0151v\u00e9 teszik, hogy felm\u00e9rj\u00fck, mennyire terheltek a lemezek \u00e9s mennyire lass\u00edtanak. Ha magas a k\u00e9sleltet\u00e9s, az azt jelenti, hogy probl\u00e9m\u00e1k vannak a lemezekkel. Ha magas a kihaszn\u00e1lts\u00e1g, akkor pedig azt, hogy a lemezek nem b\u00edrj\u00e1k a terhel\u00e9st.<\/strong> Ezek jobb min\u0151s\u00e9g\u0171 jellemz\u0151k, mint az \u00e1tbocs\u00e1t\u00f3k\u00e9pess\u00e9g.<\/p>\n

<\/p>\n

B\u00e1r ezt a statisztik\u00e1t a f\u00e1jlrendszerb\u0151l is meg lehet szerezni a \/proc \u00fatvonalon, ahogyan a processzorok kihaszn\u00e1lts\u00e1g\u00e1t is m\u00e9rik. Mi\u00e9rt nem adj\u00e1k hozz\u00e1 ezeket az inform\u00e1ci\u00f3kat a fel\u00fcgyeleti rendszerekhez, azt nem tudom. De mindenesetre fontos, hogy ez is r\u00e9sze legyen a fel\u00fcgyeletnek.<\/strong> <\/p>\n

<\/p>\n

Ugyanez vonatkozik a h\u00e1l\u00f3zati interf\u00e9szekre is. Van inform\u00e1ci\u00f3 a h\u00e1l\u00f3zat \u00e1tbocs\u00e1t\u00f3k\u00e9pess\u00e9g\u00e9r\u0151l csomagokban, byte-okban, de az zavar\u00f3, hogy nincs inform\u00e1ci\u00f3 a k\u00e9sleltet\u00e9sr\u0151l \u00e9s nincs inform\u00e1ci\u00f3 a kihaszn\u00e1lts\u00e1gr\u00f3l, pedig ez hasznos inform\u00e1ci\u00f3 lenne.<\/strong> <\/p>\n

<\/p>\n

\"A<\/p>\n

<\/p>\n

B\u00e1rmelyik fel\u00fcgyeleti rendszernek vannak h\u00e1tr\u00e1nyai. B\u00e1rmilyen fel\u00fcgyeleti rendszert is n\u00e9z\u00fcnk, az mindig nem felel meg valamilyen krit\u00e9riumnak. De mindenesetre fejl\u0151dnek, \u00faj funkci\u00f3k, \u00faj dolgok ker\u00fclnek bevezet\u00e9sre, ez\u00e9rt v\u00e1lasszon valamit, \u00e9s fejlessze tov\u00e1bb. <\/p>\n

<\/p>\n

\u00c9s ahhoz, hogy fejleszthess\u00fcnk, mindig tudni kell, hogy mit jelentenek a statisztik\u00e1k, \u00e9s hogyan seg\u00edthetnek a probl\u00e9m\u00e1k megold\u00e1s\u00e1ban. <\/p>\n

<\/p>\n

\u00c9s n\u00e9h\u00e1ny kulcsfontoss\u00e1g\u00fa pont:<\/p>\n

<\/p>\n