Ek stel voor jy lees die transkripsie van die verslag van die begin van 2016 deur Andrey Salnikov "Tipiese foute in toepassings wat lei tot opblaas in postgresql"
In hierdie verslag sal ek die vernaamste foute in toepassings ontleed wat ontstaan tydens die ontwerp en skryf van toepassingskode. En ek sal net daardie foute neem wat lei tot opblaas in Postgresql. As 'n reël is dit die begin van die einde van die werkverrigting van u stelsel as geheel, hoewel aanvanklik geen voorvereistes hiervoor sigbaar was nie.
Bly om almal te verwelkom! Hierdie verslag is nie so tegnies soos die vorige een van my kollega nie. Hierdie verslag is hoofsaaklik gemik op backend-stelselontwikkelaars omdat ons 'n redelike groot aantal kliënte het. En hulle maak almal dieselfde foute. Ek sal jou van hulle vertel. Ek sal verduidelik tot watter fatale en slegte dinge hierdie foute lei.
Hoekom word foute gemaak? Dit word om twee redes gedoen: lukraak, miskien sal dit uitwerk en as gevolg van onkunde van sommige meganismes wat op die vlak tussen die databasis en die toepassing voorkom, sowel as in die databasis self.
Ek sal vir jou drie voorbeelde gee met verskriklike prentjies van hoe sleg dinge geraak het. Ek sal jou kortliks vertel van die meganisme wat daar gebeur. En hoe om hulle te hanteer, wanneer dit gebeur het, en watter voorkomende metodes om te gebruik om foute te voorkom. Ek sal jou vertel van die hulpgereedskap en nuttige skakels verskaf.
Ek het 'n toetsdatabasis gebruik waar ek twee tabelle gehad het. Een bord met kliënterekeninge, die ander met transaksies op hierdie rekeninge. En met 'n mate van frekwensie dateer ons die saldo's op hierdie rekeninge op.
Aanvanklike data van die bord: dit is redelik klein, 2 MB. Die reaksietyd vir die databasis en spesifiek vir die teken is ook baie goed. En 'n redelike goeie vrag - 2 000 bewerkings per sekonde volgens die bord.
En deur hierdie verslag sal ek vir jou grafieke wys sodat jy duidelik kan verstaan wat aan die gebeur is. Daar sal altyd 2 skyfies met grafieke wees. Die eerste skyfie is wat in die algemeen op die bediener gebeur.
En in hierdie situasie sien ons dat ons regtig 'n klein teken het. Die indeks is klein op 2 MB. Dit is die eerste grafiek aan die linkerkant.
Die gemiddelde reaksietyd op die bediener is ook stabiel en kort. Dit is die grafiek regs bo.
Die grafiek links onder toon die langste transaksies. Ons sien dat transaksies vinnig afgehandel word. En die outovakuum werk nog nie hier nie, want dit was 'n begintoets. Dit sal aanhou werk en sal vir ons nuttig wees.
Die tweede skyfie sal altyd toegewy wees aan die plaat wat getoets word. In hierdie situasie werk ons voortdurend die kliënt se rekeningsaldo's op. En ons sien dat die gemiddelde reaksietyd vir 'n opdatering redelik goed is, minder as 'n millisekonde. Ons sien dat verwerkerhulpbronne (dit is die grafiek regs bo) ook eweredig en redelik klein verbruik word.
Die grafiek onderaan regs wys hoeveel bedryfs- en skyfgeheue ons deurgaan op soek na ons gewenste lyn voordat ons dit opdateer. En die aantal bewerkings volgens die teken is 2 000 per sekonde, soos ek aan die begin gesê het.
En nou het ons 'n tragedie. Om een of ander rede is daar 'n lang vergete transaksie. Die redes is gewoonlik almal banaal:
- Een van die algemeenste is dat ons toegang tot 'n eksterne diens in die toepassingskode begin kry het. En hierdie diens antwoord ons nie. Dit wil sê, ons het 'n transaksie oopgemaak, 'n verandering in die databasis gemaak en van die toepassing gegaan om pos te lees of na 'n ander diens binne ons infrastruktuur, en om een of ander rede reageer dit nie op ons nie. En ons sessie sit vas in 'n toestand waar dit onbekend is wanneer dit opgelos sal word.
- Die tweede situasie is wanneer 'n uitsondering om een of ander rede in ons kode voorgekom het. En in die uitsondering het ons nie die sluiting van die transaksie verwerk nie. En ons het geëindig met 'n hangsessie met 'n oop transaksie.
- En die laaste een is ook 'n redelik algemene geval. Dit is lae kwaliteit kode. Sommige raamwerke maak 'n transaksie oop. Dit hang, en jy weet dalk nie in die toepassing dat jy dit hang nie.
Waarheen lei sulke dinge?
Tot die punt dat ons tabelle en indekse dramaties begin swel. Dit is presies dieselfde opblaas effek. Vir die databasis sal dit beteken dat die databasisreaksietyd baie skerp sal toeneem en die las op die databasisbediener sal toeneem. En gevolglik sal ons aansoek daaronder ly. Want as jy 10 millisekondes in jou kode spandeer het op 'n versoek aan die databasis, 10 millisekondes aan jou logika, dan het jou funksie 20 millisekondes geneem om te voltooi. En nou sal jou situasie baie hartseer wees.
En kom ons kyk wat gebeur. Die grafiek links onder wys dat ons 'n lang lang transaksie het. En as ons na die grafiek links bo kyk, sien ons dat die grootte van ons tabel skielik van twee megagrepe tot 300 megagrepe gespring het. Terselfdertyd het die hoeveelheid data in die tabel nie verander nie, dit wil sê daar is 'n redelike groot hoeveelheid vullis daar.
Die algemene situasie rakende die gemiddelde bedienerreaksietyd het ook met verskeie grootteordes verander. Dit wil sê, alle versoeke op die bediener het heeltemal begin daal. En terselfdertyd is interne Postgres-prosesse van stapel gestuur in die vorm van outovakuum, wat probeer om iets te doen en hulpbronne verbruik.
Wat gaan aan met ons teken? Dieselfde. Ons gemiddelde reaksietyd volgens die teken het verskeie ordes van grootte gestyg. Spesifiek in terme van verbruikte hulpbronne, sien ons dat die las op die verwerker baie toegeneem het. Dit is die grafiek regs bo. En dit het toegeneem omdat die verwerker deur 'n klomp nuttelose lyne moet sorteer op soek na die een wat nodig is. Dit is die grafiek regs onder. En gevolglik het ons aantal oproepe per sekonde baie aansienlik begin daal, omdat die databasis nie tyd gehad het om dieselfde aantal versoeke te verwerk nie.
Ons moet terugkom na die lewe. Ons gaan aanlyn en vind uit dat lang transaksies tot probleme lei. Ons vind en maak hierdie transaksie dood. En alles word vir ons normaal. Alles werk soos dit moet.
Ons het kalmeer, maar na 'n rukkie begin ons agterkom dat die toepassing nie op dieselfde manier werk as voor die noodgeval nie. Versoeke word steeds stadiger en aansienlik stadiger verwerk. Een en 'n half tot twee keer stadiger spesifiek in my voorbeeld. Die las op die bediener is ook hoër as wat dit voor die ongeluk was.
En die vraag: "Wat gebeur op hierdie oomblik met die basis?" En die volgende situasie vind plaas met die basis. Op die transaksiegrafiek kan jy sien dat dit gestop het en daar werklik geen langtermyntransaksies is nie. Maar die grootte van die teken het noodlottig toegeneem tydens die ongeluk. En sedertdien het hulle nie verminder nie. Die gemiddelde tyd op die basis het gestabiliseer. En die antwoorde kom blykbaar voldoende teen 'n spoed wat vir ons aanvaarbaar is. Die outovakuum het meer aktief geraak en iets met die bord begin doen, want dit moet deur meer data sif.
Spesifiek, volgens die toetsplaat met rekeninge, waar ons saldo's verander: die reaksietyd vir 'n versoek lyk asof dit na normaal teruggekeer het. Maar in werklikheid is dit een en 'n half keer hoër.
En uit die las op die verwerker, sien ons dat die las op die verwerker nie teruggekeer het na die vereiste waarde voor die ongeluk nie. En die redes daar lê juis in die onderste regtergrafiek. Dit kan gesien word dat 'n sekere hoeveelheid geheue daar deursoek word. Dit wil sê, om die vereiste lyn te vind, mors ons die hulpbronne van die databasisbediener terwyl ons nuttelose data sorteer. Die aantal transaksies per sekonde het gestabiliseer.
Oor die algemeen goed, maar die situasie is erger as wat dit was. Duidelike databasisagteruitgang as gevolg van ons toepassing wat met hierdie databasis werk.
En om te verstaan wat daar aangaan, as jy nie by die vorige verslag was nie, laat ons nou 'n bietjie teorie kry. Teorie oor die interne proses. Hoekom 'n motorstofsuier en wat doen dit?
Letterlik kortliks vir begrip. Een of ander tyd het ons 'n tafel. Ons het rye in die tabel. Hierdie lyne kan aktief wees, lewendig, en wat ons nou nodig het. Hulle is in die prentjie in groen gemerk. En daar is spertye wat reeds uitgewerk is, opgedateer is en nuwe inskrywings daarop verskyn het. En hulle is gemerk dat hulle nie meer interessant is vir die databasis nie. Maar hulle is in die tabel as gevolg van 'n Postgres-funksie.
Hoekom het jy 'n motorstofsuier nodig? Op 'n sekere punt kom die outovakuum, kry toegang tot die databasis en vra dit: "Gee my asseblief die ID van die oudste transaksie wat tans in die databasis oop is." Die databasis gee hierdie id terug. En die outovakuum, op grond daarvan, sorteer deur die lyne in die tabel. En as hy sien dat sommige lyne deur baie ouer transaksies verander is, dan het hy die reg om dit te merk as lyne wat ons in die toekoms kan hergebruik deur nuwe data daar te skryf. Dit is 'n agtergrondproses.
Op hierdie tydstip gaan ons voort om met die databasis te werk en gaan voort om 'n paar veranderinge aan die tabel aan te bring. En op hierdie lyne, wat ons kan hergebruik, skryf ons nuwe data. En so kry ons 'n siklus, dit wil sê die hele tyd verskyn 'n paar dooie ou lyne daar, in plaas daarvan skryf ons nuwe lyne neer wat ons nodig het. En dit is 'n normale toestand vir PostgreSQL om te werk.
Wat het tydens die ongeluk gebeur? Hoe het hierdie proses daar gebeur?
Ons het 'n teken in een of ander toestand gehad, sommige lewendig, sommige doodlyne. Die motor stofsuier het opgedaag. Hy het die databasis gevra wat ons oudste transaksie is en wat die ID is. Ek het hierdie ID ontvang, wat baie ure gelede kan wees, miskien tien minute gelede. Dit hang af van hoe swaar die las jy op jou databasis het. En hy het lyne gaan soek wat hy as hergebruik kan merk. En ek het nie sulke lyne in ons tabel gekry nie.
Maar in hierdie tyd gaan ons voort om met die tafel te werk. Ons doen iets daarin, werk dit op, verander die data. Wat moet die databasis op hierdie tydstip doen? Sy het geen ander keuse as om nuwe reëls aan die einde van die bestaande tabel te voeg nie. En so begin ons tafelgrootte swel.
In werklikheid het ons groen lyne nodig om te werk. Maar tydens so 'n probleem blyk dit dat die persentasie groen lyne deur die hele tabel uiters laag is.
En wanneer ons 'n navraag uitvoer, moet die databasis deur al die lyne gaan: beide rooi en groen, om die verlangde lyn te vind. En die effek van die opblaas van 'n tafel met nuttelose data word "bloat" genoem, wat ook ons skyfspasie opvreet. Onthou, dit was 2 MB, dit het 300 MB geword? Verander nou megagrepe na gigagrepe en jy sal vinnig al jou skyfhulpbronne verloor.
Watter gevolge kan daar vir ons wees?
- In my voorbeeld het die tabel en indeks 150 keer gegroei. Sommige van ons kliënte het meer noodlottige gevalle gehad toe hulle eenvoudig begin om te raak van skyfspasie.
- Die grootte van die tafels self sal nooit afneem nie. Outovakuum kan in sommige gevalle die stert van die tafel afsny as daar net doodlyne is. Maar aangesien daar konstante rotasie is, kan een groen lyn aan die einde vries en nie opgedateer word nie, terwyl al die ander iewers aan die begin van die plaat neergeskryf sal word. Maar dit is so 'n onwaarskynlike gebeurtenis dat jou tafel self in grootte sal krimp, so jy moet nie daarvoor hoop nie.
- Die databasis moet deur 'n hele klomp nuttelose lyne sorteer. En ons mors skyfhulpbronne, ons mors verwerkerhulpbronne en elektrisiteit.
- En dit raak ons toepassing direk, want as ons aan die begin 10 millisekondes aan die versoek spandeer het, 10 millisekondes aan ons kode, dan het ons tydens die ongeluk 'n sekonde aan die versoek begin spandeer en 10 millisekondes aan die kode, dit wil sê 'n bestelling van omvang in toepassingsprestasie het afgeneem. En toe die ongeluk opgelos is, het ons 20 millisekondes aan 'n versoek begin spandeer, 10 millisekondes aan 'n kode. Dit beteken dat ons steeds een en 'n half keer in produktiwiteit gedaal het. En dit is alles as gevolg van een transaksie wat gevries het, miskien deur ons skuld.
- En die vraag: “Hoe kan ons alles terugkry?” sodat alles reg is met ons en versoeke so vinnig inkom soos voor die ongeluk.
Vir hierdie doel is daar 'n sekere siklus van werk wat uitgevoer word.
Eerstens moet ons die problematiese tabelle vind wat opgeblase is. Ons verstaan dat in sommige tabelle die opname meer aktief is, in ander minder aktief. En hiervoor gebruik ons die uitbreiding . Deur hierdie uitbreiding te installeer, kan jy navrae skryf wat jou sal help om tabelle te vind wat redelik opgeblase is.
Sodra jy hierdie tabelle gevind het, moet jy dit saamdruk. Daar is reeds gereedskap hiervoor. In ons maatskappy gebruik ons drie gereedskap. Die eerste is die ingeboude VAKUUM VOL. Hy is wreed, hard en genadeloos, maar soms is hy baie nuttig. и - Dit is derdeparty-hulpprogramme om tabelle saam te druk. En hulle hanteer die databasis versigtiger.
Hulle word gebruik afhangende van wat vir jou geriefliker is. Maar ek sal jou heel aan die einde hiervan vertel. Die belangrikste ding is dat daar drie gereedskap is. Daar is baie om van te kies.
Nadat ons alles reggemaak het en seker gemaak het dat alles reg is, moet ons weet hoe om hierdie situasie in die toekoms te voorkom:
- Dit kan redelik maklik voorkom word. U moet die duur van sessies op die Meesterbediener monitor. Veral gevaarlike sessies in ledig in transaksietoestand. Dit is diegene wat net 'n transaksie oopgemaak het, iets gedoen het en weg is, of bloot gehang het, in die kode verdwaal het.
- En vir jou, as ontwikkelaars, is dit belangrik om jou kode te toets wanneer hierdie situasies opduik. Dit is nie moeilik om te doen nie. Dit sal 'n nuttige tjek wees. Jy sal 'n groot aantal "kinderlike" probleme wat met lang transaksies verband hou, vermy.
In hierdie grafieke wou ek jou wys hoe die teken en die gedrag van die databasis verander het nadat ek in hierdie geval die teken met VACUUM FULL deurgegaan het. Dit is nie vir my produksie nie.
Die tabelgrootte het onmiddellik teruggekeer na sy normale bedryfstoestand van 'n paar megagrepe. Dit het nie die gemiddelde reaksietyd vir die bediener grootliks beïnvloed nie.
Maar spesifiek vir ons toetsteken, waar ons rekeningsaldo's opgedateer het, sien ons dat die gemiddelde reaksietyd vir 'n versoek om data in die teken by te werk, verminder is tot voornoodvlakke. Die hulpbronne wat deur die verwerker verbruik is om hierdie versoek te voltooi, het ook tot voor-ongelukvlakke gedaal. En die onderste regterkantse grafiek wys dat ons nou presies die lyn vind wat ons dadelik nodig het, sonder om deur die stapels dooie lyne te gaan wat daar was voordat die tabel saamgepers is. En die gemiddelde versoektyd het op ongeveer dieselfde vlak gebly. Maar hier het ek eerder 'n fout in my hardeware.
Dit is waar die eerste storie eindig. Dit is die algemeenste. En dit gebeur met almal, ongeag die kliënt se ervaring en hoe gekwalifiseerd die programmeerders is. Vroeër of later gebeur dit.
Die tweede storie, waarin ons die vrag versprei en bedienerhulpbronne optimaliseer
- Ons het reeds grootgeword en ernstige ouens geword. En ons verstaan dat ons 'n replika het en dit sal goed wees vir ons om die las te balanseer: skryf aan die Meester, en lees uit die replika. En gewoonlik ontstaan hierdie situasie wanneer ons 'n paar verslae of ETL wil voorberei. En besigheid is baie bly hieroor. Hy wil regtig 'n verskeidenheid verslae hê met baie komplekse ontledings.
- Verslae neem baie ure, want komplekse analise kan nie in millisekondes bereken word nie. Ons, soos dapper ouens, skryf kode. In die invoegtoepassing maak ons die opname op die Meester, en voer die verslae op die replika uit.
- Die verspreiding van die vrag.
- Alles werk perfek. Ons is puik.
En hoe lyk hierdie situasie? Spesifiek op hierdie grafieke het ek ook die tydsduur van transaksies vanaf die replika vir die transaksieduur bygevoeg. Alle ander grafieke verwys slegs na die Meesterbediener.
Teen hierdie tyd het my rapportraad gegroei. Daar is meer van hulle. Ons sien dat die gemiddelde bedienerreaksietyd stabiel is. Ons sien dat ons op die replika 'n langlopende transaksie het wat vir 2 uur duur. Ons sien die stil werking van die outovakuum, wat doodlyne verwerk. En alles is goed met ons.
Spesifiek, volgens die getoetste plaat, gaan ons voort om rekeningsaldo's daar op te dateer. En ons het ook 'n stabiele reaksietyd vir versoeke, stabiele hulpbronverbruik. Alles is goed met ons.
Alles is in orde tot die oomblik dat hierdie verslae begin terugvuur as gevolg van 'n konflik met replikasie. En hulle vuur met gereelde tussenposes terug.
Ons gaan aanlyn en begin lees hoekom dit gebeur. En ons vind 'n oplossing.
Die eerste oplossing is om die vertraging van replikasie te verhoog. Ons weet dat ons verslag vir 3 uur loop. Ons stel die replikasievertraging op 3 uur. Ons stel alles bekend, maar ons ondervind steeds probleme met verslae wat soms gekanselleer word.
Ons wil hê alles moet perfek wees. Ons klim verder. En ons het 'n koel omgewing op die internet gevind - hot_standby_feedback. Kom ons skakel dit aan. Hot_standby_feedback stel ons in staat om die outovakuum op die Meester terug te hou. Sodoende raak ons heeltemal ontslae van replikasiekonflikte. En alles werk goed vir ons met verslae.
En wat gebeur tans met die Meesterbediener? En ons is in totale moeilikheid met die Meesterbediener. Nou sien ons die grafieke wanneer ek albei hierdie instellings geaktiveer het. En ons sien dat die sessie op ons replika op een of ander manier die situasie op die Meesterbediener begin beïnvloed het. Sy het wel 'n effek omdat sy die outovakuum onderbreek het, wat die doodlyne uitvee. Ons tafelgrootte het weer die hoogte ingeskiet. Die gemiddelde navraaguitvoeringstyd oor die hele databasis het ook die hoogte ingeskiet. Die autovacuums het 'n bietjie verskerp.
Spesifiek, vanaf ons bord, sien ons dat die data-opdatering daarop ook na die lug gespring het. SVE-verbruik het insgelyks baie toegeneem. Ons gaan weer deur 'n groot aantal dooie, nuttelose lyne. En die reaksietyd vir hierdie teken en die aantal transaksies het gedaal.
Hoe sal dit lyk as ons nie weet waarvan ek voorheen gepraat het nie?
- Ons begin soek na probleme. As ons probleme ondervind het in die eerste deel, weet ons dat dit dalk te wyte is aan 'n lang transaksie en gaan na die Meester. Ons het 'n probleem met die Meester. Wors hom. Dit word warm, sy lasgemiddelde is ongeveer honderd.
- Versoeke daar is stadig, maar ons sien geen langlopende transaksies daar nie. En ons verstaan nie wat die saak is nie. Ons verstaan nie waar om te kyk nie.
- Ons gaan bedienertoerusting na. Miskien het ons klopjag neergestort. Miskien is ons geheuestokkie uitgebrand. Ja, enigiets kan gebeur. Maar nee, die bedieners is nuut, alles werk goed.
- Almal hardloop: administrateurs, ontwikkelaars en die direkteur. Niks help nie.
- En op 'n stadium begin alles skielik regmaak.
Op hierdie tydstip is die versoek op ons replika verwerk en gelaat. Ons het die verslag ontvang. Besigheid is steeds gelukkig. Soos julle kan sien, het ons teken weer gegroei en gaan dit nie krimp nie. Op die grafiek met sessies het ek 'n stukkie van hierdie lang transaksie van 'n replika gelos sodat jy kan skat hoe lank dit neem totdat die situasie stabiliseer.
Die sessie is verby. En eers na 'n rukkie kom die bediener min of meer in orde. En die gemiddelde reaksietyd vir versoeke op die Meesterbediener keer terug na normaal. Want uiteindelik het die outovakuum die geleentheid om hierdie doodlyne skoon te maak en te merk. En hy het sy werk begin doen. En hoe vinnig hy dit doen, so vinnig sal ons in orde kom.
Volgens die getoetste tablet, waar ons rekeningsaldo's opdateer, sien ons presies dieselfde prentjie. Die gemiddelde rekeningopdateringstyd is ook geleidelik besig om te normaliseer. Die hulpbronne wat deur die verwerker verbruik word, word ook verminder. En die aantal transaksies per sekonde keer terug na normaal. Maar weer is ons terug na normaal, nie dieselfde as wat ons voor die ongeluk was nie.
Ons kry in elk geval 'n prestasievermindering, soos in die eerste geval, een en 'n half tot twee keer, en soms meer.
Dit lyk asof ons alles reg gedoen het. Verdeel die vrag. Die toerusting is nie ledig nie. Ons het die versoeke volgens ons verstand verdeel, maar steeds het alles sleg uitgedraai.
- Moenie warm_standby_terugvoer aktiveer nie? Ja, dit word nie aanbeveel om dit aan te skakel sonder besonder sterk redes nie. Omdat hierdie draai direk die Meesterbediener raak en die werking van die outovakuum daar opskort. Deur dit op een of ander replika te aktiveer en daarvan te vergeet, kan jy die Meester doodmaak en groot probleme met die toepassing kry.
- Verhoog maksimum_standby_streaming_delay? Ja, vir verslae is dit waar. As u 'n verslag van drie uur het en u wil nie hê dit moet ineenstort as gevolg van replikasiekonflikte nie, verhoog dan eenvoudig die vertraging. 'n Langtermynverslag vereis nooit data wat nou in die databasis aangekom het nie. As jy dit vir drie uur het, loop jy dit vir 'n ou dataperiode. En vir jou, of daar 'n vertraging van drie uur of 'n vertraging van ses uur is, sal geen verskil maak nie, maar jy sal konsekwent verslae ontvang en sal geen probleme ondervind dat hulle val nie.
- Natuurlik moet jy lang sessies op replikas beheer, veral as jy besluit om warm_standby_terugvoer op 'n replika te aktiveer. Want enigiets kan gebeur. Ons het hierdie replika aan die ontwikkelaar gegee sodat hy die navrae kon toets. Hy het 'n mal versoek geskryf. Hy het dit geloods en gaan tee drink, en ons het die gevestigde Meester gekry. Of dalk plaas ons die verkeerde toepassing daar. Die situasies is uiteenlopend. Sessies op replikas moet so noukeurig gemonitor word as op die Meester.
- En as u vinnige en lang navrae oor replikas het, is dit in hierdie geval beter om dit te verdeel om die vrag te versprei. Dit is 'n skakel na streaming_delay. Vir vinniges, het een replika met 'n klein replikasie vertraging. Vir langdurige verslagdoeningversoeke, het 'n replika wat met 6 uur of 'n dag kan vertraag. Dit is 'n heeltemal normale situasie.
Ons skakel die gevolge op dieselfde manier uit:
- Ons vind opgeblase tafels.
- En ons druk dit saam met die gerieflikste hulpmiddel wat ons pas.
Die tweede verhaal eindig hier. Kom ons gaan aan na die derde verhaal.
Ook redelik algemeen vir ons waarin ons migrasie doen.
- Enige sagtewareproduk groei. Die vereistes daarvoor is besig om te verander. Ons wil in elk geval ontwikkel. En dit gebeur dat ons die data in die tabel moet opdateer, naamlik om 'n opdatering in terme van ons migrasie uit te voer vir die nuwe funksionaliteit wat ons as deel van ons ontwikkeling bekendstel.
- Die ou dataformaat is nie bevredigend nie. Kom ons sê ons gaan nou na die tweede tabel, waar ek transaksies op hierdie rekeninge het. En kom ons sê dat hulle in roebels was, en ons het besluit om die akkuraatheid te verhoog en dit in kopecks te doen. En hiervoor moet ons 'n opdatering maak: vermenigvuldig die veld met die transaksiebedrag met honderd.
- In vandag se wêreld gebruik ons outomatiese databasisweergawebeheernutsgoed. Kom ons sê . Ons registreer ons migrasie daarheen. Ons toets dit op ons toetsbasis. Alles is reg. Die opdatering gaan deur. Dit blokkeer werk vir 'n rukkie, maar ons kry opgedateerde data. En ons kan nuwe funksionaliteit hieroor bekendstel. Alles is getoets en nagegaan. Alles is bevestig.
- Ons het beplande werk uitgevoer en migrasie uitgevoer.
Hier is die migrasie met die opdatering wat voor u aangebied word. Aangesien dit my rekeningtransaksies is, was die plaat 15 GB. En aangesien ons elke reël opdateer, het ons die grootte van die tabel verdubbel met die opdatering, want ons het elke reël herskryf.
Tydens die migrasie kon ons niks met hierdie plaat doen nie, want alle versoeke daarvoor is in tou gesit en gewag totdat hierdie opdatering voltooi is. Maar hier wil ek jou aandag vestig op die getalle wat op die vertikale as is. Dit wil sê, ons het 'n gemiddelde versoektyd voor migrasie van ongeveer 5 millisekondes en die verwerkerlading, die aantal blokbewerkings vir die lees van skyfgeheue is minder as 7,5.
Ons het die migrasie uitgevoer en weer probleme gekry.
Die migrasie was suksesvol, maar:
- Die ou funksionaliteit neem nou langer om te voltooi.
- Die tafel het weer groot geword.
- Die las op die bediener het weer groter geword as voorheen.
- En natuurlik peuter ons steeds aan die funksionaliteit wat goed gewerk het, ons het dit 'n bietjie verbeter.
En dit is weer opblaas, wat weer ons lewens verwoes.
Hier demonstreer ek dat die tabel, soos die vorige twee gevalle, nie na sy vorige groottes gaan terugkeer nie. Die gemiddelde bedienerlading blyk voldoende te wees.
En as ons na die tabel met rekeninge draai, sal ons sien dat die gemiddelde versoektyd vir hierdie tabel verdubbel het. Die las op die verwerker en die aantal lyne wat in die geheue uitgesorteer is, het bo 7,5 gespring, maar was laer. En dit het 2 keer gespring in die geval van verwerkers, 1,5 keer in die geval van blokbewerkings, dit wil sê ons het 'n agteruitgang in bedienerwerkverrigting gekry. En as gevolg daarvan - agteruitgang van die prestasie van ons toepassing. Terselfdertyd het die aantal oproepe ongeveer op dieselfde vlak gebly.
En die belangrikste ding hier is om te verstaan hoe om sulke migrasies korrek te doen. En hulle moet gedoen word. Ons doen hierdie migrasies redelik konsekwent.
- Sulke groot migrasies gebeur nie outomaties nie. Hulle moet altyd onder beheer wees.
- Toesig deur 'n kundige persoon word vereis. As jy 'n DBA in jou span het, laat die DBA dit dan doen. Dis sy werk. Indien nie, laat dan die mees ervare persoon dit doen, wat weet hoe om met databasisse te werk.
- 'n Nuwe databasisskema, selfs al werk ons een kolom op, berei ons altyd in fases voor, dit wil sê vooraf voordat die nuwe weergawe van die toepassing ontplooi word:
- Nuwe velde word bygevoeg waarin ons die opgedateerde data sal aanteken.
- Ons dra data van die ou veld na die nuwe veld oor in klein dele. Hoekom doen ons dit? Eerstens beheer ons altyd die proses van hierdie proses. Ons weet dat ons reeds soveel groepe oorgedra het en ons het soveel oor.
- En die tweede positiewe effek is dat ons tussen elke so 'n bondel die transaksie sluit, 'n nuwe een oopmaak, en dit laat die outovakuum toe om volgens die plaat te werk, merk spertye vir hergebruik.
- Vir die lyne wat sal verskyn terwyl die toepassing loop (ons het steeds die ou toepassing aan die gang), voeg ons 'n sneller by wat nuwe waardes na nuwe velde skryf. In ons geval is dit vermenigvuldiging met honderd van die ou waarde.
- As ons heeltemal koppig is en dieselfde veld wil hê, hernoem ons eenvoudig die velde na voltooiing van alle migrasies en voordat ons 'n nuwe weergawe van die toepassing uitrol. Die oues kry een of ander uitgevind name, en die nuwe velde word hernoem na die oues.
- En eers daarna begin ons 'n nuwe weergawe van die toepassing.
En terselfdertyd sal ons nie 'n opblaas kry nie en sal nie ly in terme van prestasie nie.
Dit is waar die derde verhaal eindig.
En nou 'n bietjie meer besonderhede oor die gereedskap wat ek in die heel eerste storie genoem het.
Voordat u na bloat soek, moet u die uitbreiding installeer .
Sodat jy nie met navrae vorendag hoef te kom nie, het ons reeds hierdie navrae in ons werk geskryf. Jy kan hulle gebruik. Daar is twee versoeke hier.
- Die eerste een neem nogal lank om te werk, maar dit sal jou die presiese opblaaswaardes uit die tabel wys.
- Die tweede een werk vinniger en is baie effektief wanneer jy vinnig moet bepaal of daar 'n opblaas is of nie volgens die tabel. En jy moet ook verstaan dat opblaas altyd teenwoordig is in 'n Postgres-tabel. Dit is 'n kenmerk van sy MVCC-model.
- En 20% opblaas is normaal vir tafels in die meeste gevalle. Dit wil sê, jy moet nie bekommerd wees en hierdie tabel saamdruk nie.
Ons het uitgevind hoe om tabelle te identifiseer wat opgeswel is met nuttelose data.
Nou oor hoe om opblaas reg te stel:
- As ons 'n klein tablet en goeie skywe het, dit wil sê op 'n tablet tot 'n gigagreep, is dit heel moontlik om VACUUM FULL te gebruik. Hy sal 'n eksklusiewe slot van jou op die tafel neem vir 'n paar sekondes en goed, maar hy sal alles vinnig en hard doen. Wat doen VACUUM FULL? Dit neem 'n eksklusiewe slot op die tafel en herskryf lewendige rye van die ou tabelle na die nuwe tabel. En aan die einde vervang hy hulle. Dit verwyder ou lêers en vervang die oues met nuwes. Maar vir die duur van sy werk neem dit 'n eksklusiewe slot op die tafel. Dit beteken dat jy niks met hierdie tabel kan doen nie: nie daaraan skryf nie, ook nie daarin lees of dit verander nie. En VACUUM FULL vereis bykomende skyfspasie om data te skryf.
- Volgende instrument . In sy beginsel is dit baie soortgelyk aan VACUUM FULL, want dit herskryf ook data van ou lêers na nuwes en vervang dit in die tabel. Maar terselfdertyd neem dit nie 'n eksklusiewe slot op die tafel aan die begin van sy werk nie, maar neem dit slegs op die oomblik wanneer dit reeds gereed data het om die lêers te vervang. Sy skyfhulpbronvereistes is soortgelyk aan dié van VACUUM FULL. Jy benodig bykomende skyfspasie, en dit is soms van kritieke belang as jy teragreep-tabelle het. En dit is redelik verwerker-honger omdat dit aktief met I/O werk.
- Die derde nut is . Dit is versigtiger met hulpbronne omdat dit volgens effens verskillende beginsels werk. Die hoofgedagte van pgcompacttable is dat dit alle lewendige rye na die begin van die tabel skuif deur opdaterings in die tabel te gebruik. En dan loop dit 'n vakuum op hierdie tafel, want ons weet ons het lewendige rye aan die begin en dooie rye aan die einde. En die vakuum self sny hierdie stert af, dit wil sê dit benodig nie veel bykomende skyfspasie nie. En terselfdertyd kan dit steeds in terme van hulpbronne geknyp word.
Alles met gereedskap.
As jy die bloat-onderwerp interessant vind om verder binne te delf, is hier 'n paar nuttige skakels:
- - Dit is 'n verslag van my kollega. Dit is algemeen oor waarheen Postgres se ruimte gaan tydens sy werk en lewe. En daar is 'n baie groot en gedetailleerde tegniese stuk vir databasisadministrateurs oor bloat.
- - dit is 'n skakel na ons bewaarplek, waar ons 'n klomp nuttige skrifte stoor om die toestand van die databasis na te gaan. Daar kan jy skrifte vind om na opblaas te soek.
- и skakels na gereedskap wat jou sal help om tekens te krimp.
- – dit is 'n plasing van my kollega. Daar ontleed hy bloat baie ernstig en tegnies in detail op 'n vlak naby aan administrateurs.
Ek het meer probeer om 'n gruwelverhaal vir ontwikkelaars te wys, want hulle is ons direkte kliënte van databasisse en moet verstaan wat en waartoe aksies lei. Ek hoop ek het daarin geslaag. Dankie vir jou aandag!
vrae
Dankie vir die verslag! Jy het gepraat oor hoe jy probleme kan identifiseer. Hoe kan hulle gewaarsku word? Dit wil sê, ek het 'n situasie gehad waar versoeke gehang het nie net omdat hulle toegang tot sommige eksterne dienste verkry het nie. Dit was net 'n paar wilde joins. Daar was 'n paar klein, onskadelike versoeke wat vir 'n dag rondgehang het, en toe 'n bietjie nonsens begin doen het. Dit wil sê, baie soortgelyk aan wat jy beskryf. Hoe om dit op te spoor? Sit en kyk gedurig watter versoek vas is? Hoe kan dit voorkom word?
In hierdie geval is dit 'n taak vir die administrateurs van jou maatskappy, nie noodwendig vir die DBA nie.
Ek is 'n administrateur.
PostgreSQL het 'n aansig genaamd pg_stat_activity wat hangende navrae wys. En jy kan sien hoe lank dit daar hang.
Moet ek elke 5 minute inkom en kyk?
Stel cron op en kontroleer. As jy 'n langtermyn versoek het, skryf 'n brief en dit is dit. Dit wil sê, jy hoef nie met jou oë te kyk nie, dit kan geoutomatiseer word. Jy sal 'n brief ontvang, jy reageer daarop. Of jy kan outomaties skiet.
Is daar enige ooglopende redes waarom dit gebeur?
Ek het 'n paar gelys. Ander meer komplekse voorbeelde. En daar kan lank gesels.
Dankie vir die verslag! Ek wou duidelikheid gee oor die pg_repack-nutsding. As sy nie 'n eksklusiewe slot doen nie, dan...
Sy doen 'n eksklusiewe slot.
... dan kan ek moontlik data verloor. Moet my aansoek niks gedurende hierdie tyd opneem nie?
Nee, dit werk glad met die tabel, dit wil sê pg_repack dra eers al die lewendige lyne wat bestaan oor. Natuurlik vind daar 'n soort inskrywing in die tabel plaas. Hy gooi net hierdie poniestert uit.
Dit wil sê, hy doen dit eintlik op die ou end?
Op die ou end neem hy 'n eksklusiewe slot om hierdie lêers te ruil.
Sal dit vinniger wees as VAKUUM VOL?
VACUUM FULL, sodra dit begin het, het dadelik 'n eksklusiewe slot geneem. En totdat hy alles doen, sal hy haar nie laat gaan nie. En pg_repack neem slegs 'n eksklusiewe slot ten tyde van lêervervanging. Op hierdie oomblik sal jy nie daar skryf nie, maar die data sal nie verlore gaan nie, alles sal goed wees.
Hallo! Jy het gepraat oor die werking van 'n motorstofsuier. Daar was 'n grafiek met rooi, geel en groen opnameselle. Dit wil sê, geel - hy het hulle as geskrap gemerk. En as gevolg daarvan kan daar iets nuuts in hulle geskryf word?
Ja. Postgres vee nie lyne uit nie. Hy het so 'n spesifisiteit. As ons 'n reël opgedateer het, het ons die ou een as geskrap gemerk. Die ID van die transaksie wat hierdie reël verander het, verskyn daar, en ons skryf 'n nuwe reël. En ons het sessies wat hulle moontlik kan lees. Op 'n stadium word hulle redelik oud. En die essensie van hoe die outovakuum werk, is dat dit deur hierdie lyne gaan en dit as onnodig merk. En jy kan data daar oorskryf.
Ek verstaan. Maar dit is nie waaroor die vraag gaan nie. Ek het nie klaargemaak nie. Kom ons neem aan ons het 'n tabel. Dit het velde van veranderlike grootte. En as ek iets nuuts probeer insit, pas dit dalk eenvoudig nie in die ou sel nie.
Nee, in elk geval word die hele lyn daar opgedateer. Postgres het twee databergingsmodelle. Dit kies uit die datatipe. Daar is data wat direk in die tabel gestoor word, en daar is ook tos-data. Dit is groot hoeveelhede data: teks, json. Hulle word in aparte plate gestoor. En volgens hierdie tablette kom dieselfde storie met opblaas voor, dit wil sê alles is dieselfde. Hulle word net afsonderlik gelys.
Dankie vir die verslag! Is dit aanvaarbaar om stellinguittelnavrae te gebruik om tydsduur te beperk?
Baie aanvaarbaar. Ons gebruik dit oral. En aangesien ons nie ons eie dienste het nie, bied ons afstandondersteuning, ons het nogal 'n verskeidenheid kliënte. En almal is heeltemal tevrede hiermee. Dit wil sê, ons het cron-bane wat nagaan. Die duur van die sessies word eenvoudig met die kliënt ooreengekom, waarvoor ons nie saamstem nie. Dit kan 'n minuut wees, dit kan 10 minute wees. Dit hang af van die las op die basis en die doel daarvan. Maar ons gebruik almal pg_stat_activity.
Dankie vir die verslag! Ek probeer jou verslag op my aansoeke toepas. En dit lyk of ons oral 'n transaksie begin, en dit duidelik oral voltooi. As daar 'n uitsondering is, vind terugrol steeds plaas. En toe begin ek dink. Die transaksie mag immers nie eksplisiet begin nie. Dit is waarskynlik 'n wenk aan die meisie. As ek net 'n rekord opdateer, sal die transaksie in PostgreSQL begin en eers voltooi wanneer die verbinding ontkoppel is?
As jy nou oor die toepassingsvlak praat, hang dit af van die drywer wat jy gebruik, van die ORM wat gebruik word. Daar is baie instellings daar. As u outomatiese toewysing geaktiveer het, begin 'n transaksie daar en sluit onmiddellik.
Dit wil sê, dit sluit onmiddellik na die opdatering?
Dit hang af van die instellings. Ek het een instelling genoem. Dit is outomatiese commit aan. Dit is redelik algemeen. As dit geaktiveer is, het die transaksie geopen en gesluit. Tensy jy uitdruklik gesê het "begin transaksie" en "beëindig transaksie", maar bloot 'n versoek in die sessie geloods het.
Hallo! Dankie vir die verslag! Kom ons stel ons voor dat ons 'n databasis het wat swel en swel en dan raak die spasie op die bediener op. Is daar enige gereedskap om hierdie situasie reg te stel?
Die spasie op die bediener moet behoorlik gemonitor word.
Die DBA het byvoorbeeld gaan tee drink, was by 'n oord, ens.
Wanneer 'n lêerstelsel geskep word, word ten minste 'n soort rugsteunspasie geskep waar data nie geskryf word nie.
Wat as dit heeltemal onder nul is?
Daar word dit gereserveerde spasie genoem, dit wil sê dit kan bevry word en afhangend van hoe groot dit geskep is, kry jy vrye spasie. By verstek weet ek nie hoeveel daar is nie. En in 'n ander geval, lewer skywe sodat jy ruimte het om 'n rekonstruktiewe operasie uit te voer. Jy kan een of ander tabel uitvee wat jy gewaarborg nie sal nodig hê nie.
Is daar enige ander gereedskap?
Dit is altyd handgemaak. En plaaslik word dit duidelik wat die beste is om daar te doen, want sommige data is krities en sommige is nie-krities. En vir elke databasis en die toepassing wat daarmee werk, hang dit af van die besigheid. Dit word altyd plaaslik besluit.
Dankie vir die verslag! Ek het twee vrae. Eerstens het jy skyfies gewys wat wys dat wanneer transaksies vas is, beide die tafelspasiegrootte en die indeksgrootte groei. En verder op die berig was daar 'n klomp nutsprogramme wat die tablet verpak. Wat van die indeks?
Hulle pak hulle ook.
Maar die vakuum beïnvloed nie die indeks nie?
Sommige werk met 'n indeks. Byvoorbeeld, pg_rapack, pgcompacttable. Die vakuum herskep die indekse en beïnvloed dit. Met VACUUM FULL is die idee om alles te oorskryf, dit wil sê dit werk met almal.
En die tweede vraag. Ek verstaan nie hoekom verslae oor replikas so afhang van die replikasie self nie. Dit het vir my gelyk of verslae gelees word, en replikasie is skryf.
Wat veroorsaak 'n replikasiekonflik? Ons het 'n Meester waarop prosesse plaasvind. Ons het 'n motorstofsuier aan die gang. Wat doen 'n outovakuum eintlik? Hy sny 'n paar ou lyne uit. As ons op hierdie tydstip 'n versoek het op die replika wat hierdie ou reëls lees, en op die Meester het 'n situasie plaasgevind dat die outovakuum hierdie reëls as moontlik gemerk het vir oorskryf, dan het ons dit oorgeskryf. En ons het 'n datapakkie ontvang, wanneer ons daardie reëls wat die versoek benodig op die replika moet herskryf, sal die replikasieproses wag vir die uitteltyd wat jy opgestel het. En dan sal PostgreSQL besluit wat vir hom belangriker is. En replikasie is vir hom belangriker as die versoek, en hy sal die versoek skiet om hierdie veranderinge op die replika aan te bring.
Andrey, ek het 'n vraag. Hierdie wonderlike grafieke wat jy tydens die aanbieding gewys het, is dit die resultaat van die werk van een of ander soort nut van jou? Hoe is die grafieke gemaak?
Dit is 'n diens .
Is dit 'n kommersiële produk?
Ja. Dit is 'n kommersiële produk.
Bron: will.com