Navrhuji přečíst přepis zprávy ze začátku roku 2016 od Andrey Salnikova „Typické chyby v aplikacích, které vedou k nadýmání v postgresql“
V této zprávě budu analyzovat hlavní chyby v aplikacích, které se vyskytují ve fázi návrhu a psaní kódu aplikace. A vezmu jen ty chyby, které vedou k nadýmání v Postgresql. Zpravidla se jedná o začátek konce výkonu vašeho systému jako celku, ačkoli zpočátku pro to nebyly vidět žádné předpoklady.
Rádi přivítáme všechny! Tato zpráva není tak technická jako předchozí od mého kolegy. Tato přednáška je zaměřena na vývojáře back-endových systémů především proto, že máme poměrně velký počet klientů. A všichni dělají stejné chyby. Řeknu vám o nich. Vysvětlím, k čemu fatální a špatné tyto chyby vedou.
Proč se dělají chyby? Provádějí se ze dvou důvodů: namátkou to možná půjde z neznalosti některých mechanismů, které se vyskytují na úrovni mezi základnou a aplikací a také v základně samotné.
Dám vám tři příklady s hroznými obrázky toho, jak se věci zhoršily. Stručně popíšu mechanismus, který se tam vyskytuje. A jak se s nimi vypořádat, kdy k nim došlo a jaké preventivní metody použít, abychom chybám předešli. Řeknu vám o pomocných nástrojích a dám užitečné odkazy.
Použil jsem testovací databázi, kde jsem měl dvě tabulky. Jedna deska s účty zákazníků, druhá s operacemi na těchto účtech. A s určitou periodicitou aktualizujeme zůstatky na těchto účtech.
Počáteční údaje desky: je poměrně malá, 2 MB. Doba odezvy pro databázi a konkrétně pro desku je také velmi dobrá. A docela dobrá zátěž – 2 operací za vteřinu na talíři.
A prostřednictvím této zprávy vám ukážu grafy, aby bylo jasné, co se děje. Vždy budou 2 snímky s grafy. První snímek je to, co se obecně děje na serveru.
A v této situaci vidíme, že máme opravdu malý talíř. Index je malý na 2 MB. Toto je první graf vlevo.
Průměrná doba odezvy na serveru je také stabilní, malá. Toto je graf vpravo nahoře.
V levém dolním grafu jsou nejdelší transakce. Vidíme, že transakce jsou rychle dokončeny. A autovakuum tady ještě nefunguje, protože - to byl start-test. Pak to bude fungovat a bude nám to k užitku.
Druhý snímek bude vždy věnován testovací destičce. V této situaci neustále aktualizujeme zůstatky na účtu klienta. A vidíme, že průměrná doba odezvy na operaci aktualizace je docela dobrá, méně než milisekunda. Vidíme, že zdroje procesoru (toto je graf vpravo nahoře) jsou také spotřebovávány rovnoměrně a docela malé.
Pravý dolní graf ukazuje, kolik operační a diskové paměti projdeme při hledání požadovaného řádku před jeho aktualizací. A počet operací na plotně je 2 za vteřinu, jak jsem řekl na začátku.
A teď tu máme tragédii. Z nějakého důvodu dojde k dlouho zapomenuté transakci. Důvody jsou obvykle všechny banální:
- Jedním z nejčastějších je, že jsme v kódu aplikace začali přistupovat k externí službě. A tato služba nám neodpovídá. To znamená, že jsme otevřeli transakci, provedli změnu v databázi a přešli z aplikace na čtení pošty nebo na jinou službu v rámci naší infrastruktury a ta nám z nějakého důvodu neodpovídá. A naše relace visela ve stavu – neví se, kdy se to vyřeší.
- Druhá situace je, když se v našem kódu z nějakého důvodu vyskytla výjimka. A uzavření transakce jsme ve výjimce nezpracovali. A dostali jsme relaci s otevřenou transakcí.
- A ten poslední je také docela běžný. Toto je nekvalitní kód. Některé rámce otevírají transakci. Visí a možná v aplikaci nepoznáte, že ho máte pověšený.
Kam takové věci vedou?
Na to, že naše tabulky a indexy začínají dramaticky bobtnat. To je přesně stejný efekt nadýmání. U databáze se to projeví tak, že se velmi prudce prodlouží doba odezvy databáze, zvýší se zatížení databázového serveru. A v důsledku toho naše aplikace utrpí. Protože pokud jste ve svém kódu strávili 10 milisekund na požadavku do databáze, 10 milisekund na vaší logice, pak vaše funkce pracovala 20 milisekund. A nyní bude vaše situace velmi smutná.
A uvidíme, co se stane. Levý dolní graf ukazuje, že máme dlouhou dlouhou transakci. A když se podíváme na levý horní graf, vidíme, že velikost tabulky vyskočila ze dvou megabajtů na 300 megabajtů. Zároveň se množství dat v tabulce nezměnilo, to znamená, že je zde poměrně velké množství odpadků.
Celková situace z hlediska průměrné doby odezvy serveru se také změnila o několik řádů. To znamená, že všechny požadavky na serveru začaly úplně klesat. A zároveň se rozběhly interní procesy Postgres tváří v tvář autovakuu, které se snaží něco dělat a spotřebovávají zdroje.
Co se stane s naším talířem? Stejný. Průměrná doba odezvy na tabletu vyskočila o několik řádů. Pokud konkrétně z hlediska spotřebovaných zdrojů, pak vidíme, že zatížení procesoru se výrazně zvýšilo. Toto je graf vpravo nahoře. A zvýšil se, protože procesor musí projít hromadou zbytečných řádků při hledání toho, co potřebujete. Toto je graf vpravo dole. A v důsledku toho začal velmi klesat počet hovorů za sekundu, protože databáze nestíhá zpracovávat stejný počet požadavků.
Musíme se vrátit k životu. Lezeme na internet a zjišťujeme, že dlouhé transakce vedou k problému. Najdeme a zabijeme tuto transakci. A všechno se nám daří. Vše funguje jak má.
Uklidnili jsme se, ale po chvíli si začínáme všímat, že aplikace nefunguje jako před pohotovostí. Požadavky jsou zpracovávány stejně pomaleji a mnohem pomaleji. Konkrétně v mém příkladu jeden a půl až dvakrát pomalejší. Zatížení serveru je také vyšší než před nehodou.
A otázka: "Co se v tuto chvíli děje se základnou?". A se základem je následující situace. Na grafu transakcí můžete vidět, že se zastavil a skutečně neexistují žádné dlouhodobé transakce. Rozměry desky ale při nehodě fatálně narostly. A od té doby se nesnížil. Průměrná doba na základně se ustálila. A zdá se, že odpovědi jdou adekvátně s pro nás přijatelnou rychlostí. Autovakuum se zaktivizovalo a začalo s tabletem něco dělat, protože potřebuje nahodit více dat.
Konkrétně na výsledkové tabuli testu, kde měníme zůstatky: zdá se, že doba odezvy na požadavek se vrátila do normálu. Ve skutečnosti je ale jedenapůlkrát vyšší.
A podle zátěže procesoru vidíme, že se zátěž procesoru nevrátila na požadovanou hodnotu před pádem. A důvody tam leží právě v grafu vpravo dole. Je vidět, že dochází k prohledávání určitého množství paměti. To znamená, že při hledání požadovaného řádku vynakládáme prostředky databázového serveru při třídění zbytečných dat. Počet transakcí za sekundu se ustálil.
Obecně dobré, ale situace je horší, než byla. Explicitní degradace databáze v důsledku naší aplikace, která s touto databází pracuje.
A abyste pochopili, co se tam děje, pokud jste nebyli u předchozí zprávy, tak teď trochu teorie. Teorie o vnitřním procesu. Proč autovakuum a k čemu slouží?
Doslova ve zkratce pro pochopení. V určitém okamžiku máme stůl. V tabulce máme řádky. Tyto linky mohou být aktivní, živé, potřebujeme hned. Na obrázku jsou označeny zeleně. A jsou uzavírky, které už prošly, byly aktualizovány, objevily se na nich nové záznamy. A jsou označeni, že již nejsou pro databázi zajímaví. Leží ale v tabulce kvůli zvláštnostem Postgresu.
Proč potřebujete autovakuum? Autovakuum v určitém okamžiku přijde, zavolá databázi a požádá ji: "Dejte mi prosím id nejstarší transakce, která je aktuálně otevřena v databázi." Databáze vrátí toto ID. A autovakuum, spoléhající se na něj, prochází řádky v tabulce. A pokud vidí, že některé řádky byly změněny mnohem staršími transakcemi, pak má právo je označit jako řádky, které můžeme v budoucnu znovu použít tím, že tam zapíšeme nová data. Toto je proces na pozadí.
V tuto chvíli pokračujeme v práci s databází, pokračujeme v provádění některých změn v tabulce. A na tyto řádky, které můžeme znovu použít, zapisujeme nová data. A tím dostaneme cyklus, to znamená, že se tam pořád objevují nějaké mrtvé staré řádky, místo nich zapisujeme nové řádky, které potřebujeme. A to je normální stav pro fungování PostgreSQL.
Co se stalo při nehodě? Jak tento proces probíhal?
Měli jsme talíř v nějakém stavu, nějaký živý, nějaký mrtvý. Autovakuum dorazilo. Zeptal se databáze, jaká je naše nejstarší transakce, jaké je její id. Dostal jsem toto ID, které může být staré mnoho hodin, možná deset minut. Záleží na tom, jak velkou zátěž na databázi máte. A šel hledat linky, které by mohl označit jako znovupoužité. A takové řádky jsem v naší tabulce nenašel.
Ale v tuto chvíli pokračujeme v práci s tabulkou. Něco v něm děláme, aktualizujeme, měníme data. Co by měla databáze v tuto chvíli dělat? Nezbývá jí nic jiného, než přidat nové řádky na konec stávající tabulky. A tím se u nás začíná nafukovat velikost stolu.
Zelené linky opravdu potřebujeme, abychom fungovali. Ale během takového problému se ukáže, že procento zelených čar je extrémně nízké v celém objemu tabulky.
A když spustíme dotaz, databáze musí projít všechny řádky, červené i zelené, aby našla ten správný řádek. A efektu nafouknutí tabulky zbytečnými daty se říká „nadýmání“, které nám také zabírá místo na disku. Pamatujete si, že to bylo 2 MB, teď je to 300 MB? Nyní změňte megabajty na gigabajty a velmi rychle přijdete o všechny své diskové prostředky.
Jaké to má pro nás důsledky?
- V mém příkladu tabulka a index vzrostly 150krát. Někteří naši klienti měli fatálnější případy, kdy prostě začalo docházet místo na disku.
- Stoly se samy od sebe nikdy nezmenší. Autovakuum může v některých případech odříznout konec tabulky, pokud existují pouze mrtvé čáry. Ale protože se neustále střídá, jedna zelená čára může viset na konci a nebude aktualizována a všechny ostatní někde na začátku desky budou zaznamenány. Ale to je tak nepravděpodobná událost, že se váš stůl sám zmenší, takže byste v to neměli doufat.
- Databáze potřebuje protřídit celou hromadu zbytečných řádků. A plýtváme diskovými prostředky, plýtváme procesorovými prostředky a elektřinou.
- A to přímo ovlivňuje naši aplikaci, protože pokud jsme na začátku strávili 10 milisekund na požadavku, 10 milisekund na našem kódu, tak jsme během pádu začali strávit sekundu žádostí a 10 milisekund kódem, tj. velikost výkonu aplikace se snížila. A když byla nehoda vyřešena, začali jsme trávit 20 milisekund na požadavek, 10 milisekund na kód. To znamená, že jsme se výkonnostně propadli jedenapůlkrát. A to vše kvůli jedné transakci, která se zastavila a možná i naší vinou.
- A otázka: „Jak mohu dostat vše zpět?“ Aby u nás bylo vše v pořádku a požadavky běžely stejně rychle jako před nehodou.
K tomu existuje určitý cyklus práce, který se provádí.
Nejprve musíme najít problematické tabulky, které se nafoukly. Chápeme, že některé tabulky zaznamenávají aktivněji, některé méně aktivně. A k tomu používáme rozšíření . Instalací tohoto rozšíření můžete psát dotazy, které vám pomohou najít tabulky, které jsou dostatečně nafouklé.
Jakmile tyto tabulky najdete, je třeba je zkomprimovat. Nástroje na to již existují. V naší firmě používáme tři nástroje. První je vestavěný VACUUM FULL. Je krutý, drsný a nemilosrdný, ale někdy je velmi užitečný. и jsou nástroje třetích stran pro kompresi tabulek. A na databázi jsou opatrnější.
Používají se podle toho, co je pro vás výhodnější. Ale o tom budu mluvit úplně na konci. Hlavní věc je, že existují tři nástroje. Je z čeho vybírat.
Poté, co vše napravíme a ujistíme se, že je vše v pořádku, bychom měli vědět, jak této situaci v budoucnu předejít:
- Je poměrně snadné tomu zabránit. Musíte sledovat trvání relací na hlavním serveru. Zvláště nebezpečné relace ve stavu nečinnosti ve stavu transakce. To jsou ti, kteří právě otevřeli transakci, něco udělali a odešli, nebo prostě viseli, ztratili se v kódu.
- A pro vás, jako vývojáře, je důležité testovat kód v době, kdy tyto situace nastanou. Není těžké to udělat. Bude to užitečná kontrola. Vyhnete se tak spoustě „dětských“ problémů spojených s dlouhými transakcemi.
Na těchto grafech jsem vám chtěl ukázat, jak se změnila tabulka a chování databáze poté, co jsem na stole v tomto případě prošel VACUUM FULL. Tohle není moje produkce.
Velikost tabulky se okamžitě vrátila do normálního pracovního stavu několika megabajtů. Průměrnou dobu odezvy na serveru to příliš neovlivnilo.
Ale konkrétně v naší testovací tabulce, kde jsme aktualizovali zůstatky na účtech, vidíme, že průměrná doba odezvy na požadavek na aktualizaci dat v tabletu se zkrátila na úroveň před pádem. Prostředky spotřebované procesorem k provedení tohoto požadavku také klesly na úroveň před havárií. A pravý dolní graf ukazuje, že nyní najdeme přesně ten řádek, který potřebujeme hned, aniž bychom procházeli hromadou mrtvých řádků, které byly před komprimací stolu. A průměrná doba dotazování zůstala přibližně na stejné úrovni. Ale tady mám spíše chybu mého hardwaru.
Tady končí první příběh. Ona je nejčastější. A stává se to každému, bez ohledu na zkušenosti klienta, jak kvalifikovaní programátoři tam jsou. Dříve nebo později se to stane.
Druhý příběh, ve kterém rozdělujeme zátěž a optimalizujeme zdroje serveru
- Vyrostli jsme a stali se z nás vážní chlapi. A chápeme, že máme repliku a bylo by pro nás dobré vyvážit zátěž: pište Mistrovi a čtěte z repliky. A většinou tato situace nastane, když chceme připravit nějaké reporty nebo ETL. A byznys z toho má velkou radost. Opravdu chce různé sestavy se spoustou komplexních analýz.
- Přehledy trvají mnoho hodin, protože složité analýzy nelze vypočítat v milisekundách. My, jako odvážní chlapi, píšeme kód. Děláme v aplikaci insert, kterou nahráváme na Master, provádíme reporty na replice.
- Rozkládáme zátěž.
- Vše funguje perfektně. Jsme dobří.
A jak tato situace vypadá? Konkrétně na těchto grafech jsem přidal i dobu trvání transakcí z repliky po dobu trvání transakce. Všechny ostatní grafy se týkají pouze hlavního serveru.
Do této doby se moje zpravodajská tabule rozrostla. Je jich víc. Vidíme, že průměrná doba odezvy serveru je stabilní. Vidíme, že máme dlouho běžící transakci na replice, která běží 2 hodiny. Vidíme tichou práci autovakua, který zpracovává mrtvé linky. A jsme všichni dobří.
Konkrétně podle testovacího tabletu pokračujeme v aktualizaci zůstatků na tamních účtech. A také máme stabilní dobu odezvy na vyžádání, stabilní spotřebu zdrojů. U nás je vše v pořádku.
Vše je v pořádku až do okamžiku, kdy na nás tyto zprávy začnou znovu pálit o konfliktu s replikací. A v pravidelných intervalech střílejí zpět.
Jdeme online a začínáme číst, proč se to děje. A najdeme řešení.
Prvním řešením je zvýšení latence replikace. Víme, že naše zpráva běží 3 hodiny. Nastavte zpoždění replikace na 3 hodiny. Vše rozjíždíme, ale stále máme problémy s tím, že se občas ostřelují zprávy.
Chceme, aby bylo vše dokonalé. Pojďme dále. A na internetu najdeme skvělé nastavení – hot_standby_feedback. Zapneme to. Hot_standby_feedback nám umožňuje udržet autovakuum běžící na Masteru. Tím se zcela zbavíme replikačních konfliktů. A všichni dobře pracujeme s přehledy.
A co se v tuto chvíli děje s Master serverem? A s hlavním serverem máme totální katastrofu. Nyní vidíme grafy se zapnutými oběma těmito nastaveními. A vidíme, že relace na replice nějak začala ovlivňovat situaci na Master serveru. Má dopad, protože pozastavil autovakuum, které čistí mrtvé linie. Velikost našeho stolu opět raketově vzrostla. Průměrná doba provádění dotazu v celé databázi také raketově vzrostla. Autovakua trochu zpřísnily.
Konkrétně na našem talíři vidíme, že aktualizace dat na něm také vyskočila do nebe. Spotřeba procesorových zdrojů podobně výrazně vzrostla. Znovu iterujeme přes velké množství mrtvých zbytečných řádků. A doba odezvy na tomto tabletu, počet transakcí klesl.
Jak to bude vypadat, když nevíme, o čem jsem předtím mluvil?
- Začínáme hledat problémy. Pokud jsme v prvním díle narazili na problémy, víme, že to může být důvod dlouhé transakce a lezeme na Mistra. Problém je s Mistrem. Klobásy ho. Rozcvičuje se, má Load Average pod stovkou.
- Požadavky se tam zpomalí, ale žádné dlouhodobé transakce tam nevidíme. A my nerozumíme tomu, co se děje. Nevíme, kde hledat.
- Kontrola hardwaru serveru. Možná se náš nájezd zhroutil. Možná jsme spálili paměťovou lištu. Ano, všechno může být. Ale ne, servery jsou nové, vše funguje dobře.
- Všichni běží: správci, vývojáři i ředitel. Nic nepomáhá.
- A v určité chvíli se vše najednou začne samo opravovat.
Na replice v té době požadavek vyšel a odešel. Obdrželi jsme hlášení. Obchod je stále spokojený. Jak vidíte, náš stůl se opět rozrostl a zmenšovat se nebude. Na grafu s relacemi jsem nechal kousek této dlouhé transakce z repliky, abyste mohli zhodnotit, jak dlouho trvá, než se situace stabilizuje.
Sezení je pryč. A teprve po nějaké době je server víceméně v pořádku. A průměrná doba odezvy na požadavky na hlavním serveru se vrátí do normálu. Protože konečně autovakuum dostalo příležitost vyčistit, označte tyto mrtvé linie. A začal dělat svou práci. A jak rychle to udělá, tak rychle budeme v pořádku.
Na testovací tabulce, kde aktualizujeme zůstatky účtů, vidíme úplně stejný obrázek. Průměrná doba aktualizace účtu se také postupně normalizuje. Sníží se také zdroje spotřebované procesorem. A počet transakcí za sekundu se vrátil k normálu. Ale zase zpátky do normálu, ne do toho, co jsme měli před nehodou.
V každém případě se dostaneme ke snížení výkonu, jako v prvním případě, jeden a půl až dvakrát a někdy i více.
Zdá se, že jsme udělali všechno správně. Rozložte zátěž. Zařízení není nečinné. Podle mysli porušili žádosti, ale přesto vše dopadlo špatně.
- Neaktivovat hot_standby_feedback? Ano, nedoporučuje se jej zapínat bez zvlášť závažných důvodů. Protože toto zkroucení přímo ovlivňuje hlavní server a pozastavuje tam práci autovakua. Tím, že to zapnete na nějaké replice a zapomenete na to, můžete zabít Mistra a získat velké problémy s aplikací.
- Zvýšit max_standby_streaming_delay? Ano, pro přehledy ano. Pokud máte tříhodinovou zprávu a nechcete, aby se zhroutila kvůli konfliktům replikace, pak jednoduše zvyšte zpoždění. Dlouhá sestava nikdy nevyžaduje data, která vstoupila do databáze právě teď. Pokud to máte tři hodiny, tak to provozujete na nějaké staré datové období. A vy, ty tři hodiny zpoždění, to šest hodin zpoždění - nebude hrát žádnou roli, ale budete dostávat hlášení soustavně a neznáte problémy s jejich pádem.
- Přirozeně potřebujete ovládat dlouhé relace na replikách, zvláště pokud se rozhodnete povolit hot_standby_feedback na replice. Protože to může být cokoliv. Tuto poznámku jsme dali vývojáři, aby otestoval požadavky. Napsal šílenou žádost. Začal a šel pít čaj a dostali jsme zavedeného Mistra. Nebo jsme tam spustili špatnou aplikaci. Situace jsou různé. Relace na replikách je třeba kontrolovat stejně pečlivě jako na Masteru.
- A pokud máte rychlé a dlouhé dotazy na repliky, pak je v tomto případě lepší je rozdělit, aby se zátěž rozložila. Toto je odkaz na streaming_delay. Pro rychlé mít jednu repliku s malým zpožděním replikace. Pro dlouhotrvající požadavky na vytváření přehledů mějte repliku, která může zaostávat o 6 hodin o den. To je zcela normální situace.
Následky odstraňujeme stejným způsobem:
- Nacházíme nadupané stoly.
- A komprimujeme tím nejpohodlnějším nástrojem, který nám vyhovuje.
Druhý příběh zde končí. Přejděme ke třetímu příběhu.
Také pro nás zcela běžné, ve kterých provádíme migraci.
- Každý softwarový produkt roste. Požadavky se mění. V každém případě se chceme rozvíjet. A stává se, že potřebujeme aktualizovat data v tabulce, a to spustit aktualizaci z hlediska naší migrace na novou funkcionalitu, kterou implementujeme v rámci našeho vývoje.
- Starý datový formát nevyhovuje. Řekněme, že nyní přejdeme k druhé tabulce, kde mám operace s těmito účty. A řekněme, že byly v rublech, a rozhodli jsme se zvýšit přesnost a udělat to v kopejkách. A k tomu musíme provést aktualizaci: vynásobte pole s částkou operace stem.
- V dnešním světě používáme nástroje pro automatizované verzování databází. Řekněme . Registrujeme tam naši migraci. Testujeme to na naší testovací základně. Vše je v pořádku. Aktualizace běží. Bloky chvíli fungují, ale dostáváme aktualizovaná data. A v tomto můžeme spustit novou funkcionalitu. Vše otestováno a zkontrolováno. Vše potvrzeno.
- Provedl plánované práce, provedl migraci.
Zde je migrace s aktualizací, kterou máte před sebou. Jelikož mám operace na účtech, deska měla 15 GB. A protože aktualizujeme každý řádek, zdvojnásobili jsme desku aktualizací, protože jsme přepsali každý řádek.
Během migrace jsme s tímto štítkem nemohli nic dělat, protože všechny požadavky na něj byly zařazeny do fronty a čekaly na dokončení této aktualizace. Ale zde chci upozornit na čísla, která jsou na svislé ose. To znamená, že máme průměrnou dobu požadavku před migrací v oblasti 5 milisekund a zatížení procesoru, počet blokových operací pro čtení paměti disku je menší než 7,5.
Přestěhovali jsme se a znovu jsme měli problémy.
Migrace byla úspěšná, ale:
- Stará funkce začala fungovat déle.
- Stůl se opět zvětšil.
- Zatížení serveru se opět zvýšilo, než bylo.
- A samozřejmě se pořád plácáme s funkcionalitou, která fungovala dobře, trochu jsme ji vylepšili.
A to je opět nadýmání, které nám opět kazí život.
Zde demonstruji, že stůl, stejně jako předchozí dva případy, se nevrátí k předchozím velikostem. Průměrné zatížení serveru se zdá být dostatečné.
A pokud se obrátíme na tabulku s účty, pak uvidíme, že průměrná doba požadavku se u této tabulky zdvojnásobila. Zatížení procesoru a počet řádků k vytřídění v paměti vyskočil nad 7,5, ale byl nižší. A vyskočil v případě procesorů 2krát, v případě blokových operací 1,5krát, čili jsme dostali degradaci výkonu serveru. A v důsledku toho - degradace výkonu naší aplikace. Počet hovorů přitom zůstal přibližně na stejné úrovni.
A zde je hlavní věcí pochopit, jak takové migrace správně provádět. A je potřeba je udělat. Tyto migrace provádíme docela pravidelně.
- Tak velké migrace se neprovádějí automaticky. Musí být vždy kontrolovány.
- Vyžaduje dohled od znalé osoby. Pokud máte v týmu DBA, nechte to udělat DBA. Je to jeho práce. Pokud ne, tak ať to udělá nejzkušenější člověk, který umí s databázemi pracovat.
- Nové databázové schéma, i když aktualizujeme jeden sloupec, připravujeme vždy po etapách, tedy s předstihem před uvedením nové verze aplikace:
- Jsou přidána nová pole, do kterých budeme zapisovat právě aktualizované údaje.
- Data ze starého pole do nového pole přenášíme po malých částech. Proč to děláme? Za prvé, vždy kontrolujeme proces tohoto procesu. Víme, že už jsme převedli tolik šarží a tolik nám zbylo.
- A druhým pozitivním efektem je, že mezi každou takovou dávkou uzavřeme transakci, otevřeme novou, a to umožňuje, aby autovakuum fungovalo podle štítku, označovalo termíny pro opětovné použití.
- Pro řádky, které se objeví během provozu aplikace (máme ještě starou aplikaci), přidáme trigger, který zapíše nové hodnoty do nových polí. V našem případě se jedná o vynásobení staré hodnoty sto.
- Pokud jsme zcela tvrdohlaví a chceme stejné pole, pak po dokončení všech migrací a před spuštěním nové verze aplikace pole jednoduše přejmenujeme. Ta stará na nějaký vymyšlený název a nová pole přejmenujeme na stará.
- A teprve poté spustíme novou verzi aplikace.
A zároveň se nenafoukneme a nepropadneme ve výkonu.
Toto je konec třetího příběhu.
A teď trochu více o nástrojích, které jsem zmínil v úplně prvním příběhu.
Než začnete hledat nadýmání, musíte nainstalovat rozšíření .
Abyste si žádosti nevymýšleli, tyto žádosti jsme již sepsali v naší práci. Můžete je použít. Jsou zde dvě žádosti.
- První trvá poměrně dlouho, ale ukáže vám přesné hodnoty nadýmání podle tabulky.
- Druhý funguje rychleji a je velmi účinný, když potřebujete rychle vyhodnotit, zda je v tabulce nafouknutá nebo ne. A měli byste také pochopit, že stůl Postgres je vždy nafouknutý. To je vlastnost jeho modelu MVCC.
- A 20% nafouknutí je pro stoly ve většině případů v pořádku. To znamená, že byste se neměli obávat a komprimovat tuto tabulku.
Přišli jsme na to, jak identifikovat tabulky, které jsou u nás nateklé, navíc když jsou nabobtnané zbytečnými daty.
Nyní o tom, jak opravit nadýmání:
- Pokud máme malou plotnu a dobré disky, tedy na plotně do gigabajtu, je docela možné použít VACUUM FULL. Na pár sekund si od vás vezme exkluzivní zámek a dobře, ale všechno udělá rychle a tvrdě. Co dělá VACUUM FULL? Vezme exkluzivní zámek na stůl a přepíše živé řádky ze starých tabulek do nové tabulky. A nakonec je vystřídá. Smaže staré soubory, nahradí staré soubory novými. Ale po dobu své práce zabírá exkluzivní zámek na stole. To znamená, že s touto tabulkou nemůžete nic dělat: ani do ní zapisovat, ani do ní číst, ani ji upravovat. A VACUUM FULL vyžaduje další místo na disku pro zápis dat.
- Další nástroj . Svým principem je velmi podobný VACUUM FULL, protože také přepisuje data ze starých souborů do nových a nahrazuje je v tabulce. Zároveň si ale nebere exkluzivní zámek na stůl hned na začátku své práce, ale bere si ho až v okamžiku, kdy má připravená data, aby soubory nahradil. Má stejné požadavky na diskové prostředky jako VACUUM FULL. Potřebujete další místo na disku, a to je někdy kritické, pokud máte terabajtové tabulky. A co se týče procesoru, je docela nenasytný, protože aktivně pracuje s I/O.
- Třetí utilita je . Na zdroje je opatrnější, protože funguje na trochu jiných principech. Hlavní podstatou pgcompacttable je, že přesouvá všechny živé řádky na začátek tabulky s aktualizacemi v tabulce. A pak to spustí vakuum na tomto stole, protože víme, že máme živé řady na začátku a mrtvé řady na konci. A samotný vakuum tento ocas odřízne, to znamená, že nevyžaduje mnoho dalšího místa na disku. A přitom se to dá ještě zmáčknout zdroji.
Vše s nářadím.
Pokud shledáváte naduté téma zajímavé z hlediska hlubšího zahloubání, zde je pro vás několik užitečných odkazů:
- je zpráva mého kolegy. Jde obecně o to, kam se Postgres ubírá v průběhu své práce a života. A existuje velmi velký a podrobný technický článek pro DBA o nadýmání.
- je odkaz na naše úložiště, kde uchováváme spoustu užitečných skriptů pro kontrolu stavu databáze. Zde můžete najít skripty pro vyhledávání nadýmání.
- и odkazy na nástroje, které vám pomohou komprimovat desky.
- Toto je příspěvek mého kolegy. Tam zcela vážně a technicky podrobně rozebírá nadýmání již na úrovni blízké administrátorům.
Zde jsem se pokusil ukázat hororový příběh pro vývojáře, protože jsou našimi přímými klienty databází a musí rozumět tomu, k čemu a k čemu vedou akce. Doufám, že se mi to povedlo. Děkuji za pozornost!
otázky
Díky za zprávu! Mluvil jste o tom, jak lze identifikovat problémy. Jak mohou být varováni? To znamená, že jsem měl situaci, kdy požadavky visely nejen proto, že se obrátily na nějaké externí služby. Bylo to jen pár divokých spojení. Byly tam nějaké drobné, neškodné požadavky, které se tu poflakovaly celý den, a pak začaly dělat nějaké nesmysly. To znamená, že je to velmi podobné tomu, co popisujete. Jak to sledovat? Sedněte si a neustále sledujte, který požadavek se zasekl? Jak tomu lze předejít?
V tomto případě je to úkol pro administrátory vaší společnosti, ne nutně pro DBA.
Jsem správce.
PostgreSQL má pohled nazvaný pg_stat_activity, který zobrazuje čekající dotazy. A je vidět, jak dlouho tam visí.
Musím každých 5 minut přijít a podívat se?
Nastavte cron a zkontrolujte. Pokud máte dlouhý požadavek, napište dopis a je to. To znamená, že se nemusíte dívat očima, to lze zautomatizovat. Dostanete dopis, odpovíte na něj. Nebo můžete střílet automaticky.
Existují jasné důvody, proč se tak děje?
Některé jsem uvedl. Další složitější příklady. A může dojít k dlouhému rozhovoru.
Díky za zprávu! Chtěl jsem objasnit utilitu pg_repack. Pokud to nebude vyžadovat exkluzivní zámek, pak...
Vyrábí exkluzivní zámek.
... pak bych mohl potenciálně ztratit data. Neměla by moje aplikace v tuto chvíli nic nahrávat?
Ne, pracuje tiše s tabulkou, tj. pg_repack nejprve přenese všechny živé řádky, které tam jsou. Nějaký záznam v tabulce samozřejmě probíhá. Prostě hodí tenhle culík.
To znamená, dělá to ještě na konci?
Nakonec to trvá exkluzivní zámek na výměnu těchto souborů.
Bude rychlejší než VACUUM FULL?
VACUUM FULL, jak to začalo, okamžitě vzal exkluzivní zámek. A dokud všechno neudělá, nepustí ji. A pg_repack používá exkluzivní zámek pouze v době výměny souborů. V tuto chvíli tam sice nepíšete, ale data se neztratí, vše bude v pořádku.
Ahoj! Mluvil jste o práci autovakua. Byl tam graf s červenými, žlutými a zelenými buňkami záznamu. Tedy žluté – označil je za smazané. A ve výsledku do nich můžete napsat něco nového?
Ano. Postgres neodstraňuje řádky. Má takové specifikum. Pokud jsme řádek aktualizovali, označili jsme starý jako smazaný. ID transakce, které změnilo tento řádek, se tam dostane a napíšeme nový řádek. A máme relace, které je mohou potenciálně číst. V určitém okamžiku docela zestárnou. A podstatou autovakua je to, že prochází těmito řádky a označí je jako nepotřebné. A tam můžete data přepsat.
Chápu. Ale otázka není o tom. Nesouhlasil jsem. Řekněme, že máme stůl. Má pole s proměnlivou velikostí. A pokud se pokusím vložit něco nového, může se stát, že se to do staré buňky jednoduše nevejde.
Ne, v každém případě se aktualizuje celý řádek. Postgres má dva modely úložiště. Vybírá z datového typu. Existují data, která jsou uložena přímo v tabulce, a také data tos. Jedná se o velké množství dat: text, json. Jsou uloženy v samostatných tabletách. A podle těchto tablet se děje stejný příběh s nadýmáním, to znamená, že všechno je stejné. Jsou pouze uvedeny samostatně.
Díky za zprávu! Jak přijatelné je použití požadavků na časový limit výpisu k omezení trvání?
Velmi přijatelné. Používáme to všude. A vzhledem k tomu, že nemáme vlastní služby, poskytujeme vzdálenou podporu, klienti jsou poměrně různorodí. A všichni jsou s tím celkem spokojeni. To znamená, že máme práce v cronu, které kontrolují. Jde jen o to, že délka sezení je domluvená s klientem, před kterou se neklapeme. Může to být minuta, může to být 10 minut. Záleží na zatížení základny a jejím účelu. Ale všichni používáme pg_stat_activity.
Díky za zprávu! Snažím se vyzkoušet vaši zprávu pro mé aplikace. A zdá se, že všude začínáme transakci a všude ji vyloženě dokončíme. Pokud dojde k nějaké výjimce, dojde ke stejnému vrácení zpět. A pak mě napadlo. Koneckonců, transakce nemůže začít explicitně. Myslím, že tohle je nápověda pro dívku. Pokud pouze aktualizuji záznam, začne transakce v PostgreSQL a skončí až po odpojení připojení?
Pokud nyní mluvíte o úrovni aplikace, pak záleží na ovladači, který používáte, na používaném ORM. Je tam spousta nastavení. Pokud máte zapnuté automatické potvrzení, transakce začne tam a okamžitě se zavře.
To znamená, že se zavře okamžitě po aktualizaci?
Záleží na nastavení. Pojmenoval jsem jedno nastavení. Toto je automatické potvrzení. Je docela obyčejná. Pokud je povoleno, transakce byla otevřena a uzavřena. Pokud jste výslovně neřekli „zahájit transakci“ a „ukončit transakci“, ale jednoduše spustili požadavek do relace.
Ahoj! Díky za zprávu! Představte si, že máme databázi, která se zvětšuje a zvětšuje a pak na serveru dojde místo. Existují nějaké nástroje k nápravě této situace?
Místo na serveru v dobrém slova smyslu musí být monitorováno.
Například DBA šel pít čaj, byl v resortu atd.
Když se vytvoří systém souborů, vytvoří se alespoň nějaké rezervní místo, kam se data nezapisují.
Co když je úplně nula?
Tam se tomu říká vyhrazený prostor, to znamená, že jej lze uvolnit a podle toho, jak velký byl vytvořen, jste získali volné místo. Ve výchozím nastavení nevím, kolik jich je. A v jiném případě dodejte disky, abyste měli kde provést operaci obnovy. Můžete smazat nějakou tabulku, kterou zaručeně nebudete potřebovat.
Nejsou žádné další nástroje?
Vždy je to ruční práce. A na místě se ukáže, co je lepší tam udělat, protože tam jsou data, která jsou kritická, jsou tam nekritická. A u každé databáze a aplikace, která s ní pracuje, záleží na podnikání. Rozhoduje se vždy na místě.
Díky za zprávu! Mám dvě otázky. Nejprve jste ukázali snímky, kde bylo ukázáno, že v případě zavěšených transakcí roste jak množství tabulkového prostoru, tak velikost indexu. A dále ve zprávě byla spousta utilit, které balí tablet. A co index?
Také je balí.
Ale vakuum nemá vliv na index?
Některé pracují s indexem. Například pg_rapack, pgcompacttable. Vakuum znovu vytváří indexy, ovlivňuje je. VACUUM FULL má podstatu přepsání všeho, tj. funguje se všemi.
A druhá otázka. Nechápal jsem, proč zprávy o replikách tolik závisí na replikaci samotné. Zdálo se mi, že zprávy se čtou a replikace zapisuje.
Co způsobuje konflikt replikace? Máme Mistra, na kterém probíhají procesy. Máme autovakuum. Autovakuum ve skutečnosti, co to dělá? Vystřihne nějaké staré řádky. Pokud v tuto chvíli máme požadavek na repliku, která čte tyto staré řádky, a na Masteru došlo k situaci, že autovakuum označilo tyto řádky jako možné k přepsání, pak jsme je přepsali. A obdrželi jsme datový paket, když musíme přepsat řádky, které požadavek potřebuje na replice, pak proces replikace počká na časový limit, který jste nakonfigurovali. A pak se PostgreSQL rozhodne, co je pro něj důležitější. A replikace je pro něj důležitější než žádost a žádost zastřelí, aby provedl tyto změny na replice.
Andrew, mám otázku. Tato nádherná grafika, kterou jste předvedli během prezentace, je výsledkem nějaké práce vašeho nástroje? Jak byly vytvořeny grafy?
Toto je služba .
Jedná se o komerční produkt?
Ano. Jedná se o komerční produkt.
Zdroj: www.habr.com