Predlažem da pročitate transkript izvještaja Andreja Salnikova s početka 2016. "Tipične greške u aplikacijama koje dovode do nadimanja u postgresql-u"
U ovom izvještaju analiziraću glavne greške u aplikacijama koje se javljaju u fazi dizajniranja i pisanja koda aplikacije. I uzet ću samo one greške koje dovode do nadimanja u Postgresql-u. Po pravilu, ovo je početak kraja rada vašeg sistema u cjelini, iako u početku nisu viđeni preduslovi za to.
Drago mi je svima! Ovaj izvještaj nije toliko tehnički kao prethodni od mog kolege. Ovaj govor je usmjeren na programere back-end sistema uglavnom zato što imamo prilično veliki broj klijenata. I svi prave iste greške. Reći ću vam o njima. Objasniću do čega pogubnog i lošeg vode ove greške.
Zašto se prave greške? Izvode se iz dva razloga: nasumično, možda će proraditi iz nepoznavanja nekih mehanizama koji se javljaju na nivou između baze i aplikacije, kao i u samoj bazi.
Dat ću vam tri primjera sa strašnim slikama kako su stvari postale loše. Ukratko ću opisati mehanizam koji se tu dešava. I kako se nositi s njima, kada su se dogodile i koje preventivne metode koristiti da spriječimo greške. Reći ću vam o pomoćnim alatima i dati korisne veze.
Koristio sam testnu bazu podataka u kojoj sam imao dvije tabele. Jedna tablica sa računima kupaca, druga sa operacijama na tim računima. I sa određenom periodičnošću ažuriramo stanja na ovim računima.
Početni podaci ploče: prilično je mala, 2 MB. Vrijeme odziva za bazu podataka i posebno za ploču je također vrlo dobro. I prilično dobro opterećenje - 2 operacija u sekundi na ploči.
I kroz ovaj izvještaj pokazaću vam grafikone kako bi bilo jasno šta se dešava. Uvijek će postojati 2 slajda sa grafikonima. Prvi slajd je ono što se generalno dešava na serveru.
I u ovoj situaciji vidimo da zaista imamo mali tanjir. Indeks je mali i iznosi 2 MB. Ovo je prvi grafikon s lijeve strane.
Prosečno vreme odgovora na serveru je takođe stabilno, malo. Ovo je gornji desni grafikon.
Donji lijevi grafikon prikazuje najduže transakcije. Vidimo da se transakcije brzo završavaju. A autovakum ovdje još ne radi, jer - to je bio start-test. Onda će raditi i biti nam od koristi.
Drugi slajd će uvijek biti posvećen testnoj ploči. U ovoj situaciji stalno ažuriramo stanje na računu klijenta. I vidimo da je prosječno vrijeme odgovora za operaciju ažuriranja prilično dobro, manje od jedne milisekunde. Vidimo da se resursi procesora (ovo je gornji desni grafikon) također troše ravnomjerno i prilično malo.
Donji desni grafikon pokazuje koliko operativne i disk memorije prolazimo u potrazi za željenom linijom prije nego što je ažuriramo. A broj operacija prema znaku je 2 u sekundi, kao što sam rekao na početku.
A sada imamo tragediju. Iz nekog razloga dolazi do davno zaboravljene transakcije. Razlozi su obično banalni:
- Jedan od najčešćih je da smo počeli da pristupamo eksternom servisu u kodu aplikacije. A ovaj servis nam ne odgovara. Odnosno, otvorili smo transakciju, izvršili promjenu baze podataka i prešli sa aplikacije na čitanje pošte ili na neki drugi servis unutar naše infrastrukture, a ona nam iz nekog razloga ne odgovara. A naša sjednica je visila u stanju - ne zna se kada će biti riješena.
- Druga situacija je kada se iz nekog razloga u našem kodu dogodio izuzetak. I nismo obrađivali zatvaranje transakcije u izuzetku. I dobili smo visi sastanak sa otvorenom transakcijom.
- I posljednja je također prilično česta. Ovo je kod lošeg kvaliteta. Neki okviri otvaraju transakciju. Visi i možda ne znate u aplikaciji da ga imate.
Kuda takve stvari vode?
Na činjenicu da naše tabele i indeksi počinju dramatično da rastu. Ovo je potpuno isti efekat nadimanja. Za bazu podataka, to će se izraziti u činjenici da ćemo imati vrlo naglo povećanje vremena odziva baze podataka, opterećenje na serveru baze podataka će se povećati. I kao rezultat toga, naša aplikacija će patiti. Jer ako ste u vašem kodu potrošili 10 milisekundi na zahtjev bazi podataka, 10 milisekundi na svoju logiku, onda je vaša funkcija radila 20 milisekundi. A sada će vaša situacija biti veoma tužna.
I da vidimo šta će se desiti. Donji lijevi grafikon pokazuje da imamo dugu dugu transakciju. A ako pogledamo gornji levi grafikon, vidimo da je veličina tabele skočila sa dva megabajta na 300 megabajta. Istovremeno, količina podataka u tabeli se nije promijenila, odnosno postoji prilično velika količina smeća.
Ukupna situacija u smislu prosječnog vremena odgovora servera također se promijenila za nekoliko redova veličine. Odnosno, svi zahtjevi na serveru su počeli potpuno padati. A istovremeno su pokrenuti i interni Postgres procesi suočeni sa autovakuumom, koji pokušavaju nešto da urade i troše resurse.
Šta se dešava sa našim tanjirom? Isto. Prosečno vreme odziva na tabletu je skočilo za nekoliko redova veličine. Ako se konkretno radi o potrošenim resursima, onda vidimo da se opterećenje procesora uvelike povećalo. Ovo je gornji desni grafikon. I povećao se jer procesor mora proći kroz gomilu beskorisnih linija u potrazi za onim koji vam treba. Ovo je donji desni grafikon. I kao rezultat toga, broj poziva u sekundi počeo je jako opadati, jer baza podataka nema vremena za obradu istog broja zahtjeva.
Moramo se vratiti u život. Penjemo se na internet i otkrivamo da duge transakcije dovode do problema. Pronalazimo i uništavamo ovu transakciju. I sve nam ide dobro. Sve radi kako treba.
Smirili smo se, ali nakon nekog vremena počinjemo primjećivati da aplikacija ne radi kao prije hitnog slučaja. Zahtjevi se svejedno obrađuju sporije, a mnogo sporije. Jedan i po do dva puta sporije, konkretno u mom primjeru. Opterećenje servera je također veće nego prije nesreće.
I pitanje: "Šta se dešava sa bazom u ovom trenutku?". A sa osnovom dolazi do sljedeće situacije. Na grafikonu transakcija možete vidjeti da je stao i da zaista nema dugoročnih transakcija. Ali dimenzije ploče tokom nesreće su fatalno porasle. I od tada se nije smanjio. Prosječno vrijeme na bazi se stabiliziralo. I čini se da odgovori idu adekvatno za nas prihvatljivom brzinom. Autovacuum je postao aktivniji i počeo nešto da radi sa tabletom, jer mu treba više podataka.
Konkretno, na testnoj tabli, gdje mijenjamo balanse: vrijeme odgovora na zahtjev kao da se vratilo u normalu. Ali u stvari je jedan i po puta veći.
A po opterećenju procesora vidimo da se opterećenje na procesoru nije vratilo na željenu vrijednost prije pada. A razlozi se nalaze upravo u donjem desnom grafikonu. Vidi se da se traži neka količina memorije. To jest, da bismo tražili željenu liniju, trošimo resurse servera baze podataka prilikom sortiranja beskorisnih podataka. Broj transakcija u sekundi se stabilizovao.
Generalno, dobro, ali situacija je gora nego što je bila. Eksplicitna degradacija baze podataka kao posljedica naše aplikacije koja radi sa ovom bazom podataka.
A da biste razumeli šta se tamo dešava, ako niste bili na prethodnom izveštaju, sada malo teorije. Teorija o unutrašnjem procesu. Zašto autovakum i čemu služi?
Bukvalno ukratko za razumijevanje. U nekom trenutku imamo sto. Imamo redove u tabeli. Ove linije mogu biti aktivne, žive, sada nam trebaju. Na slici su označene zelenom bojom. I postoje rokovi koji su već razrađeni, ažurirani, na njima su se pojavili novi unosi. I označeni su da više nisu interesantni bazi podataka. Ali oni leže u tabeli zbog posebnosti Postgresa.
Zašto vam je potreban autovakuum? Autovacuum dolazi u nekom trenutku, poziva bazu podataka i pita je: "Molim vas, dajte mi ID najstarije transakcije koja je trenutno otvorena u bazi podataka." Baza podataka vraća ovaj ID. A autovakuum, oslanjajući se na njega, prolazi kroz linije u tabeli. A ako vidi da su neke linije promijenjene mnogo starijim transakcijama, onda ima pravo da ih označi kao linije koje možemo ponovo koristiti u budućnosti upisivanjem novih podataka tamo. Ovo je pozadinski proces.
U ovom trenutku nastavljamo sa radom sa bazom podataka, nastavljamo da unosimo neke izmene u tabelu. I na ovim linijama, koje možemo ponovo koristiti, pišemo nove podatke. I na taj način dobijamo ciklus, odnosno stalno se pojavljuju neke mrtve stare linije, umjesto njih zapisujemo nove linije koje nam trebaju. I ovo je normalno stanje za PostgreSQL da radi.
Šta se desilo tokom nesreće? Kako se odvijao ovaj proces?
Imali smo ploču u nekom stanju, neki živi, neki mrtvi. Autovakuum je stigao. Pitao je bazu podataka koja je naša najstarija transakcija, koji je njen id. Dobio sam ovaj ID, koji može biti star mnogo sati, možda deset minuta. Zavisi koliko je opterećenje na bazi podataka. I otišao je da traži linije koje može označiti kao ponovo upotrebljene. I nisam našao takve redove u našoj tabeli.
Ali u ovom trenutku nastavljamo da radimo sa stolom. Nešto radimo u njemu, ažuriramo ga, mijenjamo podatke. Šta bi baza podataka trebala učiniti u ovom trenutku? Ona nema izbora nego da doda nove redove na kraj postojeće tabele. I tako kod nas veličina stola počinje da se naduvava.
Zaista su nam potrebne zelene linije za rad. Ali tokom takvog problema ispada da je procenat zelenih linija izuzetno nizak u celom volumenu tabele.
A kada izvršimo upit, baza podataka mora proći kroz sve redove, i crvene i zelene, da bi pronašla pravu liniju. A efekat naduvavanja tabele beskorisnim podacima naziva se "naduvavanje", što takođe jede naš prostor na disku. Zapamtite, bilo je 2 MB, a sada je 300 MB? Sada promijenite megabajte u gigabajte i vrlo brzo ćete izgubiti sve svoje diskovne resurse.
Koje su implikacije za nas?
- U mom primjeru, tabela i indeks su porasli 150 puta. Neki od naših klijenata su imali i više fatalnih slučajeva kada je prostor na disku jednostavno počeo da ponestaje.
- Stolovi se nikada neće sami od sebe smanjiti. Autovakuum u nekim slučajevima može odsjeći rep stola ako postoje samo mrtve linije. Ali pošto postoji stalna rotacija, jedna zelena linija može visjeti na kraju i ne biti ažurirana, a sve ostalo negdje na početku ploče će biti zabilježeno. Ali ovo je tako malo vjerojatan događaj da će se vaš stol smanjiti u veličini, tako da se tome ne biste trebali nadati.
- Baza podataka treba da sortira čitavu gomilu beskorisnih linija. I trošimo resurse diska, trošimo resurse procesora i električnu energiju.
- A to direktno utiče na našu aplikaciju, jer ako smo na početku potrošili 10 milisekundi na zahtjev, 10 milisekundi na naš kod, onda smo tokom pada počeli trošiti sekundu na zahtjev i 10 milisekundi na kod, tj. performanse aplikacije veličine su smanjene. A kada je nesreća riješena, počeli smo trošiti 20 milisekundi po zahtjevu, 10 milisekundi po kodu. To znači da smo ipak potonuli jedan i po put u smislu učinka. A to je sve zbog jedne transakcije koja je visila, a možda i našom krivicom.
- I pitanje: „Kako da vratim sve?“ Da je kod nas sve u redu i da zahtjevi teku brzo kao i prije nesreće.
Za to postoji određeni ciklus rada koji se izvodi.
Prvo moramo pronaći problematične tablice koje su napuhane. Razumijemo da neke tabele snimaju aktivnije, neke manje aktivno. I za to koristimo ekstenziju . Instaliranjem ovog proširenja možete pisati upite koji će vam pomoći da pronađete tabele koje su dovoljno napuhane.
Nakon što pronađete ove tabele, potrebno ih je komprimirati. Za to već postoje alati. U našoj kompaniji koristimo tri alata. Prvi je ugrađeni VACUUM FULL. On je okrutan, grub i nemilosrdan, ali ponekad je veoma koristan. и su uslužni programi treće strane za komprimiranje tablica. I oni su pažljiviji prema bazi podataka.
Koriste se u zavisnosti od toga šta vam više odgovara. Ali o ovome ću govoriti na samom kraju. Glavna stvar je da postoje tri alata. Ima mnogo toga za izabrati.
Nakon što smo sve ispravili, uvjerili se da je sve u redu, trebali bismo znati kako spriječiti ovu situaciju u budućnosti:
- Prilično je lako spriječiti. Morate pratiti trajanje sesija na Master serveru. Posebno opasne sesije u stanju mirovanja u stanju transakcije. To su oni koji su upravo otvorili transakciju, uradili nešto i otišli, ili jednostavno visili, izgubili se u kodu.
- A za vas, kao programere, važno je da testirate kod u trenutku kada dođe do ovih situacija. Nije teško to učiniti. Ovo će biti korisna provjera. Izbjeći ćete mnogo "djetinjastih" problema povezanih s dugim transakcijama.
Na ovim grafikonima, htio sam vam pokazati kako su se tablica i ponašanje baze promijenili nakon što sam proslijedio VACUUM FULL na tablicu u ovom slučaju. Ovo nije moja produkcija.
Veličina tabele se odmah vratila u normalno radno stanje od nekoliko megabajta. Ovo nije u velikoj mjeri uticalo na prosječno vrijeme odgovora na cijelom serveru.
Ali konkretno u našoj testnoj tabeli, gdje smo ažurirali stanja računa, vidimo da je prosječno vrijeme odgovora na zahtjev za ažuriranje podataka na tabletu smanjeno na nivo prije nesreće. Resursi koje je procesor potrošio da izvrši ovaj zahtjev također su pali na nivoe prije pada. A donji desni grafikon pokazuje da sada nalazimo tačno onu liniju koja nam je potrebna odmah, bez prolaska kroz gomilu mrtvih linija koje su bile prije kompresije tabele. A prosječno vrijeme upita ostalo je približno na istom nivou. Ali ovdje imam, prije, grešku mog hardvera.
Tu se prva priča završava. Ona je najčešća. I to se dešava svima, bez obzira na iskustvo klijenta, koliko su kvalifikovani programeri. Prije ili kasnije to se dogodi.
Druga priča, u kojoj raspoređujemo opterećenje i optimizujemo resurse servera
- Odrasli smo i postali ozbiljni momci. I razumijemo da imamo repliku i bilo bi dobro da izbalansiramo opterećenje: pišemo Masteru i čitamo sa replike. I obično ova situacija nastaje kada želimo da pripremimo neku vrstu izvještaja ili ETL. I biznis je veoma sretan zbog toga. On zaista želi razne izvještaje s gomilom složene analitike.
- Izvještaji traju mnogo sati, jer se složena analitika ne može izračunati u milisekundama. Mi, kao hrabri momci, pišemo kod. Radimo u aplikaciji za umetanje koju snimamo na Masteru, radimo izvještaje na replici.
- Raspoređujemo teret.
- Sve radi savršeno. Odlični smo.
I kako izgleda ova situacija? Konkretno, na ove grafikone sam dodao i trajanje transakcija iz replike za vrijeme trajanja transakcije. Svi ostali grafikoni odnose se samo na glavni server.
Do tada je moja tabla za izveštaje porasla. Ima ih više. Možemo vidjeti da je prosječno vrijeme odgovora servera stabilno. Vidimo da imamo dugotrajnu transakciju na replici koja radi 2 sata. Vidimo tihi rad autovakuma, koji obrađuje mrtve linije. I svi smo dobro.
Konkretno, prema test tabletu, nastavljamo sa ažuriranjem stanja na tamošnjim računima. Imamo i stabilno vrijeme odgovora na zahtjev, stabilnu potrošnju resursa. Kod nas je sve u redu.
Sve je u redu do trenutka kada ovi izvještaji počnu da nam uzvraćaju paljbu na sukob sa replikacijom. I uzvraćaju pucanje u pravilnim intervalima.
Idemo na internet i počinjemo čitati zašto se to događa. I nalazimo rješenje.
Prvo rješenje je povećanje latencije replikacije. Znamo da naš izvještaj traje 3 sata. Postavite kašnjenje replikacije na 3 sata. Počinjemo sve, ali i dalje imamo problema sa činjenicom da se izvještaji ponekad vraćaju.
Želimo da sve bude savršeno. Idemo dalje. A na Internetu nalazimo kul postavku - hot_standby_feedback. Uključujemo ga. Hot_standby_feedback nam omogućava da zadržimo autovakuum koji radi na Master-u. Tako se u potpunosti rješavamo sukoba replikacije. I svi dobro radimo sa izvještajima.
I šta se dešava sa glavnim serverom u ovom trenutku? A sa Master serverom imamo totalnu katastrofu. Sada vidimo grafikone sa uključenim oba ova podešavanja. I vidimo da je sesija na replici nekako počela da utiče na situaciju na Master serveru. Ima uticaj jer je suspendovao autovakuum koji čisti mrtve linije. Veličina našeg stola je ponovo naglo porasla. Prosječno vrijeme izvršenja upita u cijeloj bazi podataka je također naglo poraslo. Autovakumi su se malo zategli.
Konkretno, na našoj ploči vidimo da je ažuriranje podataka na njemu također skočilo u nebo. Potrošnja procesorskih resursa se na sličan način značajno povećala. Ponovo ponavljamo preko velikog broja mrtvih beskorisnih linija. I vrijeme odziva na ovom tabletu, broj transakcija je pao.
Kako će to izgledati ako ne znamo o čemu sam prije govorio?
- Počinjemo da tražimo probleme. Ako smo naišli na probleme u prvom dijelu, znamo da bi to mogao biti razlog za dugu transakciju i penjemo se na Master. Problem je sa Majstorom. Kobasice ga. Zagreva se, ima prosek opterećenja ispod stotinu.
- Zahtjevi se tamo usporavaju, ali tamo ne vidimo nikakve dugoročne transakcije. I ne razumemo šta se dešava. Ne znamo gde da tražimo.
- Provjera hardvera servera. Možda je naš napad propao. Možda smo spalili memorijsku traku. Da, sve može biti. Ali ne, serveri su novi, sve radi kako treba.
- Svi trče: administratori, programeri i direktor. Ništa ne pomaže.
- I u nekom trenutku, sve odjednom počinje da se ispravlja samo od sebe.
Na replici je u to vrijeme zahtjev prošao i otišao. Primili smo izvještaj. Posao je i dalje sretan. Kao što vidite, naša tabela je ponovo porasla i neće se smanjivati. Na grafikonu sa sesijama ostavio sam dio ove duge transakcije iz replike, tako da možete procijeniti koliko je vremena potrebno dok se situacija ne stabilizuje.
Sjednica je nestala. I tek nakon nekog vremena server dolazi manje-više u red. A prosječno vrijeme odgovora za zahtjeve na glavnom serveru se vraća u normalu. Jer, konačno je autovakuum dobio priliku da očisti, označi ove rokove. I počeo je da radi svoj posao. I koliko brzo on to uradi, tako brzo ćemo mi biti u redu.
Na probnoj tabli, gdje ažuriramo stanja na računu, vidimo potpuno istu sliku. Prosečno vreme ažuriranja naloga takođe se postepeno normalizuje. Resursi koje troši procesor također su smanjeni. I broj transakcija u sekundi se vratio na normalu. Ali opet, vratimo se u normalu, ne isto kao što smo imali prije nesreće.
U svakom slučaju, imamo pad performansi, kao u prvom slučaju, jedan i po do dva puta, a ponekad i više.
Čini se da smo sve uradili kako treba. Rasporedite opterećenje. Oprema ne miruje. Prema mišljenju, oni su prekršili zahtjeve, ali je ipak sve ispalo loše.
- Nemojte omogućiti hot_standby_feedback? Da, ne preporučuje se uključivanje bez posebno jakih razloga. Jer ovaj obrt direktno utiče na glavni server i obustavlja rad autovakuma tamo. Ako ga uključite na nekoj replici i zaboravite na njega, možete ubiti Master i dobiti velike probleme sa aplikacijom.
- Povećati max_standby_streaming_delay? Da, za izvještaje jeste. Ako imate trosatni izvještaj i ne želite da se sruši zbog sukoba replikacije, jednostavno povećajte kašnjenje. Dugačak izvještaj nikada ne zahtijeva podatke koji su trenutno ušli u bazu podataka. Ako ga imate tri sata, onda ga koristite za neki stari period podataka. A ti, ta tri sata kašnjenja, tih šest sati kašnjenja - neće igrati nikakvu ulogu, ali ćeš stalno primati izvještaje i nećeš znati probleme sa njihovim padom.
- Naravno, morate kontrolisati duge sesije na replikama, posebno ako odlučite da omogućite hot_standby_feedback na replici. Jer može biti bilo šta. Ovu primedbu smo dali programeru kako bi on testirao zahteve. Napisao je ludi zahtjev. Počeo je i otišao da pije čaj, a mi smo dobili uspostavljenog Učitelja. Ili smo tamo pokrenuli pogrešnu aplikaciju. Situacije su različite. Sesije na replikama se moraju kontrolisati jednako pažljivo kao i na Masteru.
- A ako imate brze i dugačke upite o replikama, onda je u ovom slučaju bolje da ih podijelite kako biste rasporedili opterećenje. Ovo je link do streaming_delay. Za brzo imati jednu repliku sa malim kašnjenjem replikacije. Za dugotrajne zahtjeve za izvještavanje, imajte repliku koja može zaostajati za 6 sati, za jedan dan. Ovo je sasvim normalna situacija.
Posljedice otklanjamo na isti način:
- Nalazimo napuhane stolove.
- I kompresujemo najprikladnijim alatom koji nam odgovara.
Druga priča se ovdje završava. Pređimo na treću priču.
Također prilično uobičajeno za nas, u kojoj radimo migraciju.
- Svaki softverski proizvod raste. Zahtjevi se mijenjaju. U svakom slučaju, želimo da se razvijamo. I dešava se da treba da ažuriramo podatke u tabeli, odnosno da pokrenemo ažuriranje u smislu naše migracije na novu funkcionalnost koju implementiramo kao deo našeg razvoja.
- Stari format podataka ne odgovara. Recimo da sada pređemo na drugu tabelu, gdje imam operacije na ovim računima. I, recimo da su bili u rubljama, a mi smo odlučili da povećamo tačnost i uradimo to u kopejkama. A za to moramo izvršiti ažuriranje: pomnožimo polje sa količinom operacije sa sto.
- U današnjem svijetu koristimo automatizirane alate za upravljanje verzijama baze podataka. Recimo . Tamo registrujemo našu migraciju. Testiramo ga na našoj testnoj bazi. Sve je uredu. Ažuriranje je u toku. Blokovi rade neko vrijeme, ali dobijamo ažurirane podatke. I možemo pokrenuti novu funkcionalnost na ovome. Sve testirano i provjereno. Sve potvrđeno.
- Sprovedeni planski radovi, izvršene migracije.
Evo migracije s ažuriranjem koje je pred vama. Pošto imam operacije po računima, ploča je bila 15 GB. A pošto ažuriramo svaki red, udvostručili smo veličinu tabele jer smo prepisali svaki red.
Tokom migracije, nismo mogli ništa učiniti s ovom oznakom, jer su svi zahtjevi za nju stajali u redu čekanja i čekali da se ovo ažuriranje završi. Ali ovdje želim da vam skrenem pažnju na brojeve koji se nalaze na okomitoj osi. Odnosno, imamo prosječno vrijeme zahtjeva prije migracije u području od 5 milisekundi i opterećenje na procesoru, broj blok operacija za čitanje memorije diska je manji od 7,5.
Migrirali smo i opet smo imali problema.
Migracija je bila uspješna, ali:
- Stara funkcionalnost počela je duže raditi.
- Stol je ponovo narastao.
- Opterećenje servera je opet postalo više nego što je bilo.
- I, naravno, još uvijek se petljamo s funkcionalnošću koja je dobro funkcionirala, malo smo je poboljšali.
A ovo je opet nadutost, koja nam opet kvari živote.
Ovdje demonstriram da se tabela, kao i prethodna dva slučaja, neće vratiti na prethodne veličine. Čini se da je prosječno opterećenje na serveru adekvatno.
A ako se okrenemo tabeli sa računima, onda ćemo videti da se prosečno vreme zahteva za ovu tabelu udvostručilo. Opterećenje procesora i broj linija koje treba sortirati u memoriji skočio je iznad 7,5, ali je bio manji. I skočio u slučaju procesora za 2 puta, u slučaju blok operacija za 1,5 puta, odnosno dobili smo degradaciju u performansama servera. I kao rezultat - degradacija performansi naše aplikacije. Istovremeno, broj poziva je ostao približno na istom nivou.
I ovdje je glavna stvar razumjeti kako ispravno napraviti takve migracije. I treba ih uraditi. Ove migracije radimo prilično redovno.
- Tako velike migracije se ne rade automatski. Uvek se moraju kontrolisati.
- Potreban nadzor od strane upućene osobe. Ako imate DBA u timu, neka to uradi DBA. To je njegov posao. Ako ne, onda neka to uradi najiskusnija osoba koja zna da radi sa bazama podataka.
- Novu šemu baze podataka, čak i ako ažuriramo jednu kolonu, uvijek se pripremamo u fazama, tj. unaprijed prije nego što se nova verzija aplikacije pojavi:
- Dodaju se nova polja u koja ćemo upisivati samo ažurirane podatke.
- Prenosimo podatke sa starog polja na novo polje u malim dijelovima. Zašto ovo radimo? Prvo, mi uvijek kontrolišemo proces ovog procesa. Znamo da smo već prenijeli toliko serija i da nam je toliko ostalo.
- A drugi pozitivan efekat je da između svake takve serije zatvaramo transakciju, otvaramo novu i to omogućava da autovakuum radi prema tablici, da označi rokove za ponovnu upotrebu.
- Za linije koje će se pojaviti tokom rada aplikacije (još uvijek imamo staru aplikaciju), dodajemo okidač koji upisuje nove vrijednosti u nova polja. U našem slučaju, ovo je množenje sa stotinu stare vrijednosti.
- Ako smo potpuno tvrdoglavi i želimo isto polje, onda po završetku svih migracija i prije pokretanja nove verzije aplikacije jednostavno preimenujemo polja. Stare u neko izmišljeno ime, a nova polja preimenujemo u stara.
- I tek nakon toga pokrećemo novu verziju aplikacije.
A u isto vrijeme, nećemo se nadimati i nećemo klonuti u performansama.
Ovo je kraj treće priče.
A sada malo više o alatima koje sam spomenuo u prvoj priči.
Prije traženja nadimanja, morate instalirati ekstenziju .
Da ne biste izmišljali zahtjeve, ove zahtjeve smo već napisali u našem radu. Možete ih koristiti. Ovdje su dva zahtjeva.
- Prvi traje dosta vremena, ali će vam pokazati tačne vrijednosti nadimanja prema tabeli.
- Drugi radi brže i veoma je efikasan kada treba brzo da procenite da li postoji naduvavanje u tabeli ili ne. Takođe treba da razumete da uvek postoji naduvavanje u Postgres tabeli. Ovo je karakteristika njegovog MVCC modela.
- A 20% nadimanja je dobro za stolove u većini slučajeva. To jest, ne biste trebali brinuti i komprimirati ovu tablicu.
Shvatili smo kako da identifikujemo tabele koje su kod nas nabrekle, štaviše, kada su nabrekle od beskorisnih podataka.
Sada o tome kako da popravite nadutost:
- Ako imamo malu ploču i dobre diskove, odnosno na ploči do gigabajta, sasvim je moguće koristiti VACUUM FULL. Uzet će vam ekskluzivnu bravu na nekoliko sekundi, i u redu, ali će sve učiniti brzo i oštro. Šta radi VACUUM FULL? Uzima ekskluzivno zaključavanje na tablici i prepisuje žive redove iz starih tablica u novu tablicu. I na kraju ih zamjenjuje. Briše stare datoteke, zamjenjuje nove za stare. Ali za vrijeme svog rada, potrebno mu je ekskluzivna brava na stolu. To znači da ne možete ništa učiniti s ovom tablicom: niti pisati u nju, niti čitati u nju, niti je mijenjati. A VACUUM FULL zahtijeva dodatni prostor na disku za pisanje podataka.
- Next Tool . Po svom principu je vrlo sličan VACUUM FULL, jer također prepisuje podatke iz starih datoteka u nove i zamjenjuje ih u tabeli. Ali u isto vrijeme, ne preuzima ekskluzivnu bravu na stolu na samom početku svog rada, već je preuzima tek u trenutku kada ima gotove podatke za zamjenu datoteka. Ima iste zahtjeve za diskovnim resursima kao VACUUM FULL. Potreban vam je dodatni prostor na disku, a to je ponekad kritično ako imate tabele od terabajta. I prilično je proždrljiv u pogledu procesora, jer aktivno radi sa I/O.
- Treći uslužni program je . Pažljivije tretira resurse, jer radi na malo drugačijim principima. Glavna suština pgcompacttable je da pomera sve žive redove na početak tabele sa ažuriranjima u tabeli. I tada počinje vakuum na ovom stolu, jer znamo da imamo žive redove na početku i mrtve redove na kraju. I sam vakuum odsiječe ovaj rep, odnosno ne zahtijeva puno dodatnog prostora na disku. A u isto vrijeme, još uvijek se može stisnuti resursima.
Sve sa alatima.
Ako smatrate da je tema naduvenosti zanimljiva u smislu daljeg kopanja unutra, evo nekoliko korisnih linkova za vas:
- je izvještaj mog kolege. Općenito je o tome gdje se nalazi Postgresovo mjesto u toku njegovog rada i života. I postoji vrlo veliki i detaljan tehnički dio za DBA o naduvavanju.
- je veza do našeg spremišta, gdje pohranjujemo gomilu korisnih skripti za provjeru statusa baze podataka. Tamo možete pronaći skripte za pretraživanje.
- и veze do alata koji će vam pomoći da komprimirate ploče.
- Ovo je objava mog kolege. Tamo on prilično ozbiljno i tehnički detaljno analizira naduvavanje već na nivou bliskom administratorima.
Ovdje sam pokušao prikazati horor priču za programere, jer su oni naši direktni klijenti baza podataka i moraju razumjeti do čega i do čega vode. Nadam se da sam uspeo. Hvala vam na pažnji!
Vaša pitanja
Hvala na izvještaju! Govorili ste o tome kako se problemi mogu identifikovati. Kako ih se može upozoriti? Odnosno, imao sam situaciju da su zahtjevi visili ne samo zato što su se obraćali nekim eksternim servisima. To su bili samo neki divlji spojevi. Bilo je nekih sićušnih, bezazlenih zahtjeva koji su se motali po jedan dan, a onda su počeli raditi neke gluposti. To jest, veoma je slično onome što opisujete. Kako to pratiti? Sjedite i stalno gledajte, koji zahtjev je zapeo? Kako se to može spriječiti?
U ovom slučaju, ovo je zadatak za administratore vaše kompanije, a ne nužno za DBA.
Ja sam administrator.
PostgreSQL ima pogled nazvan pg_stat_activity koji prikazuje upite na čekanju. I možete vidjeti koliko dugo tamo visi.
Moram da dođem svakih 5 minuta i pogledam?
Postavite cron i provjerite. Ako imate dug zahtjev, napišite pismo i to je to. Odnosno, ne morate gledati svojim očima, ovo se može automatizirati. Dobićete pismo, odgovorite na njega. Ili možete pucati automatski.
Postoje li jasni razlozi zašto se to dešava?
Naveo sam neke. Drugi složeniji primjeri. I može biti dugačak razgovor.
Hvala na izvještaju! Htio sam pojasniti uslužni program pg_repack. Ako nije potrebno ekskluzivno zaključavanje, onda...
Ona pravi ekskluzivnu bravu.
... tada bih potencijalno mogao izgubiti podatke. Zar moja aplikacija ne bi trebala ništa snimati u ovom trenutku?
Ne, radi tiho sa stolom, tj. pg_repack prvo prenosi sve žive linije koje su tamo. Naravno, postoji neka vrsta zapisa u tabeli. On samo baca ovaj konjski rep.
Odnosno, da li to i dalje radi na kraju?
Na kraju, potrebno je ekskluzivno zaključavanje zamjene ovih datoteka.
Hoće li biti brže od VACUUM FULL?
VACUUM FULL, kao što je počeo, odmah je preuzeo ekskluzivnu bravu. I dok ne uradi sve, neće je pustiti. A pg_repack preuzima ekskluzivno zaključavanje samo u vrijeme zamjene datoteka. U ovom trenutku ne pišete tamo, ali podaci neće biti izgubljeni, sve će biti u redu.
Zdravo! Govorili ste o radu autovakuma. Postojao je grafikon sa crvenim, žutim i zelenim ćelijama zapisa. Odnosno žute - označio ih je kao izbrisane. I kao rezultat toga, možete napisati nešto novo u njima?
Da. Postgres ne uklanja redove. On ima takvu specifičnost. Ako smo ažurirali liniju, staru smo označili kao izbrisanu. Transakcioni ID koji je promijenio ovu liniju dolazi gore, a mi pišemo novi red. I imamo sesije koje ih potencijalno mogu pročitati. U nekom trenutku postanu prilično stari. A suština autovakuma je da on prolazi kroz ove linije i označava ih kao nepotrebne. I tu možete prepisati podatke.
Razumijem. Ali pitanje nije u tome. Nisam se složio. Recimo da imamo sto. Ima polja promjenjive veličine. A ako pokušam da ubacim nešto novo, možda jednostavno neće stati u staru ćeliju.
Ne, tu je u svakom slučaju cijela linija ažurirana. Postgres ima dva modela skladištenja. On bira iz vrste podataka. Postoje podaci koji se pohranjuju direktno u tablicu, a postoje i tos podaci. To su velike količine podataka: tekst, json. Čuvaju se u zasebnim tabletama. I po ovim tabletama se dešava ista priča sa nadimanjem, odnosno sve je isto. Oni su samo posebno navedeni.
Hvala na izvještaju! Koliko je prihvatljivo koristiti zahtjeve za timeout izraza za ograničenje trajanja?
Vrlo prihvatljivo. Koristimo ga svuda. A kako nemamo svoje servise, pružamo podršku na daljinu, klijenti su dosta raznoliki. I svi su sa ovim poprilično zadovoljni. To jest, imamo poslove u cron-u koji provjeravaju. Samo što se trajanje seansi dogovara sa klijentom, pre čega ne zakucavamo. Može biti minut, može biti 10 minuta. Zavisi od opterećenja baze i njene namjene. Ali svi koristimo pg_stat_activity.
Hvala na izvještaju! Pokušavam isprobati vaš izvještaj za svoje aplikacije. I čini se da svuda započinjemo transakciju i svuda je eksplicitno završavamo. Ako je neki izuzetak, onda dolazi do istog vraćanja. A onda sam pomislio. Na kraju krajeva, transakcija može započeti ne eksplicitno. Ovo je nagoveštaj devojci, pretpostavljam. Ako samo izvršim ažuriranje zapisa, da li će transakcija početi u PostgreSQL-u i završiti tek kada se veza prekine?
Ako sada govorite o nivou aplikacije, onda to zavisi od drajvera koji koristite, od ORM-a koji se koristi. Postoji mnogo podešavanja. Ako imate omogućeno automatsko urezivanje, onda transakcija počinje tamo i odmah se zatvara.
Odnosno, zatvara se odmah nakon ažuriranja?
Zavisi od postavki. Nazvao sam jednu postavku. Ovo je uključeno automatsko urezivanje. Ona je prilično česta. Ako je omogućeno, transakcija je otvorena i zatvorena. Osim ako niste eksplicitno rekli "pokreni transakciju" i "završi transakciju", ali jednostavno pokrenuli zahtjev u sesiju.
Zdravo! Hvala na izvještaju! Zamislite da imamo bazu podataka koja raste i raste, a onda serveru ponestane prostora. Postoje li neki alati za rješavanje ove situacije?
Mjesto na serveru na dobar način treba pratiti.
Na primjer, DBA je otišao da pije čaj, bio je u odmaralištu itd.
Kada se kreira sistem datoteka, stvara se barem dio rezervnog prostora gdje podaci nisu upisani.
Šta ako je potpuno nula?
Tamo se to zove rezervisani prostor, odnosno može se osloboditi, a u zavisnosti od toga koliko je napravljen, dobijate slobodan prostor. Podrazumevano, ne znam koliko ih ima. A u drugom slučaju, isporučite diskove tako da imate gdje da izvršite operaciju oporavka. Možete obrisati neku tabelu za koju je garantovano da vam neće trebati.
Postoje li drugi alati?
Uvek je ručno rađeno. I na mestu se otkriva šta je tu bolje uraditi, jer postoje podaci koji su kritični, postoje nekritični. A za svaku bazu podataka i aplikaciju koja radi s njom, ovisi o poslu. Uvek se odlučuje na licu mesta.
Hvala na izvještaju! Imam dva pitanja. Prvo ste pokazali slajdove na kojima je pokazano da u slučaju obješenih transakcija raste i količina prostora tablice i veličina indeksa. I dalje u izvještaju postoji gomila uslužnih programa koji pakuju tablet. A šta je sa indeksom?
I njih pakuju.
Ali vakuum ne utiče na indeks?
Neki rade sa indeksom. Na primjer pg_rapack, pgcompacttable. Vakum ponovo stvara indekse, utiče na njih. VACUUM FULL ima suštinu prepisivanja svega, tj. radi sa svima.
I drugo pitanje. Nisam razumio zašto izvještaji o replikama toliko zavise od same replikacije. Činilo mi se da se izvještaji čitaju, a replikacija piše.
Šta uzrokuje konflikt replikacije? Imamo Učitelja na kojem se odvijaju procesi. Imamo autovakuum. Autovakuum u stvari, šta radi? On izrezuje neke stare linije. Ako u ovom trenutku imamo zahtjev na replici koja čita ove stare redove, a na Masteru je došlo do situacije da je autovakuum označio ove redove kao moguće za prepisivanje, onda smo ih prepisali. I primili smo paket podataka, kada moramo prepisati linije koje su potrebne zahtjevu na repliku, tada će proces replikacije čekati vremensko ograničenje koje ste konfigurirali. A onda će PostgreSQL odlučiti šta mu je važnije. A replikacija mu je važnija od zahtjeva, i on će snimiti zahtjev da se te promjene izvrše na replici.
Andrew, imam pitanje. Ove divne grafike koje ste pokazali tokom prezentacije, da li je ovo rezultat nekog vašeg rada? Kako su napravljene karte?
Ovo je usluga .
Je li ovo komercijalni proizvod?
Da. Ovo je komercijalni proizvod.
izvor: www.habr.com