Javaslom, hogy olvassa el Andrey Salnikov 2016 eleji jelentésének átiratát: „Tipikus hibák az alkalmazásokban, amelyek felfúvódáshoz vezetnek a postgresql-ben”
Ebben a jelentésben elemzem az alkalmazások főbb hibáit, amelyek az alkalmazáskód tervezésének és írásának szakaszában merülnek fel. És csak azokat a hibákat veszem figyelembe, amelyek a Postgresql felfúvódásához vezetnek. Általában ez a kezdete a rendszer egészének teljesítménye végének, bár kezdetben ennek semmilyen előfeltétele nem volt látható.
Örömmel üdvözlök mindenkit! Ez a jelentés nem annyira technikai jellegű, mint kollégám előző jelentése. Ez a jelentés elsősorban a háttérrendszer-fejlesztőknek szól, mivel meglehetősen nagy számú ügyfelünk van. És mindannyian ugyanazokat a hibákat követik el. Mesélek róluk. Elmagyarázom, milyen végzetes és rossz dolgokhoz vezetnek ezek a hibák.
Miért követnek el hibákat? Két okból készülnek: véletlenszerűen, talán sikerülni fog, és azért, mert nem ismerik azokat a mechanizmusokat, amelyek az adatbázis és az alkalmazás közötti szinten, valamint magában az adatbázisban fordulnak elő.
Mondok három példát szörnyű képekkel, hogy milyen rosszra fordultak a dolgok. Röviden elmondom az ott előforduló mechanizmust. És hogyan kezeljük őket, mikor történtek, és milyen megelőző módszereket alkalmazzunk a hibák megelőzésére. Mesélek a segédeszközökről, és hasznos linkeket adok.
Egy teszt adatbázist használtam, ahol két táblám volt. Az egyik tábla ügyfélszámlákkal, a másik az ezeken a számlákon végrehajtott tranzakciókkal. És bizonyos gyakorisággal frissítjük ezeken a számlákon az egyenleget.
A lemez kezdeti adatai: elég kicsi, 2 MB. Az adatbázis és kifejezetten a jel válaszideje is nagyon jó. És meglehetősen jó terhelés - 2 művelet másodpercenként a lemez szerint.
Ezen a jelentésen keresztül grafikonokat fogok mutatni, hogy világosan megérthesd, mi történik. Mindig lesz 2 dia grafikonnal. Az első dia az, ami általában a szerveren történik.
És ebben a helyzetben azt látjuk, hogy valóban van egy kis jelünk. Az index kicsi, 2 MB. Ez az első grafikon a bal oldalon.
A szerver átlagos válaszideje is stabil és rövid. Ez a jobb felső grafikon.
A bal alsó grafikon a leghosszabb tranzakciókat mutatja. Látjuk, hogy a tranzakciók gyorsan lezajlanak. És az autovákuum itt még nem működik, mert ez egy start teszt volt. Továbbra is működik, és hasznos lesz számunkra.
A második tárgyat mindig a vizsgált lemeznek szentelik. Ebben a helyzetben folyamatosan frissítjük az ügyfél számlaegyenlegét. És azt látjuk, hogy a frissítési művelet átlagos válaszideje meglehetősen jó, kevesebb mint egy ezredmásodperc. Azt látjuk, hogy a processzor erőforrásait (ez a jobb felső grafikon) szintén egyenletesen és meglehetősen kicsiben fogyasztják.
A jobb alsó grafikonon látható, hogy mennyi üzemi és lemezmemórián megyünk keresztül, hogy megkeressük a kívánt sort a frissítés előtt. Az előjel szerinti műveletek száma pedig 2 másodpercenként, ahogy az elején mondtam.
És most tragédia van. Valamilyen oknál fogva van egy rég elfeledett tranzakció. Az okok általában banálisak:
- Az egyik leggyakoribb az, hogy az alkalmazás kódjában kezdtünk hozzáférni egy külső szolgáltatáshoz. És ez a szolgáltatás nem válaszol nekünk. Vagyis megnyitottunk egy tranzakciót, megváltoztattuk az adatbázist, és az alkalmazásból levelek olvasására vagy az infrastruktúránkon belüli másik szolgáltatásra váltottunk, és az valamilyen oknál fogva nem válaszol nekünk. A munkamenetünk pedig olyan állapotban ragadt, hogy nem tudni, mikor oldják meg.
- A második helyzet az, amikor valamilyen okból kivétel történt a kódunkban. A kivételnél pedig nem dolgoztuk fel a tranzakció lezárását. És végül egy függő munkamenetben zártunk egy nyitott tranzakcióval.
- És az utolsó is elég gyakori eset. Ez gyenge minőségű kód. Egyes keretrendszerek tranzakciót nyitnak. Lefagy, és előfordulhat, hogy nem tudja az alkalmazásban, hogy lóg.
Hová vezetnek az ilyen dolgok?
Odáig, hogy a táblázataink és indexeink drámaian megduzzadnak. Ez pontosan ugyanaz a puffadás hatás. Az adatbázis számára ez azt jelenti, hogy az adatbázis válaszideje nagyon meredeken növekszik, és megnő az adatbázis-kiszolgáló terhelése. Ennek eredményeként az alkalmazásunk szenvedni fog. Mert ha 10 ezredmásodpercet töltött a kódjában egy adatbázis kérésére, 10 ezredmásodpercet pedig a logikára, akkor a függvény 20 ezredmásodpercbe telt. És most teljesen szomorú lesz a helyzeted.
És lássuk, mi történik. A bal alsó grafikon azt mutatja, hogy hosszú, hosszú tranzakciónk van. És ha megnézzük a bal felső grafikont, azt látjuk, hogy a táblázatunk mérete hirtelen két megabájtról 300 megabájtra ugrott. Ugyanakkor a táblázatban szereplő adatok mennyisége nem változott, vagyis elég nagy mennyiségű szemét van ott.
A szerver átlagos válaszidejével kapcsolatos általános helyzet is több nagyságrenddel változott. Vagyis a szerveren lévő összes kérés teljesen leesett. Ezzel párhuzamosan pedig beindultak a belső Postgres folyamatok autovákuum formájában, amelyek próbálnak tenni valamit és erőforrásokat fogyasztanak.
Mi történik a jelünkkel? Ugyanaz. Az előjel szerinti átlagos válaszidőnk több nagyságrenddel feljebb ugrott. Konkrétan az elhasznált erőforrások tekintetében azt látjuk, hogy a processzor terhelése nagyon megnőtt. Ez a jobb felső grafikon. És ez nőtt, mert a processzornak sok haszontalan sort kell rendeznie, hogy megtalálja a szükségeset. Ez a jobb alsó grafikon. Ennek eredményeként a másodpercenkénti hívásaink száma nagyon jelentősen csökkenni kezdett, mivel az adatbázisnak nem volt ideje ugyanannyi kérést feldolgozni.
Vissza kell térnünk az életbe. Felmegyünk az internetre, és rájövünk, hogy a hosszú tranzakciók problémákhoz vezetnek. Megtaláljuk és megöljük ezt a tranzakciót. És nálunk minden normálissá válik. Minden úgy működik, ahogy kell.
Megnyugodtunk, de egy idő után kezdjük észrevenni, hogy az alkalmazás nem úgy működik, mint a vészhelyzet előtt. A kérések feldolgozása továbbra is lassabban történik, és lényegesen lassabban. Másfél-kétszer lassabb konkrétan az én példámban. A szerver terhelése is nagyobb, mint a baleset előtt volt.
És a kérdés: "Mi történik ebben a pillanatban a bázissal?" És a következő helyzet fordul elő az alappal. A tranzakciós diagramon látható, hogy leállt, és tényleg nincsenek hosszú távú tranzakciók. De a tábla mérete végzetesen megnőtt a baleset során. És azóta sem csökkentek. A bázison töltött átlagos idő stabilizálódott. És úgy tűnik, hogy a válaszok megfelelő sebességgel, számunkra elfogadható sebességgel érkeznek. Az autovákuum aktívabbá vált, és elkezdett valamit kezdeni a jellel, mert több adatot kell átszűrnie.
Konkrétan a számlákkal ellátott teszttábla szerint, ahol egyenlegeket változtatunk: úgy tűnik, hogy a kérések válaszideje normalizálódott. A valóságban azonban másfélszer magasabb.
A processzor terheléséből pedig azt látjuk, hogy a processzor terhelése nem tért vissza a szükséges értékre az összeomlás előtt. Az okok pedig pontosan a jobb alsó grafikonon vannak. Látható, hogy egy bizonyos mennyiségű memóriát keresnek ott. Vagyis a keresett sor megtalálásához az adatbázisszerver erőforrásait pazaroljuk, miközben a haszontalan adatokat válogatjuk össze. A másodpercenkénti tranzakciók száma stabilizálódott.
Összességében jó, de a helyzet rosszabb, mint volt. Világos adatbázis-romlás az adatbázissal működő alkalmazásunk következményeként.
És hogy megértsük, mi folyik ott, ha nem az előző jelentésnél, akkor most lássunk egy kis elméletet. Elmélet a belső folyamatról. Miért az autóporszívó és mit csinál?
Szó szerint röviden a megértés kedvéért. Valamikor van egy asztalunk. Vannak soraink a táblázatban. Ezek a vonalak lehetnek aktívak, élők, és amire most szükségünk van. A képen zölddel vannak jelölve. És vannak már kidolgozott, frissített határidős sorok, és új bejegyzések jelentek meg rajtuk. És meg vannak jelölve, hogy már nem érdekesek az adatbázis számára. De egy Postgres funkció miatt benne vannak a táblázatban.
Miért van szüksége autóporszívóra? Valamikor jön az autovacuum, hozzáfér az adatbázishoz, és megkérdezi: "Kérem, adja meg az adatbázisban jelenleg nyitva lévő legrégebbi tranzakció azonosítóját." Az adatbázis ezt az azonosítót adja vissza. Az autovákuum pedig erre támaszkodva rendezi a táblázat sorait. Ha pedig azt látja, hogy egyes sorokat jóval régebbi tranzakciók változtattak meg, akkor jogában áll azokat sorokként megjelölni, amelyeket új adatok beírásával a jövőben újra felhasználhatunk. Ez egy háttérfolyamat.
Jelenleg továbbra is dolgozunk az adatbázissal, és folytatunk néhány változtatást a táblán. És ezekre a sorokra, amelyeket újra felhasználhatunk, új adatokat írunk. És így egy ciklust kapunk, azaz állandóan holt régi sorok jelennek meg ott, helyettük új sorokat írunk fel, amelyekre szükségünk van. És ez egy normális állapot a PostgreSQL működéséhez.
Mi történt a baleset során? Hogyan zajlott ez a folyamat ott?
Volt egy táblánk bizonyos állapotban, néhány élő, néhány halott vonal. Megérkezett az autóporszívó. Megkérdezte az adatbázist, hogy mi a legrégebbi tranzakciónk és mi az azonosítója. Megkaptam ezt az azonosítót, ami sok órával ezelőtt, talán tíz perce lehetett. Attól függ, hogy mekkora terhelés nehezedik az adatbázisra. És keresett olyan sorokat, amelyeket újrafelhasználtként megjelölhetett. És nem találtam ilyen sorokat a táblázatunkban.
De ebben az időben továbbra is az asztallal dolgozunk. Csinálunk benne valamit, frissítjük, módosítjuk az adatokat. Mit kell tennie az adatbázisnak ilyenkor? Nincs más választása, mint új sorokat hozzáadni a meglévő táblázat végéhez. És így az asztalunk mérete duzzadni kezd.
A valóságban zöld vonalakra van szükségünk a működéshez. De egy ilyen probléma során kiderül, hogy a zöld vonalak százalékos aránya rendkívül alacsony az egész táblázatban.
És amikor végrehajtunk egy lekérdezést, az adatbázisnak végig kell mennie az összes soron: piroson és zölden is, hogy megtalálja a kívánt sort. A haszontalan adatokkal való táblázat felduzzasztásának hatását pedig „felfújásnak” nevezzük, ami a lemezterületünket is felemészti. Emlékszel, 2 MB volt, 300 MB lett? Most módosítsa a megabájtokat gigabájtokra, és gyorsan elveszíti az összes lemezerőforrást.
Milyen következményekkel járhat ez számunkra?
- Az én példámban a táblázat és az index 150-szeresére nőtt. Néhány ügyfelünknek több végzetes eset is volt, amikor egyszerűen kezdett kifogyni a lemezterületük.
- Maga az asztalok mérete soha nem fog csökkenni. Az autovákuum bizonyos esetekben levághatja az asztal végét, ha csak holtvonalak vannak. De mivel állandó a forgás, előfordulhat, hogy egy zöld vonal lefagy a végén, és nem frissül, míg az összes többi valahol a tábla elejére lesz írva. De ez olyan valószínűtlen esemény, hogy az asztal mérete csökkenni fog, ezért ne reménykedjen benne.
- Az adatbázisnak egy csomó haszontalan sort kell rendeznie. És pazaroljuk a lemez erőforrásokat, pazaroljuk a processzor erőforrásokat és az elektromosságot.
- Ez pedig közvetlenül érinti az alkalmazásunkat, mert ha az elején 10 ezredmásodpercet fordítottunk a kérésre, 10 ezredmásodpercet a kódunkra, akkor az összeomlás során egy másodpercet kezdtünk a kérésre és 10 ezredmásodpercet a kódra, vagyis egy nagyságrendet. az alkalmazás teljesítményének nagysága csökkent. És amikor a baleset megoldódott, 20 ezredmásodpercet kezdtünk tölteni egy kéréssel, 10 ezredmásodpercet pedig egy kóddal. Ez azt jelenti, hogy még mindig másfélszeresére csökkent a termelékenység. És mindez egy tranzakciónak köszönhető, amely befagyott, talán a mi hibánkból.
- És a kérdés: „Hogyan kaphatunk vissza mindent?”, hogy minden rendben legyen velünk, és a kérések olyan gyorsan érkezzenek, mint a baleset előtt.
Ebből a célból egy bizonyos munkaciklust kell végrehajtani.
Először meg kell találnunk a problémás táblákat, amelyek dagadtak. Megértjük, hogy egyes táblázatokban a felvétel aktívabb, máshol kevésbé aktív. És ehhez a kiterjesztést használjuk . A bővítmény telepítésével olyan lekérdezéseket írhat, amelyek segítenek megtalálni a meglehetősen dagadt táblázatokat.
Miután megtalálta ezeket a táblázatokat, tömörítenie kell őket. Erre már vannak eszközök. Cégünkben három eszközt használunk. Az első a beépített VACUUM FULL. Kegyetlen, durva és könyörtelen, de néha nagyon hasznos. и - Ezek harmadik féltől származó segédprogramok a táblák tömörítésére. És óvatosabban kezelik az adatbázist.
Attól függően használják őket, hogy mi a kényelmesebb az Ön számára. De erről a legvégén mesélek. A lényeg az, hogy három eszköz van. Van miből válogatni.
Miután mindent kijavítottunk és megbizonyosodtunk arról, hogy minden rendben van, tudnunk kell, hogyan előzhetjük meg ezt a helyzetet a jövőben:
- Elég könnyen megelőzhető. Figyelnie kell a munkamenetek időtartamát a főkiszolgálón. Különösen veszélyes munkamenetek tétlen tranzakciós állapotban. Ők azok, akik most nyitottak egy tranzakciót, csináltak valamit, és elmentek, vagy egyszerűen lefagytak, elvesztek a kódban.
- És Önnek, mint fejlesztőnek fontos, hogy tesztelje a kódot, amikor ilyen helyzetek merülnek fel. Nem nehéz megtenni. Ez hasznos ellenőrzés lesz. Elkerülheti a hosszú tranzakciókhoz kapcsolódó „gyerekes” problémák nagy számát.
Ezekben a grafikonokban azt szerettem volna bemutatni, hogyan változott az előjel és az adatbázis viselkedése, miután ebben az esetben a VACUUM FULL-lal átmentem a jelen. Ez nekem nem produkció.
A táblázat mérete azonnal visszatért a normál, pár megabájtos működési állapotába. Ez nem befolyásolta jelentősen a szerver átlagos válaszidejét.
De kifejezetten a tesztjelünknél, ahol frissítettük a számlaegyenlegeket, azt látjuk, hogy a jelben szereplő adatok frissítésére vonatkozó kérések átlagos válaszideje a vészhelyzet előtti szintre csökkent. A processzor által a kérés teljesítéséhez felhasznált erőforrások szintén az összeomlás előtti szintre csökkentek. A jobb alsó grafikon pedig azt mutatja, hogy most pontosan azt a sort találjuk meg, amelyre szükségünk van, anélkül, hogy végigmennénk azokon a halomokban, amelyek a táblázat tömörítése előtt ott voltak. Az átlagos kérési idő pedig megközelítőleg ugyanazon a szinten maradt. De itt van egy hiba a hardveremben.
Itt ér véget az első történet. Ez a leggyakoribb. És ez mindenkivel megtörténik, függetlenül az ügyfél tapasztalatától és a programozók képzettségétől. Előbb-utóbb ez megtörténik.
A második történet, amelyben elosztjuk a terhelést és optimalizáljuk a szerver erőforrásokat
- Már felnőttünk és komoly srácok lettünk. És megértjük, hogy van egy replikánk, és jó lenne, ha egyensúlyba hoznánk a terhelést: írjunk a Mesternek, és olvassunk a replikából. És általában ez a helyzet akkor áll elő, amikor valamilyen jelentést vagy ETL-t szeretnénk készíteni. És ennek nagyon örül az üzlet. Nagyon sokféle jelentést szeretne, sok összetett elemzéssel.
- A jelentések elkészítése sok órát vesz igénybe, mivel az összetett elemzéseket nem lehet ezredmásodpercben kiszámítani. Mi, mint a bátor srácok, kódot írunk. A beillesztő alkalmazásban a Master-en készítjük el a felvételt, és a replikán hajtjuk végre a jelentéseket.
- A terhelés elosztása.
- Minden tökéletesen működik. Szuperek vagyunk.
És hogy néz ki ez a helyzet? Konkrétan ezeken a grafikonokon a replikából származó tranzakciók időtartamát is hozzáadtam a tranzakció időtartamához. Az összes többi grafikon csak a főkiszolgálóra vonatkozik.
Ekkorra nőtt a jelentéstáblám. Több is van belőlük. Látjuk, hogy a szerver átlagos válaszideje stabil. Látjuk, hogy a replikán van egy régóta futó tranzakció, amely 2 órán keresztül fut. Látjuk a holtvonalakat feldolgozó autovákuum csendes működését. És minden rendben van velünk.
Konkrétan a bevizsgált tábla szerint ott folytatjuk a számlaegyenlegek frissítését. És emellett stabil válaszidőnk van a kérésekre, stabil erőforrás-felhasználásunk. Nálunk minden rendben van.
Minden rendben van addig a pillanatig, amíg ezek a jelentések nem kezdenek el újraindulni a replikációval való ütközés miatt. És rendszeres időközönként visszalőnek.
Felmegyünk az internetre, és elkezdjük olvasni, miért történik ez. És találunk megoldást.
Az első megoldás a replikációs várakozási idő növelése. Tudjuk, hogy a jelentésünk 3 óráig tart. A replikációs késleltetést 3 órára állítottuk be. Mindent elindítunk, de továbbra is problémáink vannak az időnként törölt jelentésekkel.
Azt akarjuk, hogy minden tökéletes legyen. Tovább mászunk. És találtunk egy jó beállítást az interneten - hot_standby_feedback. Kapcsoljuk be. A Hot_standby_feedback lehetővé teszi, hogy visszatartsuk az autovákuumot a Masteren. Így teljesen megszabadulunk a replikációs konfliktusoktól. És nálunk minden jól működik a jelentésekkel.
És mi történik jelenleg a Master szerverrel? És totális bajban vagyunk a Master szerverrel. Most akkor látjuk a grafikonokat, amikor mindkét beállítás engedélyezve van. És látjuk, hogy a replikánkon lévő munkamenet valahogy elkezdte befolyásolni a helyzetet a főkiszolgálón. Megvan a hatása, mert leállította az autovákuumot, ami kitisztítja a holtvonalakat. Asztalunk mérete ismét az egekbe szökött. Az átlagos lekérdezés-végrehajtási idő a teljes adatbázisban szintén az egekbe szökött. Az autoporszívók kicsit megfeszültek.
Konkrétan a tányérunkról azt látjuk, hogy a rajta lévő adatfrissítés is az egekbe ugrott. A CPU-fogyasztás hasonlóan nagymértékben nőtt. Ismét sok halott, haszontalan soron megyünk keresztül. Ennek a jelnek a válaszideje és a tranzakciók száma pedig csökkent.
Hogy fog kinézni, ha nem tudjuk, miről beszéltem korábban?
- Elkezdjük keresni a problémákat. Ha az első részben problémákba ütköztünk, tudjuk, hogy ennek oka lehet egy hosszú tranzakció, és menjünk a Mesterhez. Problémánk van a Mesterrel. Kolbász neki. Felmelegszik, terhelési átlaga száz körül van.
- Ott a kérések lassúak, de ott nem látunk hosszú távú tranzakciókat. És nem értjük, mi a baj. Nem értjük, hol nézzünk.
- Ellenőrizzük a szerver felszereltségét. Lehet, hogy a rajtaütésünk összeomlott. Lehet, hogy kiégett a memóriakártyánk. Igen, bármi megtörténhet. De nem, a szerverek újak, minden jól működik.
- Mindenki fut: rendszergazdák, fejlesztők és az igazgató. Semmi sem segít.
- És egy ponton minden hirtelen helyreáll.
Ekkor a replikánkra vonatkozó kérést feldolgoztuk és elhagytuk. Megkaptuk a jelentést. Az üzlet még mindig boldog. Amint látja, a jelünk ismét nőtt, és nem fog csökkenni. A munkameneteket tartalmazó grafikonon meghagytam egy darabot ebből a hosszú tranzakcióból egy replikából, hogy meg tudja becsülni, mennyi ideig tart a helyzet stabilizálódása.
Az ülés véget ért. És csak egy idő után jön többé-kevésbé rendben a szerver. És a főkiszolgálón lévő kérések átlagos válaszideje visszatér a normál értékre. Mert végül az autovákuumnak lehetősége van kitisztítani és kijelölni ezeket a határvonalakat. És elkezdte végezni a dolgát. És milyen gyorsan csinálja, olyan gyorsan rendbe hozzuk.
A tesztelt tablet szerint, ahol a számlaegyenlegeket frissítjük, pontosan ugyanezt a képet látjuk. Az átlagos fiókfrissítési idő is fokozatosan normalizálódik. A processzor által fogyasztott erőforrások is csökkennek. A másodpercenkénti tranzakciók száma pedig visszatér a normál értékre. De ismét visszatértünk a normális kerékvágásba, nem úgy, mint a baleset előtt.
Mindenesetre teljesítménylevonást kapunk, mint az első esetben, másfél-kétszeresét, sőt néha többet is.
Úgy tűnik, mindent jól csináltunk. Ossza el a terhelést. A berendezés nem tétlen. A kéréseket a fejünk szerint felosztottuk, de így is minden rosszul alakult.
- Nincs engedélyezve a hot_standby_feedback? Igen, különösen erős indokok nélkül nem ajánlott bekapcsolni. Mert ez a csavar közvetlenül érinti a Master szervert és felfüggeszti ott az autovákuum működését. Ha engedélyezi néhány replikán, és elfelejti, megölheti a Mestert, és nagy problémákat okozhat az alkalmazással.
- A max_standby_streaming_delay növelése? Igen, a jelentések esetében ez igaz. Ha van egy háromórás jelentése, és nem szeretné, hogy a replikációs ütközések miatt összeomoljon, egyszerűen növelje a késleltetést. A hosszú távú jelentéshez soha nem szükséges olyan adat, amely éppen most érkezett az adatbázisba. Ha három órája megvan, akkor néhány régi adatperiódusra futja. És az Ön számára nem számít, hogy három vagy hat órás késés van, de folyamatosan kapja a jelentéseket, és nem lesz gond a leeséssel.
- Természetesen szabályoznia kell a replikák hosszú munkameneteit, különösen akkor, ha úgy dönt, hogy engedélyezi a hot_standby_feedback funkciót a replikán. Mert bármi megtörténhet. Ezt a replikát átadtuk a fejlesztőnek, hogy tesztelhesse a lekérdezéseket. Őrült kérést írt. Beindította és elment teát inni, és megkaptuk a bevett Mestert. Vagy rossz alkalmazást tettünk oda. A helyzetek változatosak. A replikákon végzett munkameneteket ugyanolyan gondosan kell figyelni, mint a Masteren.
- És ha gyors és hosszú lekérdezései vannak a replikákkal kapcsolatban, akkor ebben az esetben jobb, ha felosztja őket a terhelés elosztása érdekében. Ez a streaming_delay link. Gyorsak esetén egy replikával rendelkezzen kis replikációs késleltetéssel. A hosszú távú jelentési kérelmek esetén rendelkezzen olyan replikával, amely 6 órát vagy egy napot is késhet. Ez egy teljesen normális helyzet.
A következményeket ugyanúgy megszüntetjük:
- Felfújt asztalokat találunk.
- És tömörítjük a számunkra legkényelmesebb eszközzel.
A második történet itt ér véget. Térjünk át a harmadik történetre.
Szintén elég gyakori nálunk, ahol migrációt végzünk.
- Bármely szoftvertermék növekszik. Változnak a vele szemben támasztott követelmények. Mindenesetre fejlődni akarunk. És előfordul, hogy frissítenünk kell a táblázatban szereplő adatokat, nevezetesen, hogy a fejlesztésünk részeként bevezetett új funkcionalitásunk migrációja szempontjából frissítést hajtsunk végre.
- A régi adatformátum nem kielégítő. Tegyük fel, hogy most rátérünk a második táblázatra, ahol ezeken a számlákon vannak tranzakcióim. Tegyük fel, hogy rubelben voltak, és úgy döntöttünk, hogy növeljük a pontosságot, és kopejkában tesszük. Ehhez pedig egy frissítést kell végrehajtanunk: szorozzuk meg a mezőt a tranzakció összegével százzal.
- A mai világban automatizált adatbázis-verzióvezérlő eszközöket használunk. Mondjuk . Ott regisztráljuk a migrációt. Tesztbázisunkon teszteljük. Minden rendben. A frissítés folyamatban van. Egy ideig blokkolja a munkát, de frissített adatokat kapunk. Ezen pedig új funkciókat indíthatunk. Mindent teszteltek és ellenőriztek. Minden beigazolódott.
- Tervezett munkákat végeztünk, migrációt végeztünk.
Itt látható a migráció az Ön előtt bemutatott frissítéssel. Mivel ezek az én számlatranzakcióim, a lemez 15 GB volt. És mivel minden sort frissítünk, a frissítéssel megdupláztuk a táblázat méretét, mert minden sort átírtunk.
Az áttelepítés során nem tudtunk mit kezdeni ezzel a lemezzel, mert az összes hozzá érkezett kérés sorban állt, és megvárták, amíg ez a frissítés befejeződik. De itt szeretném felhívni a figyelmet azokra a számokra, amelyek a függőleges tengelyen vannak. Ez azt jelenti, hogy a migráció és a processzorterhelés előtti átlagos kérési időnk körülbelül 5 milliszekundum, a lemezmemória olvasásához szükséges blokkműveletek száma kevesebb, mint 7,5.
Végrehajtottuk a migrációt, és ismét problémák adódtak.
Az áttelepítés sikeres volt, de:
- A régi funkció most tovább tart.
- Az asztal ismét megnőtt.
- A szerver terhelése ismét nagyobb lett, mint korábban.
- És persze még bütyköljük a jól működő funkcionalitást, kicsit javítottunk rajta.
És ez megint puffadás, ami megint tönkreteszi az életünket.
Itt bemutatom, hogy a táblázat az előző két esethez hasonlóan nem tér vissza a korábbi méretekre. Az átlagos szerverterhelés megfelelőnek tűnik.
Ha pedig rátérünk a számlákat tartalmazó táblázatra, látni fogjuk, hogy ennél a táblánál megduplázódott az átlagos lekérési idő. A processzor terhelése és a memóriában rendezett sorok száma 7,5 fölé ugrott, de alacsonyabb volt. A processzoroknál pedig 2-szer, blokkműveleteknél 1,5-szeresre ugrott, azaz szerverteljesítmény-romlást kaptunk. Ennek eredményeként - alkalmazásunk teljesítményének romlása. A hívások száma ugyanakkor megközelítőleg változatlan maradt.
És itt a legfontosabb az, hogy megértsük, hogyan kell helyesen végrehajtani az ilyen migrációkat. És meg kell tenni őket. Ezeket a migrációkat meglehetősen következetesen végezzük.
- Az ilyen nagy migráció nem történik meg automatikusan. Mindig ellenőrzés alatt kell lenniük.
- Hozzáértő személy felügyelete szükséges. Ha van DBA a csapatában, akkor hagyja, hogy a DBA tegye meg. Az ő dolga. Ha nem, akkor tegye meg a legtapasztaltabb ember, aki tud az adatbázisokkal dolgozni.
- Egy új adatbázissémát, még ha egy oszlopot is frissítünk, mindig szakaszosan, azaz előre elkészítjük, mielőtt az alkalmazás új verziója megjelenne:
- Új mezők kerülnek hozzáadásra, amelyekben rögzítjük a frissített adatokat.
- A régi tábláról kis részletekben visszük át az adatokat az új táblára. Miért csináljuk ezt? Először is mindig mi irányítjuk ennek a folyamatnak a folyamatát. Tudjuk, hogy már annyi tételt átvittünk, és annyi van még hátra.
- A második pozitív hatás pedig az, hogy minden ilyen köteg között lezárjuk a tranzakciót, nyitunk egy újat, és ez lehetővé teszi, hogy az autovákuum a lemeznek megfelelően működjön, megjelöljük az újrahasználat határidejét.
- Az alkalmazás futása közben megjelenő sorokhoz (még a régi alkalmazás fut) adunk hozzá egy triggert, amely új értékeket ír az új mezőkbe. Esetünkben ez a régi érték százával való szorzása.
- Ha teljesen makacsok vagyunk, és ugyanazt a mezőt szeretnénk, akkor az összes migráció befejeztével és az alkalmazás új verziójának bevezetése előtt egyszerűen átnevezzük a mezőket. A régiek valamilyen kitalált nevet kapnak, az új mezőket pedig átnevezzük a régiekre.
- És csak ezután indítjuk el az alkalmazás új verzióját.
És ugyanakkor nem fogunk felpuffadni, és nem fogunk szenvedni a teljesítmény tekintetében.
Itt ér véget a harmadik történet.
És most egy kicsit részletesebben azokról az eszközökről, amelyeket a legelső történetben említettem.
A bloat keresése előtt telepítenie kell a bővítményt .
Hogy ne kelljen kérdésekkel előállnia, ezeket a lekérdezéseket már leírtuk munkánkban. Használhatod őket. Itt két kérés van.
- Az első elég sok időt vesz igénybe, de a táblázatból megmutatja a pontos felfúvódási értékeket.
- A második gyorsabban működik, és nagyon hatékony, ha gyorsan fel kell mérni, hogy a táblázat szerint van-e puffadás vagy sem. És azt is meg kell értenie, hogy a bloat mindig jelen van a Postgres táblázatban. Ez az MVCC modell egyik jellemzője.
- És a legtöbb esetben a 20%-os puffadás normális az asztaloknál. Vagyis nem kell aggódnia és tömörítenie ezt a táblázatot.
Kitaláltuk, hogyan lehet azonosítani a haszontalan adatoktól duzzadó táblákat.
Most a puffadás megszüntetéséről:
- Ha van egy kis táblagépünk és jó lemezeink, vagyis egy gigabájtig terjedő táblagépen, akkor teljesen lehetséges a VACUUM FULL használata. Elvesz tőled egy exkluzív zárat az asztalon néhány másodpercre, és oké, de mindent gyorsan és keményen fog megtenni. Mit csinál a VACUUM FULL? Egy exkluzív zárolást használ az asztalon, és átírja a régi táblák élő sorait az új táblába. És a végén lecseréli őket. Törli a régi fájlokat, és a régieket újakkal helyettesíti. De munkája idejére exkluzív zárat vesz az asztalon. Ez azt jelenti, hogy ezzel a táblával nem lehet semmit csinálni: sem írni, sem beleolvasni, sem módosítani. A VACUUM FULL pedig további lemezterületet igényel az adatok írásához.
- Következő eszköz . Elvében nagyon hasonlít a VACUUM FULL-hoz, mert a régi fájlokból is átírja az adatokat újakra és lecseréli a táblázatban. Ugyanakkor a munka kezdetén nem vesz fel kizárólagos zárat az asztalra, hanem csak abban a pillanatban, amikor már kész adatokkal rendelkezik a fájlok cseréje érdekében. A lemez erőforrásigénye hasonló a VACUUM FULL követelményeihez. További lemezterületre van szüksége, és ez néha kritikus, ha terabájtos táblái vannak. És eléggé processzoréhes, mert aktívan működik I/O-val.
- A harmadik segédprogram az . Óvatosabb az erőforrásokkal, mert kissé eltérő elvek szerint működik. A pgcompacttable fő ötlete az, hogy az összes élő sort a táblázat elejére helyezi a táblázat frissítéseinek segítségével. És akkor vákuumot vezet ezen az asztalon, mert tudjuk, hogy élõ soraink vannak az elején és holt soraink a végén. A vákuum pedig maga vágja le ezt a farkát, vagyis nem igényel sok további lemezterületet. És ugyanakkor még mindig meg lehet szorítani a forrásokat.
Mindent eszközökkel.
Ha érdekesnek találja a felfúvódott témát a belső elmélyülés szempontjából, íme néhány hasznos link:
- - Ez a kollégám jelentése. Általánosságban szól arról, hogy hová jut Postgres tere munkája és élete során. És van egy nagyon nagy és részletes technikai cikk az adatbázis-adminisztrátorok számára a felfúvódásról.
- – ez egy link a tárhelyünkre, ahol egy csomó hasznos szkriptet tárolunk az adatbázis állapotának ellenőrzéséhez. Ott találsz szkripteket a bloat kereséséhez.
- и linkek olyan eszközökhöz, amelyek segítenek a jelek zsugorításában.
- – ez kollégám bejegyzése. Ott elég komolyan és technikailag részletesen elemzi a bloat-ot adminisztrátorokhoz közeli szinten.
Igyekeztem inkább egy horror történetet bemutatni a fejlesztőknek, mert ők az adatbázisok közvetlen ügyfelei, és meg kell érteniük, hogy mire és milyen cselekvések vezetnek. Remélem sikerült. Köszönöm a figyelmet!
kérdések
Köszönjük a beszámolót! Arról beszélt, hogyan azonosíthatja a problémákat. Hogyan lehet őket figyelmeztetni? Vagyis volt olyan helyzetem, hogy a kérések nem csak azért lógtak le, mert valamilyen külső szolgáltatáshoz fértek hozzá. Ezek csak vad csatlakozások voltak. Volt néhány apró, ártalmatlan kérés, amelyek egy napig lógtak, aztán elkezdtek hülyeségeket csinálni. Vagyis nagyon hasonló ahhoz, amit leírtál. Hogyan lehet ezt követni? Ülni és folyamatosan figyelni, melyik kérés akadt el? Hogyan lehet ezt megakadályozni?
Ebben az esetben ez a cége rendszergazdáinak feladata, nem feltétlenül a DBA-nak.
Rendszergazda vagyok.
A PostgreSQL-nek van egy pg_stat_activity nevű nézete, amely függő lekérdezéseket jelenít meg. És láthatod, meddig lóg ott.
5 percenként be kell jönnöm megnézni?
Állítsa be a cront és ellenőrizze. Ha hosszú távú kérésed van, írj egy levelet és ennyi. Vagyis nem kell a szemeddel nézned, automatizálható. Levelet kapsz, reagálsz rá. Vagy lőhet automatikusan.
Vannak nyilvánvaló okai, hogy ez miért történik?
Felsoroltam néhányat. További összetettebb példák. És még sokáig lehet beszélgetni.
Köszönöm a beszámolót! Szeretném tisztázni a pg_repack segédprogramot. Ha nem csinál exkluzív zárat, akkor...
Exkluzív zárat csinál.
... akkor potenciálisan elveszíthetem az adatokat. Az alkalmazásom nem rögzít semmit ezalatt az idő alatt?
Nem, simán működik a táblával, azaz a pg_repack először átviszi az összes létező élő sort. Természetesen ott történik valamiféle belépés a táblázatba. Csak kidobja ezt a lófarkat.
Vagyis végül tényleg megcsinálja?
A végén exkluzív zárat vesz igénybe, hogy felcserélje ezeket a fájlokat.
Gyorsabb lesz, mint a VACUUM FULL?
A VACUUM FULL, amint elindult, azonnal exkluzív zárat kapott. És amíg mindent meg nem tesz, nem engedi el. És a pg_repack csak a fájlcsere idején kap kizárólagos zárolást. Ebben a pillanatban nem fog oda írni, de az adatok nem vesznek el, minden rendben lesz.
Helló! Ön egy autóporszívó működéséről beszélt. Volt egy grafikon piros, sárga és zöld cellákkal. Azaz sárgák – jelölte töröltnek. És ennek eredményeként valami újat lehet beléjük írni?
Igen. A Postgres nem törli a sorokat. Olyan sajátossága van. Ha frissítettünk egy sort, a régit töröltként jelöltük meg. Ott megjelenik annak a tranzakciónak az azonosítója, amely ezt a sort megváltoztatta, és írunk egy új sort. És vannak olyan munkameneteink, amelyek esetleg elolvashatják őket. Valamikor nagyon megöregednek. Az autovákuum működésének pedig az a lényege, hogy átmegy ezeken a vonalakon, és szükségtelennek jelöli meg őket. És ott lehet adatokat felülírni.
Megértem. De nem erről szól a kérdés. nem fejeztem be. Tegyük fel, hogy van egy asztalunk. Változó méretű mezőkkel rendelkezik. És ha megpróbálok valami újat beilleszteni, akkor lehet, hogy egyszerűen nem fér bele a régi cellába.
Nem, mindenesetre a teljes sor frissül ott. A Postgresnek két adattárolási modellje van. Az adattípusból választ. Vannak közvetlenül a táblázatban tárolt adatok, és vannak tos adatok is. Ezek nagy mennyiségű adat: szöveg, json. Külön tányérokban tárolják. És ezek szerint a tabletták szerint ugyanaz a sztori a puffadással, vagyis minden ugyanaz. Csak külön vannak felsorolva.
Köszönöm a beszámolót! Elfogadható-e az utasítás időtúllépésére vonatkozó lekérdezések használata az időtartam korlátozására?
Nagyon elfogadható. Mindenhol ezt használjuk. És mivel nincs saját szolgáltatásunk, távtámogatást nyújtunk, elég sokféle ügyfelünk van. És ezzel mindenki teljesen elégedett. Vagyis vannak cron munkáink, amelyek ellenőrzik. A foglalkozások időtartamát egyszerűen egyeztetjük az ügyféllel, előtte nem állapodunk meg. Lehet egy perc, lehet 10 perc is. Ez az alap terhelésétől és céljától függ. De mindannyian használjuk a pg_stat_activity-t.
Köszönjük a beszámolót! Megpróbálom alkalmazni a jelentését a jelentkezéseimre. És úgy tűnik, mindenhol elindítunk egy tranzakciót, és egyértelműen mindenhol befejezzük. Ha van kivétel, akkor is előfordul a visszaállítás. És akkor elkezdtem gondolkodni. Végül is előfordulhat, hogy a tranzakció nem indul kifejezetten. Ez valószínűleg egy tipp a lánynak. Ha csak frissítek egy rekordot, a tranzakció elindul a PostgreSQL-ben, és csak akkor fejeződik be, ha a kapcsolat megszakad?
Ha most az alkalmazásszintről beszél, akkor ez a használt illesztőprogramtól, a használt ORM-től függ. Nagyon sok beállítás van ott. Ha engedélyezve van az automatikus véglegesítés, akkor a tranzakció ott kezdődik és azonnal bezárul.
Vagyis frissítés után azonnal bezár?
A beállításoktól függ. Neveztem egy beállítást. Ez az automatikus véglegesítés. Elég gyakori. Ha engedélyezve van, akkor a tranzakció megnyílt és bezárult. Hacsak nem kifejezetten azt mondta, hogy „tranzakció indítása” és „tranzakció befejezése”, hanem egyszerűen elindított egy kérést a munkamenetbe.
Helló! Köszönjük a beszámolót! Képzeljük el, hogy van egy adatbázisunk, amely megduzzad és megduzzad, majd elfogy a hely a szerveren. Létezik valamilyen eszköz a helyzet orvoslására?
A szerveren lévő helyet megfelelően figyelni kell.
Például a DBA elment teázni, üdülőhelyen volt stb.
A fájlrendszer létrehozásakor legalább valamilyen biztonsági mentési terület jön létre, ahol nem írnak adatokat.
Mi van, ha teljesen nulla alatt van?
Ott fenntartott területnek hívják, azaz fel lehet szabadítani és attól függően, hogy mekkora lett, kapsz szabad helyet. Alapesetben nem tudom hányan vannak. Egy másik esetben pedig szállítson lemezeket, hogy legyen helye a rekonstrukciós művelet végrehajtására. Törölhet néhány táblázatot, amelyre garantáltan nem lesz szüksége.
Vannak más eszközök?
Mindig kézzel készült. Helyben pedig világossá válik, hogy mit érdemes ott csinálni, mert egyes adatok kritikusak, mások pedig nem. Az egyes adatbázisok és az azzal működő alkalmazások esetében pedig az üzlettől függ. Ez mindig helyben dől el.
Köszönjük a beszámolót! Két kérdésem van. Először olyan diákat mutatott be, amelyek azt mutatták, hogy amikor a tranzakciók elakadnak, a táblaterület mérete és az index mérete is nő. És tovább a jelentésben volt egy csomó segédprogram, amely csomagolja a táblagépet. Mi van az indexszel?
Be is csomagolják őket.
De a vákuum nem befolyásolja az indexet?
Vannak, akik indexszel dolgoznak. Például pg_rapack, pgcompacttable. A vákuum újrateremti az indexeket és hatással van rájuk. A VACUUM FULL-lal az az ötlet, hogy mindent felülírjunk, azaz mindenkivel működik.
És a második kérdés. Nem értem, hogy a replikákról szóló jelentések miért függnek annyira magától a replikációtól. Nekem úgy tűnt, hogy a jelentéseket olvassák, a replikációt pedig írják.
Mi okoz replikációs konfliktust? Van egy Mesterünk, amelyen a folyamatok zajlanak. Autóporszívónk van. Mit csinál valójában egy autovákuum? Kivág néhány régi sort. Ha ebben az időben van egy kérésünk a replikán, amely ezeket a régi sorokat olvassa, és a Mesteren olyan helyzet állt elő, hogy az autovákuum ezeket a sorokat jelölte felülírásra, akkor felülírtuk őket. És kaptunk egy adatcsomagot, amikor át kell írnunk azokat a sorokat, amelyekre a kérésnek szüksége van a replikán, a replikációs folyamat megvárja az Ön által beállított időtúllépést. És akkor a PostgreSQL eldönti, mi a fontosabb számára. És a replikáció fontosabb számára, mint a kérés, és le fogja lőni a kérést, hogy végrehajtsa ezeket a változtatásokat a replikán.
Andrey, lenne egy kérdésem. Ezek a csodálatos grafikonok, amiket az előadás során mutattál, ezek valamiféle segédprogramod munkájának eredményei? Hogyan készültek a grafikonok?
Ez egy szolgáltatás .
Ez kereskedelmi termék?
Igen. Ez egy kereskedelmi termék.
Forrás: will.com