Navrhujem, aby ste si prečítali prepis správy zo začiatku roka 2016 od Andreyho Salnikova „Typické chyby v aplikáciách, ktoré vedú k nadúvaniu v postgresql“
V tejto správe budem analyzovať hlavné chyby v aplikáciách, ktoré vznikajú vo fáze navrhovania a písania kódu aplikácie. A vezmem len tie chyby, ktoré vedú k nadúvaniu v Postgresql. Toto je spravidla začiatok konca výkonu vášho systému ako celku, hoci spočiatku na to neboli viditeľné žiadne predpoklady.
Radi privítame všetkých! Táto správa nie je taká technická ako predchádzajúca od môjho kolegu. Táto správa je zameraná hlavne na vývojárov backendových systémov, pretože máme pomerne veľký počet klientov. A všetci robia rovnaké chyby. Poviem vám o nich. Vysvetlím, k akým fatálnym a zlým veciam tieto chyby vedú.
Prečo sa robia chyby? Robia sa z dvoch dôvodov: náhodne, možno to vyjde a pre neznalosť niektorých mechanizmov, ktoré sa vyskytujú na úrovni medzi databázou a aplikáciou, ako aj v samotnej databáze.
Dám vám tri príklady s hroznými obrázkami toho, ako sa veci stali zlými. Stručne vám poviem o mechanizme, ktorý sa tam deje. A ako sa s nimi vysporiadať, kedy k nim došlo a aké preventívne metódy použiť na predchádzanie chybám. Poviem vám o pomocných nástrojoch a poskytnem užitočné odkazy.
Použil som testovaciu databázu, kde som mal dve tabuľky. Jeden tanier s účtami zákazníkov, druhý s transakciami na týchto účtoch. A s určitou frekvenciou aktualizujeme zostatky na týchto účtoch.
Počiatočné údaje platne: je pomerne malá, 2 MB. Čas odozvy pre databázu a konkrétne pre znamenie je tiež veľmi dobrý. A celkom dobrá záťaž - 2 operácií za sekundu podľa taniera.
A prostredníctvom tejto správy vám ukážem grafy, aby ste jasne pochopili, čo sa deje. Vždy budú 2 snímky s grafmi. Prvá snímka je to, čo sa vo všeobecnosti deje na serveri.
A v tejto situácii vidíme, že skutočne máme malé znamenie. Index je malý, má 2 MB. Toto je prvý graf vľavo.
Priemerný čas odozvy na serveri je tiež stabilný a krátky. Toto je graf vpravo hore.
V ľavom dolnom grafe sú uvedené najdlhšie transakcie. Vidíme, že transakcie sú dokončené rýchlo. A autovákuum tu ešte nefunguje, pretože to bol štartovací test. Bude to fungovať aj naďalej a bude to pre nás užitočné.
Druhá snímka bude vždy venovaná testovanej platni. V tejto situácii neustále aktualizujeme zostatky na účte klienta. A vidíme, že priemerný čas odozvy na operáciu aktualizácie je celkom dobrý, menej ako milisekunda. Vidíme, že zdroje procesora (toto je graf vpravo hore) sa tiež spotrebúvajú rovnomerne a dosť malé.
Pravý dolný graf ukazuje, koľko operačnej a diskovej pamäte prejdeme pri hľadaní nami požadovaného riadku pred jeho aktualizáciou. A počet operácií podľa znamienka je 2 za sekundu, ako som povedal na začiatku.
A teraz tu máme tragédiu. Z nejakého dôvodu existuje dlho zabudnutá transakcia. Všetky dôvody sú zvyčajne banálne:
- Jednou z najbežnejších je, že sme v kóde aplikácie začali pristupovať k externej službe. A táto služba nám neodpovedá. To znamená, že sme otvorili transakciu, urobili zmenu v databáze a prešli z aplikácie na čítanie pošty alebo na inú službu v rámci našej infraštruktúry a tá nám z nejakého dôvodu neodpovedá. A naša relácia uviazla v stave, kedy sa nevie, kedy sa to vyrieši.
- Druhá situácia je, keď sa v našom kóde z nejakého dôvodu vyskytla výnimka. A na výnimku sme nespracovali uzavretie transakcie. A skončili sme reláciou zavesenia s otvorenou transakciou.
- A posledný je tiež pomerne bežný prípad. Toto je kód nízkej kvality. Niektoré rámce otvárajú transakciu. Visí a možno v aplikácii neviete, že ho máte zavesený.
Kam takéto veci vedú?
Do tej miery, že naše tabuľky a indexy začnú dramaticky napučiavať. Toto je presne ten istý efekt nafukovania. Pre databázu to bude znamenať, že čas odozvy databázy sa veľmi prudko zvýši a zaťaženie databázového servera sa zvýši. A v dôsledku toho bude trpieť naša aplikácia. Pretože ak ste vo svojom kóde strávili 10 milisekúnd v požiadavke na databázu, 10 milisekúnd vo vašej logike, tak dokončenie vašej funkcie trvalo 20 milisekúnd. A teraz bude vaša situácia veľmi smutná.
A uvidíme, čo sa stane. Dolný ľavý graf ukazuje, že máme dlhú dlhú transakciu. A ak sa pozrieme na ľavý horný graf, vidíme, že veľkosť našej tabuľky zrazu vyskočila z dvoch megabajtov na 300 megabajtov. Zároveň sa množstvo údajov v tabuľke nezmenilo, t. j. je tam dosť veľké množstvo odpadu.
Všeobecná situácia týkajúca sa priemerného času odozvy servera sa tiež zmenila o niekoľko rádov. To znamená, že všetky požiadavky na serveri začali úplne klesať. A zároveň sa formou autovakua spustili interné procesy Postgresu, ktoré sa snažia niečo robiť a spotrebúvajú zdroje.
Čo sa deje s naším znamením? Rovnaký. Náš priemerný čas odozvy podľa znamenia vyskočil o niekoľko rádov vyššie. Konkrétne z hľadiska spotrebovaných zdrojov vidíme, že zaťaženie procesora sa výrazne zvýšilo. Toto je graf vpravo hore. A zvýšil sa, pretože procesor musí pri hľadaní toho potrebného pretriediť množstvo zbytočných riadkov. Toto je graf vpravo dole. A v dôsledku toho nám počet hovorov za sekundu začal veľmi výrazne klesať, pretože databáza nestihla spracovať rovnaký počet požiadaviek.
Potrebujeme sa vrátiť do života. Ideme online a zisťujeme, že dlhé transakcie vedú k problémom. Nájdeme a zabijeme túto transakciu. A všetko sa pre nás stáva normálnym. Všetko funguje ako má.
Upokojili sme sa, no po chvíli si začíname všímať, že aplikácia nefunguje tak, ako pred pohotovosťou. Žiadosti sú stále spracovávané pomalšie a výrazne pomalšie. Jeden a pol až dvakrát pomalšie konkrétne v mojom príklade. Zaťaženie servera je tiež vyššie ako pred nehodou.
A otázka: "Čo sa v tejto chvíli deje so základňou?" A pri základni nastáva nasledujúca situácia. Na grafe transakcií môžete vidieť, že sa zastavil a skutočne neexistujú žiadne dlhodobé transakcie. No veľkosť nápisu sa pri nehode fatálne zväčšila. A odvtedy sa nezmenšili. Priemerný čas na základni sa ustálil. A zdá sa, že odpovede prichádzajú adekvátne rýchlosťou pre nás prijateľnou. Autovákuum sa zaktivizovalo a začalo niečo robiť so znakom, pretože potrebuje preosiať viac dát.
Konkrétne podľa testovacej dosky s účtami, kde meníme zostatky: zdá sa, že čas odozvy na požiadavku sa vrátil do normálu. V skutočnosti je však jeden a pol krát vyššia.
A zo záťaže procesora vidíme, že záťaž procesora sa nevrátila na požadovanú hodnotu pred pádom. A dôvody sú presne v pravom dolnom grafe. Je vidieť, že sa tam hľadá určité množstvo pamäte. To znamená, že na nájdenie požadovaného riadku plytváme zdrojmi databázového servera pri triedení zbytočných údajov. Počet transakcií za sekundu sa stabilizoval.
Celkovo dobré, ale situácia je horšia ako bola. Jasná degradácia databázy v dôsledku našej aplikácie, ktorá s touto databázou pracuje.
A aby ste pochopili, čo sa tam deje, ak ste neboli na predchádzajúcej správe, poďme teraz trochu teórie. Teória o vnútornom procese. Prečo vysávač do auta a na čo slúži?
Pre pochopenie doslova stručne. V určitom okamihu máme stôl. V tabuľke máme riadky. Tieto línie môžu byť aktívne, živé a to, čo teraz potrebujeme. Na obrázku sú označené zelenou farbou. A existujú konečné termíny, ktoré už boli vypracované, aktualizované a objavili sa na nich nové záznamy. A sú označené, že už nie sú pre databázu zaujímavé. Ale sú v tabuľke kvôli funkcii Postgres.
Prečo potrebujete vysávač do auta? V určitom okamihu príde autovákuum, vstúpi do databázy a požiada ju: "Prosím, dajte mi ID najstaršej transakcie, ktorá je momentálne otvorená v databáze." Databáza vráti toto ID. A autovakuum, spoliehajúc sa na to, triedi riadky v tabuľke. A ak vidí, že niektoré riadky boli zmenené oveľa staršími transakciami, tak má právo označiť ich ako riadky, ktoré môžeme v budúcnosti znova použiť tak, že tam napíšeme nové údaje. Toto je proces na pozadí.
V súčasnosti pokračujeme v práci s databázou a pokračujeme v niektorých zmenách tabuľky. A na tieto riadky, ktoré môžeme opätovne použiť, zapisujeme nové dáta. A tak dostaneme cyklus, t.j. stále sa tam objavujú nejaké mŕtve staré riadky, namiesto nich zapisujeme nové riadky, ktoré potrebujeme. A toto je normálny stav pre fungovanie PostgreSQL.
Čo sa stalo počas nehody? Ako tam k tomuto procesu došlo?
Mali sme nápis v nejakom stave, niektoré živé, niektoré mŕtve. Prišiel vysávač do auta. Spýtal sa databázy, aká je naša najstaršia transakcia a aké je jej ID. Dostal som toto ID, čo mohlo byť pred mnohými hodinami, možno pred desiatimi minútami. Závisí to od toho, aké veľké zaťaženie máte v databáze. A šiel hľadať linky, ktoré by mohol označiť ako opätovne použité. A také riadky som v našej tabuľke nenašiel.
Ale v tomto čase pokračujeme v práci s tabuľkou. Niečo v ňom robíme, aktualizujeme, meníme údaje. Čo by mala databáza v tomto čase robiť? Nezostáva jej nič iné, len pridať nové riadky na koniec existujúcej tabuľky. A tým sa naša tabuľková veľkosť začína nafukovať.
V skutočnosti potrebujeme, aby fungovali zelené linky. Ale pri takomto probléme sa ukáže, že percento zelených čiar je extrémne nízke v celej tabuľke.
A keď vykonáme dotaz, databáza musí prejsť všetkými riadkami: červeným aj zeleným, aby našla požadovaný riadok. A efekt nafúknutia tabuľky zbytočnými údajmi sa nazýva „nadúvanie“, ktoré tiež zaberá miesto na disku. Pamätáte si, že to bolo 2 MB, stalo sa z toho 300 MB? Teraz zmeňte megabajty na gigabajty a rýchlo stratíte všetky svoje diskové prostriedky.
Aké to môže mať pre nás dôsledky?
- V mojom príklade tabuľka a index vzrástli 150-krát. Niektorí naši klienti mali viac smrteľných prípadov, keď im jednoducho začalo dochádzať miesto na disku.
- Veľkosť samotných stolov sa nikdy nezmenší. Autovákuum môže v niektorých prípadoch odrezať chvost tabuľky, ak existujú iba mŕtve čiary. Ale keďže sa neustále otáča, jeden zelený riadok môže na konci zamrznúť a neaktualizovať sa, zatiaľ čo všetky ostatné budú zapísané niekde na začiatku platne. Ale toto je taká nepravdepodobná udalosť, že váš stôl sa sám zmenší, takže by ste v to nemali dúfať.
- Databáza potrebuje pretriediť množstvo zbytočných riadkov. A plytváme diskovými zdrojmi, plytváme zdrojmi procesorov a elektrinou.
- A to priamo ovplyvňuje našu aplikáciu, pretože ak sme na začiatku strávili 10 milisekúnd na požiadavke, 10 milisekúnd na našom kóde, tak pri páde sme začali tráviť sekundu požiadavkou a 10 milisekúnd nad kódom, t.j. rozsah výkonu aplikácie sa znížil. A keď bola nehoda vyriešená, začali sme tráviť 20 milisekúnd žiadosťou a 10 milisekúnd kódom. To znamená, že sme stále jedenapolkrát klesli v produktivite. A to všetko kvôli jednej transakcii, ktorá zamrzla, možno našou vinou.
- A otázka: „Ako dostaneme všetko späť?“, aby bolo u nás všetko v poriadku a požiadavky prichádzali tak rýchlo ako pred nehodou.
Na tento účel existuje určitý cyklus práce, ktorý sa vykonáva.
Najprv musíme nájsť problematické tabuľky, ktoré sú nafúknuté. Chápeme, že v niektorých tabuľkách je záznam aktívnejší, v iných menej aktívny. A na to používame rozšírenie . Inštaláciou tohto rozšírenia môžete písať dotazy, ktoré vám pomôžu nájsť tabuľky, ktoré sú dosť nafúknuté.
Keď nájdete tieto tabuľky, musíte ich skomprimovať. Nástroje na to už existujú. V našej spoločnosti používame tri nástroje. Prvým je vstavaný VACUUM FULL. Je krutý, drsný a nemilosrdný, no niekedy je veľmi užitočný. и - Toto sú pomocné programy tretích strán na kompresiu tabuliek. A s databázou zaobchádzajú opatrnejšie.
Používajú sa podľa toho, čo je pre vás výhodnejšie. Ale o tom vám poviem úplne na konci. Hlavná vec je, že existujú tri nástroje. Je z čoho vyberať.
Potom, čo sme všetko napravili a ubezpečili sa, že je všetko v poriadku, musíme vedieť, ako tejto situácii v budúcnosti zabrániť:
- Dá sa tomu celkom jednoducho zabrániť. Musíte sledovať trvanie relácií na hlavnom serveri. Obzvlášť nebezpečné relácie v nečinnosti v stave transakcie. To sú tí, ktorí práve otvorili transakciu, niečo urobili a odišli, alebo jednoducho viseli, stratili sa v kóde.
- A pre vás, ako vývojárov, je dôležité otestovať váš kód, keď nastanú tieto situácie. Nie je to ťažké urobiť. Bude to užitočná kontrola. Vyhnete sa tak veľkému množstvu „detských“ problémov spojených s dlhými transakciami.
Na týchto grafoch som vám chcel ukázať, ako sa zmenilo znamenie a správanie databázy po tom, čo som v tomto prípade prešiel cez znamenie s VACUUM FULL. Toto nie je výroba pre mňa.
Veľkosť tabuľky sa okamžite vrátila do normálneho prevádzkového stavu niekoľkých megabajtov. Priemerný čas odozvy servera to výrazne neovplyvnilo.
Ale konkrétne pre naše testovacie znamenie, kde sme aktualizovali zostatky na účtoch, vidíme, že priemerný čas odozvy na žiadosť o aktualizáciu údajov v značke sa znížil na úroveň pred núdzovým stavom. Zdroje spotrebované procesorom na dokončenie tejto požiadavky tiež klesli na úroveň pred zlyhaním. A pravý dolný graf ukazuje, že teraz nájdeme presne ten riadok, ktorý potrebujeme hneď, bez toho, aby sme prechádzali cez hromady mŕtvych riadkov, ktoré tam boli pred stlačením tabuľky. A priemerný čas vyžiadania zostal približne na rovnakej úrovni. Ale tu mám skôr chybu v mojom hardvéri.
Tu sa prvý príbeh končí. Je to najbežnejšie. A stane sa to každému, bez ohľadu na skúsenosti klienta a kvalifikáciu programátorov. Skôr či neskôr sa to stane.
Druhý príbeh, v ktorom rozdeľujeme záťaž a optimalizujeme zdroje servera
- Už sme vyrástli a stali sa z nás seriózni chlapi. A chápeme, že máme repliku a bolo by pre nás dobré vyvážiť záťaž: napíšte Majstrovi a čítajte z repliky. A väčšinou táto situácia nastane, keď chceme pripraviť nejaké reporty alebo ETL. A biznis má z toho veľkú radosť. Naozaj chce rôzne prehľady s množstvom komplexných analýz.
- Prehľady trvajú veľa hodín, pretože komplexné analýzy nemožno vypočítať v milisekundách. My, ako odvážni chlapi, píšeme kód. Vo vkladacej aplikácii urobíme záznam na Master a spustíme správy o replike.
- Rozloženie nákladu.
- Všetko funguje perfektne. Sme skvelí.
A ako táto situácia vyzerá? Konkrétne na týchto grafoch som pridal aj trvanie transakcií z repliky za trvanie transakcie. Všetky ostatné grafy sa vzťahujú len na hlavný server.
Do tejto doby sa moja správa rozrástla. Je ich viac. Vidíme, že priemerný čas odozvy servera je stabilný. Vidíme, že na replike máme dlhotrvajúcu transakciu, ktorá trvá 2 hodiny. Vidíme tichý chod autovákua, ktorý spracováva mŕtve linky. A u nás je všetko v poriadku.
Konkrétne tam podľa testovaného taniera pokračujeme v aktualizácii zostatkov na účtoch. A tiež máme stabilný čas odozvy na požiadavky, stabilnú spotrebu zdrojov. U nás je všetko v poriadku.
Všetko je v poriadku, kým sa tieto hlásenia nezačnú znova spúšťať z dôvodu konfliktu s replikáciou. A v pravidelných intervaloch strieľajú späť.
Ideme online a začneme čítať, prečo sa to deje. A nájdeme riešenie.
Prvým riešením je zvýšenie latencie replikácie. Vieme, že náš prehľad beží 3 hodiny. Nastavili sme oneskorenie replikácie na 3 hodiny. Všetko spúšťame, no stále máme problémy s občasným zrušením prehľadov.
Chceme, aby bolo všetko dokonalé. Stúpame ďalej. A na internete sme našli skvelé nastavenie – hot_standby_feedback. Poďme to zapnúť. Hot_standby_feedback nám umožňuje zadržať automatické vákuum na Master. Tým sa úplne zbavíme replikačných konfliktov. A s prehľadmi nám všetko funguje dobre.
A čo sa v súčasnosti deje s hlavným serverom? A máme totálny problém s hlavným serverom. Teraz vidíme grafy, keď mám obe tieto nastavenia povolené. A vidíme, že relácia na našej replike nejako začala ovplyvňovať situáciu na Master serveri. Má to vplyv, pretože prerušila autovakuum, čím sa vymazávajú mŕtve čiary. Veľkosť nášho stola opäť raketovo vzrástla. Priemerný čas vykonania dotazu v celej databáze tiež prudko vzrástol. Autovysávače trochu sprísnili.
Konkrétne z nášho taniera vidíme, že aj aktualizácia údajov na ňom vyskočila do neba. Spotreba CPU sa podobne výrazne zvýšila. Opäť prechádzame veľkým množstvom mŕtvych, zbytočných liniek. A čas odozvy pre tento znak a počet transakcií klesli.
Ako to bude vyzerať, keď nevieme, o čom som hovoril predtým?
- Začíname hľadať problémy. Ak sme narazili na problémy v prvej časti, vieme, že to môže byť spôsobené dlhou transakciou a ísť k Majstrovi. Máme problém s Majstrom. Klobásky ho. Zohrieva sa, priemer jeho zaťaženia je okolo stovky.
- Žiadosti sú tam pomalé, ale nevidíme tam žiadne dlhotrvajúce transakcie. A nechápeme o čo ide. Nechápeme, kde hľadať.
- Skontrolujeme serverové vybavenie. Možno náš nájazd stroskotal. Možno nám vyhorela pamäťová karta. Áno, stať sa môže čokoľvek. Ale nie, servery sú nové, všetko funguje dobre.
- Všetci bežia: správcovia, vývojári aj riaditeľ. Nič nepomáha.
- A v určitom bode sa zrazu všetko začne opravovať.
V tomto čase bola žiadosť o našu repliku spracovaná a ponechaná. Dostali sme správu. Obchod je stále šťastný. Ako vidíte, naše znamenie opäť narástlo a už sa nezmenšuje. Na grafe s reláciami som nechal kúsok tejto dlhej transakcie z repliky, aby ste vedeli odhadnúť, ako dlho trvá, kým sa situácia stabilizuje.
Relácia sa skončila. A až po nejakom čase príde server viac-menej v poriadku. A priemerný čas odozvy na požiadavky na hlavnom serveri sa vráti do normálu. Pretože konečne má autovákuum možnosť tieto mŕtve čiary vyčistiť a označiť. A začal robiť svoju prácu. A ako rýchlo to robí, tak rýchlo sa dáme do poriadku.
Podľa testovaného tabletu, kde aktualizujeme zostatky na účtoch, vidíme presne rovnaký obrázok. Postupne sa normalizuje aj priemerný čas aktualizácie účtu. Znížia sa aj zdroje spotrebované procesorom. A počet transakcií za sekundu sa vráti do normálu. Ale opäť sme späť v normále, nie tak, ako sme boli pred nehodou.
V každom prípade dostaneme zníženie výkonu, ako v prvom prípade, jeden a pol až dva krát a niekedy aj viac.
Zdá sa, že sme urobili všetko správne. Rozložte záťaž. Zariadenie nie je nečinné. Žiadosti sme si rozdelili podľa mysle, no aj tak všetko dopadlo zle.
- Nepovoliť hot_standby_feedback? Áno, neodporúča sa ho zapínať bez obzvlášť závažných dôvodov. Pretože toto skrútenie priamo ovplyvňuje hlavný server a pozastavuje tam činnosť autovákua. Ak to povolíte na nejakej replike a zabudnete na to, môžete zabiť Majstra a získať veľké problémy s aplikáciou.
- Zvýšiť max_standby_streaming_delay? Áno, pre prehľady to platí. Ak máte trojhodinovú správu a nechcete, aby zlyhala kvôli konfliktom replikácie, jednoducho zvýšte oneskorenie. Dlhodobá správa nikdy nevyžaduje údaje, ktoré sa dostali do databázy práve teraz. Ak to máte tri hodiny, tak to máte spustené na nejaké staré dátové obdobie. A pre vás nezáleží na tom, či dôjde k trojhodinovému alebo šesťhodinovému meškaniu, no hlásenia budete dostávať dôsledne a nebudete mať problémy s ich padaním.
- Prirodzene, potrebujete ovládať dlhé relácie na replikách, najmä ak sa rozhodnete povoliť hot_standby_feedback na replike. Pretože stať sa môže čokoľvek. Túto repliku sme dali vývojárovi, aby mohol otestovať dotazy. Napísal šialenú žiadosť. Spustil to a odišiel piť čaj a dostali sme zavedeného Majstra. Alebo sme tam dali nesprávnu aplikáciu. Situácie sú rôzne. Relácie na replikách musia byť monitorované rovnako starostlivo ako na Master.
- A ak máte rýchle a dlhé dotazy na repliky, potom je v tomto prípade lepšie ich rozdeliť, aby sa rozložila záťaž. Toto je odkaz na streaming_delay. Pre rýchlych majte jednu repliku s malým oneskorením replikácie. Pre dlhotrvajúce požiadavky na prehľady majte repliku, ktorá sa môže oneskoriť o 6 hodín alebo o deň. Toto je úplne bežná situácia.
Následky odstraňujeme rovnakým spôsobom:
- Nájdeme nadupané stoly.
- A komprimujeme to najpohodlnejším nástrojom, ktorý nám vyhovuje.
Druhý príbeh tu končí. Prejdime k tretiemu príbehu.
Aj pre nás celkom bežné, v ktorých robíme migráciu.
- Každý softvérový produkt rastie. Požiadavky naň sa menia. V každom prípade sa chceme rozvíjať. A stáva sa, že potrebujeme aktualizovať údaje v tabuľke, a to spustiť aktualizáciu v zmysle našej migrácie na novú funkcionalitu, ktorú zavádzame v rámci nášho vývoja.
- Starý formát údajov nie je uspokojivý. Povedzme, že teraz prejdeme k druhej tabuľke, kde mám transakcie na týchto účtoch. A povedzme, že boli v rubľoch a rozhodli sme sa zvýšiť presnosť a urobiť to v kopejkách. A na to musíme vykonať aktualizáciu: vynásobte pole s čiastkou transakcie sto.
- V dnešnom svete používame automatizované nástroje na kontrolu verzií databáz. Povedzme . Registrujeme tam našu migráciu. Testujeme to na našej testovacej základni. Všetko je v poriadku. Aktualizácia prebieha. Na chvíľu to blokuje prácu, ale dostávame aktualizované údaje. A v tomto môžeme spustiť novú funkcionalitu. Všetko bolo testované a kontrolované. Všetko sa potvrdilo.
- Vykonali sme plánované práce a zrealizovali migráciu.
Tu je migrácia s aktualizáciou, ktorú máte pred sebou. Keďže ide o transakcie na mojom účte, platňa bola 15 GB. A keďže aktualizujeme každý riadok, aktualizáciou sme zdvojnásobili veľkosť tabuľky, pretože každý riadok sme prepísali.
Počas migrácie sme s touto platňou nemohli nič robiť, pretože všetky požiadavky na ňu boli zaradené do frontu a čakali na dokončenie tejto aktualizácie. Ale tu chcem upozorniť na čísla, ktoré sú na zvislej osi. To znamená, že máme priemerný čas požiadavky pred migráciou asi 5 milisekúnd a zaťaženie procesora je počet blokových operácií na čítanie pamäte disku menej ako 7,5.
Uskutočnili sme migráciu a opäť sme mali problémy.
Migrácia bola úspešná, ale:
- Dokončenie starej funkcie teraz trvá dlhšie.
- Stôl sa opäť zväčšil.
- Zaťaženie servera sa opäť zvýšilo ako predtým.
- A samozrejme, stále sa pohrávame s funkcionalitou, ktorá fungovala dobre, trochu sme ju vylepšili.
A toto je opäť nadúvanie, ktoré nám opäť ničí život.
Tu demonštrujem, že tabuľka, podobne ako predchádzajúce dva prípady, sa nevráti na predchádzajúce veľkosti. Priemerné zaťaženie servera sa zdá byť primerané.
A ak sa pozrieme na tabuľku s účtami, uvidíme, že priemerný čas vyžiadania sa pre túto tabuľku zdvojnásobil. Zaťaženie procesora a počet riadkov vytriedených v pamäti vyskočil nad 7,5, ale bol nižší. A vyskočil 2-krát v prípade procesorov, 1,5-krát v prípade blokových operácií, t. j. došlo k zníženiu výkonu servera. A ako výsledok - degradácia výkonu našej aplikácie. Počet hovorov zároveň zostal približne na rovnakej úrovni.
A tu hlavnou vecou je pochopiť, ako správne robiť takéto migrácie. A treba ich urobiť. Tieto migrácie robíme celkom dôsledne.
- Takéto veľké migrácie sa nedejú automaticky. Musia byť vždy pod kontrolou.
- Vyžaduje sa dozor erudovanej osoby. Ak máte vo svojom tíme DBA, nechajte to urobiť DBA. Je to jeho práca. Ak nie, tak nech to urobí najskúsenejší človek, ktorý vie pracovať s databázami.
- Novú databázovú schému, aj keď aktualizujeme jeden stĺpec, pripravujeme vždy po etapách, t.j. v predstihu pred spustením novej verzie aplikácie:
- Pridávajú sa nové polia, do ktorých budeme zaznamenávať aktualizované údaje.
- Údaje zo starého poľa do nového poľa prenášame po malých častiach. Prečo to robíme? Po prvé, vždy kontrolujeme proces tohto procesu. Vieme, že toľko dávok sme už preniesli a toľko nám zostalo.
- A druhým pozitívnym efektom je, že medzi každou takouto dávkou uzavrieme transakciu, otvoríme novú, a to umožní autovákuu pracovať podľa taniera, vyznačiť termíny pre opätovné použitie.
- Pre riadky, ktoré sa objavia počas spustenia aplikácie (stále máme spustenú starú aplikáciu), pridáme spúšťač, ktorý zapíše nové hodnoty do nových polí. V našom prípade ide o vynásobenie starej hodnoty sto.
- Ak sme úplne tvrdohlaví a chceme rovnaké pole, potom po dokončení všetkých migrácií a pred spustením novej verzie aplikácie polia jednoducho premenujeme. Staré polia dostanú nejaký vymyslený názov a nové polia sa premenujú na staré.
- A až potom spustíme novú verziu aplikácie.
A zároveň sa nenafúkneme a nebudeme trpieť z hľadiska výkonu.
Tu sa tretí príbeh končí.
A teraz trochu podrobnejšie o nástrojoch, ktoré som spomenul v úplne prvom príbehu.
Pred hľadaním bloat musíte nainštalovať rozšírenie .
Aby ste nemuseli vymýšľať otázky, tieto otázky sme už spísali v našej práci. Môžete ich použiť. Sú tu dve žiadosti.
- Prvý z nich trvá pomerne dlho, ale ukáže vám presné hodnoty nafúknutia z tabuľky.
- Druhý funguje rýchlejšie a je veľmi účinný, keď potrebujete podľa tabuľky rýchlo posúdiť, či došlo k nafúknutiu alebo nie. Mali by ste tiež pochopiť, že nadúvanie je vždy prítomné v tabuľke Postgres. Toto je vlastnosť jeho modelu MVCC.
- A 20% nafúknutie je pre stoly vo väčšine prípadov normálne. To znamená, že by ste sa nemali obávať a komprimovať túto tabuľku.
Prišli sme na to, ako identifikovať tabuľky, ktoré sú nafúknuté zbytočnými údajmi.
Teraz o tom, ako opraviť nadúvanie:
- Ak máme malý tablet a dobré disky, teda na tablete do gigabajtu, je celkom možné použiť VACUUM FULL. Na pár sekúnd vám zoberie exkluzívny zámok na stole a dobre, ale všetko urobí rýchlo a tvrdo. Čo robí VACUUM FULL? Vezme exkluzívny zámok na stôl a prepíše živé riadky zo starých tabuliek do novej tabuľky. A na konci ich vystrieda. Vymaže staré súbory a nahradí staré novými. Ale po dobu svojej práce si vyžaduje exkluzívny zámok na stole. To znamená, že s touto tabuľkou nemôžete nič robiť: ani do nej zapisovať, ani do nej čítať, ani ju upravovať. A VACUUM FULL vyžaduje dodatočný priestor na disku na zápis údajov.
- Ďalší nástroj . Vo svojom princípe je veľmi podobný VACUUM FULL, pretože tiež prepisuje dáta zo starých súborov do nových a nahrádza ich v tabuľke. No zároveň si neberie exkluzívny zámok na stôl hneď na začiatku svojej práce, ale berie si ho až v momente, keď už má pripravené dáta na výmenu súborov. Jeho požiadavky na diskové prostriedky sú podobné ako pri VACUUM FULL. Potrebujete dodatočný priestor na disku a to je niekedy kritické, ak máte terabajtové tabuľky. A je dosť náročný na procesor, pretože aktívne pracuje s I/O.
- Tretia utilita je . So zdrojmi je opatrnejší, pretože funguje podľa trochu iných princípov. Hlavnou myšlienkou pgcompacttable je, že presúva všetky aktívne riadky na začiatok tabuľky pomocou aktualizácií v tabuľke. A potom sa na tomto stole spustí vákuum, pretože vieme, že na začiatku máme živé riadky a na konci mŕtve riadky. A samotné vákuum odreže tento chvost, to znamená, že nevyžaduje veľa miesta na disku. A zároveň sa to dá stále žmýkať, čo sa týka zdrojov.
Všetko s nástrojmi.
Ak považujete túto nafúknutú tému za zaujímavú z hľadiska hlbšieho ponorenia sa do vnútra, tu je niekoľko užitočných odkazov:
- - Toto je správa od môjho kolegu. Je to všeobecné o tom, kam smeruje priestor Postgres počas svojej práce a života. A existuje veľmi veľký a podrobný technický článok pre správcov databáz o nadúvaní.
- – toto je odkaz na naše úložisko, kde ukladáme kopu užitočných skriptov na kontrolu stavu databázy. Tam môžete nájsť skripty na vyhľadávanie nadúvania.
- и odkazy na nástroje, ktoré vám pomôžu zmenšiť značky.
- – toto je príspevok od môjho kolegu. Tam celkom vážne a technicky podrobne analyzuje nadúvanie na úrovni blízkej administrátorom.
Snažil som sa viac ukázať hororový príbeh pre vývojárov, pretože sú našimi priamymi klientmi databáz a musia pochopiť, k čomu a k čomu vedú akcie. Dúfam, že sa mi to podarilo. Ďakujem za tvoju pozornosť!
otázky
Ďakujeme za správu! Hovorili ste o tom, ako môžete identifikovať problémy. Ako ich možno varovať? To znamená, že som mal situáciu, keď požiadavky viseli nielen preto, že pristupovali k niektorým externým službám. Boli to len nejaké divoké spojenia. Boli tam nejaké drobné, neškodné požiadavky, ktoré tam viseli jeden deň a potom začali robiť nejaké nezmysly. Teda veľmi podobné tomu, čo popisuješ. Ako to sledovať? Sedieť a neustále sledovať, ktorá požiadavka sa zasekla? Ako sa tomu dá zabrániť?
V tomto prípade je to úloha pre správcov vašej spoločnosti, nie nevyhnutne pre DBA.
Som správca.
PostgreSQL má pohľad s názvom pg_stat_activity, ktorý zobrazuje visiace dotazy. A vidíte, ako dlho tam visí.
Musím prísť a pozrieť sa každých 5 minút?
Nastavte cron a skontrolujte. Ak máte dlhodobú požiadavku, napíšte list a je to. To znamená, že sa nemusíte pozerať očami, dá sa to zautomatizovať. Dostanete list, budete naň reagovať. Alebo môžete strieľať automaticky.
Existujú nejaké zjavné dôvody, prečo sa to deje?
Niektoré som uviedol. Ďalšie zložitejšie príklady. A rozhovor môže byť dlhý.
Ďakujeme za správu! Chcel som objasniť nástroj pg_repack. Ak neurobí exkluzívny zámok, potom...
Robí exkluzívny zámok.
... potom by som mohol stratiť dáta. Nemala by moja aplikácia počas tejto doby nič zaznamenávať?
Nie, s tabuľkou to funguje hladko, t.j. pg_repack najskôr prenesie všetky existujúce riadky. Prirodzene, nejaký zápis do tabuľky tam nastáva. Práve vyhadzuje tento konský chvost.
To znamená, že to nakoniec naozaj urobí?
Nakoniec si vezme exkluzívny zámok na výmenu týchto súborov.
Bude to rýchlejšie ako VACUUM FULL?
VACUUM FULL, akonáhle to začalo, okamžite vzal exkluzívny zámok. A kým neurobí všetko, nepustí ju. A pg_repack používa exkluzívny zámok iba v čase výmeny súboru. V tejto chvíli tam nebudete písať, ale údaje sa nestratia, všetko bude v poriadku.
Ahoj! Hovorili ste o prevádzke auto vysávača. Bol tam graf s červenými, žltými a zelenými záznamovými bunkami. Teda žlté – označil ich za vymazané. A vo výsledku sa do nich dá napísať niečo nové?
Áno. Postgres nevymaže riadky. Má také špecifikum. Ak sme aktualizovali riadok, starý sme označili ako vymazaný. Objaví sa tam ID transakcie, ktorá zmenila tento riadok, a napíšeme nový riadok. A máme relácie, ktoré by ich potenciálne mohli čítať. V určitom okamihu zostarnú. A podstatou toho, ako autovakuum funguje, je, že prechádza cez tieto riadky a označí ich ako nepotrebné. A tam môžete prepísať údaje.
Rozumiem. Ale o tom tá otázka nie je. Nedokončil som. Predpokladajme, že máme stôl. Má polia rôznej veľkosti. A ak sa pokúsim vložiť niečo nové, možno sa to jednoducho nezmestí do starej bunky.
Nie, v každom prípade sa tam aktualizuje celý riadok. Postgres má dva modely ukladania dát. Vyberá z dátového typu. Sú tam dáta, ktoré sú uložené priamo v tabuľke a sú tam aj tos dáta. Ide o veľké množstvo údajov: text, json. Sú uložené v samostatných platniach. A podľa týchto tabliet nastáva rovnaký príbeh s nadúvaním, t.j. všetko je rovnaké. Len sú uvedené samostatne.
Ďakujeme za správu! Je prijateľné používať dotazy na časový limit príkazov na obmedzenie trvania?
Veľmi prijateľné. Toto používame všade. A keďže nemáme vlastné služby, poskytujeme vzdialenú podporu, máme celkom rôznorodých klientov. A s týmto je každý úplne spokojný. To znamená, že máme úlohy cron, ktoré kontrolujú. Trvanie sedení je jednoducho dohodnuté s klientom, pred ktorým sa nedohodneme. Môže to byť minúta, môže to byť 10 minút. Závisí to od zaťaženia základne a jej účelu. Všetci však používame pg_stat_activity.
Ďakujeme za správu! Snažím sa použiť vašu správu na moje aplikácie. A zdá sa, že transakciu začíname všade a všade ju jasne dokončíme. Ak existuje nejaká výnimka, k vráteniu stále dochádza. A potom som začal rozmýšľať. Transakcia sa totiž nemusí začať explicitne. Toto je pravdepodobne náznak pre dievča. Ak iba aktualizujem záznam, transakcia sa spustí v PostgreSQL a dokončí sa až po odpojení pripojenia?
Ak teraz hovoríte o úrovni aplikácie, potom to závisí od ovládača, ktorý používate, od ORM, ktorý sa používa. Je tam veľa nastavení. Ak máte zapnuté automatické potvrdenie, transakcia sa spustí tam a okamžite sa uzavrie.
To znamená, že sa zatvorí ihneď po aktualizácii?
Závisí to od nastavení. Pomenoval som jedno nastavenie. Toto je automatické odovzdanie zapnuté. Je to celkom bežné. Ak je povolená, transakcia sa otvorila a zatvorila. Pokiaľ ste výslovne nepovedali „začať transakciu“ a „ukončiť transakciu“, ale jednoducho spustili požiadavku do relácie.
Ahoj! Ďakujeme za správu! Predstavme si, že máme databázu, ktorá sa zväčšuje a nafukuje a potom sa miesto na serveri minie. Existujú nejaké nástroje na nápravu tejto situácie?
Priestor na serveri je potrebné správne monitorovať.
Napríklad DBA išiel na čaj, bol v rezorte atď.
Keď sa vytvorí súborový systém, vytvorí sa aspoň nejaký druh záložného priestoru, kde sa údaje nezapisujú.
Čo ak je úplne pod nulou?
Tam sa to nazýva rezervovaný priestor, t.j. môže sa uvoľniť a podľa toho, aký veľký bol vytvorený, získate voľné miesto. Štandardne neviem, koľko ich je. A v inom prípade doručte disky, aby ste mali priestor na vykonanie rekonštrukčnej operácie. Môžete vymazať nejakú tabuľku, ktorú zaručene nebudete potrebovať.
Existujú nejaké ďalšie nástroje?
Vždy je to ručná práca. A lokálne je jasné, čo je najlepšie tam urobiť, pretože niektoré údaje sú kritické a niektoré nie sú kritické. A pre každú databázu a aplikáciu, ktorá s ňou pracuje, závisí od podnikania. Vždy sa rozhoduje lokálne.
Ďakujeme za správu! mam dve otazky. Najprv ste ukázali snímky, ktoré ukázali, že keď sa transakcie zaseknú, veľkosť tabuľkového priestoru aj veľkosť indexu sa zväčšia. A ďalej v správe bolo veľa nástrojov, ktoré balia tablet. A čo index?
Aj ich balia.
Ale vákuum neovplyvňuje index?
Niektoré pracujú s indexom. Napríklad pg_rapack, pgcompacttable. Vákuum obnovuje indexy a ovplyvňuje ich. S VACUUM FULL ide o prepísanie všetkého, t.j. funguje to so všetkými.
A druhá otázka. Nerozumiem, prečo správy o replikách tak závisia od samotnej replikácie. Zdalo sa mi, že správy sa čítajú a replikácia sa zapisuje.
Čo spôsobuje replikačný konflikt? Máme Majstra, na ktorom prebiehajú procesy. Máme v prevádzke vysávanie auta. Čo vlastne robí autovákuum? Vystrihuje niekoľko starých riadkov. Ak v tomto čase máme požiadavku na repliku, ktorá číta tieto staré riadky, a na Masterovi nastala situácia, že autovakuum označilo tieto riadky ako možné na prepísanie, tak sme ich prepísali. A dostali sme dátový paket, keď potrebujeme prepísať tie riadky, ktoré požiadavka potrebuje na repliku, proces replikácie počká na časový limit, ktorý ste nakonfigurovali. A potom PostgreSQL rozhodne, čo je pre neho dôležitejšie. A replikácia je preňho dôležitejšia ako požiadavka a natočí požiadavku, aby vykonal tieto zmeny na replike.
Andrey, mám otázku. Tieto nádherné grafy, ktoré ste ukázali počas prezentácie, sú výsledkom práce nejakej vašej užitočnosti? Ako sa robili grafy?
Toto je služba .
Je to komerčný produkt?
Áno. Toto je komerčný produkt.
Zdroj: hab.com