Ik stel voor dat u het transcript van het rapport van begin 2016 van Andrey Salnikov leest: “Typische fouten in applicaties die leiden tot een opgeblazen gevoel in postgresql”
In dit rapport analyseer ik de belangrijkste fouten in applicaties die zich voordoen in de fase van het ontwerpen en schrijven van applicatiecode. En ik zal alleen die fouten nemen die tot een opgeblazen gevoel in Postgresql leiden. In de regel is dit het begin van het einde van de prestaties van uw systeem als geheel, hoewel er aanvankelijk geen vereisten hiervoor zichtbaar waren.
Ik ben blij iedereen te mogen verwelkomen! Dit rapport is niet zo technisch als het vorige van mijn collega. Dit rapport is vooral gericht op ontwikkelaars van backend-systemen, omdat we een vrij groot aantal klanten hebben. En ze maken allemaal dezelfde fouten. Ik zal je over hen vertellen. Ik zal uitleggen tot welke fatale en slechte dingen deze fouten leiden.
Waarom worden er fouten gemaakt? Ze worden om twee redenen gedaan: willekeurig, misschien komt het wel goed en vanwege onwetendheid over bepaalde mechanismen die plaatsvinden op het niveau tussen de database en de applicatie, maar ook in de database zelf.
Ik zal je drie voorbeelden geven met vreselijke foto's van hoe erg het is geworden. Ik zal je kort vertellen over het mechanisme dat daar gebeurt. En hoe ermee om te gaan, wanneer ze zich voordoen en welke preventieve methoden je kunt gebruiken om fouten te voorkomen. Ik vertel je over de hulptools en geef handige links.
Ik gebruikte een testdatabase waarin ik twee tabellen had. Eén bord met klantenrekeningen, het andere met transacties op deze rekeningen. En met enige regelmaat werken we de saldi op deze rekeningen bij.
Initiële gegevens van de plaat: deze is vrij klein, 2 MB. Ook de responstijd voor de database en specifiek voor het bord is erg goed. En een redelijk goede belasting - 2 bewerkingen per seconde volgens het bord.
En via dit rapport zal ik u grafieken laten zien, zodat u duidelijk kunt begrijpen wat er gebeurt. Er zullen altijd 2 dia's met grafieken zijn. De eerste dia is wat er in het algemeen op de server gebeurt.
En in deze situatie zien we dat we echt een klein bordje hebben. De index is klein: 2 MB. Dit is de eerste grafiek aan de linkerkant.
Ook de gemiddelde responstijd op de server is stabiel en kort. Dit is de grafiek rechtsboven.
De grafiek linksonder toont de langste transacties. We zien dat transacties snel worden afgerond. En de autovacuüm werkt hier nog niet, want het was een starttest. Het zal blijven werken en nuttig voor ons zijn.
De tweede dia zal altijd gewijd zijn aan de plaat die wordt getest. In deze situatie werken we voortdurend de rekeningsaldi van de klant bij. En we zien dat de gemiddelde responstijd voor een update-operatie behoorlijk goed is, minder dan een milliseconde. We zien dat de processorbronnen (dit is de grafiek rechtsboven) ook gelijkmatig en vrij klein worden verbruikt.
De grafiek rechtsonder laat zien hoeveel werk- en schijfgeheugen we gebruiken bij het zoeken naar de gewenste lijn voordat we deze bijwerken. En het aantal bewerkingen volgens het bord is 2 per seconde, zoals ik in het begin al zei.
En nu hebben we een tragedie. Om de een of andere reden is er een lang vergeten transactie. De redenen zijn meestal allemaal banaal:
- Een van de meest voorkomende is dat we toegang hebben gekregen tot een externe service in de applicatiecode. En deze service antwoordt ons niet. Dat wil zeggen, we hebben een transactie geopend, een wijziging in de database aangebracht en zijn van de applicatie overgegaan op het lezen van e-mail of naar een andere dienst binnen onze infrastructuur, en om de een of andere reden reageert deze niet op ons. En onze sessie zit vast in een staat waarin het onbekend is wanneer deze zal worden opgelost.
- De tweede situatie is wanneer er om de een of andere reden een uitzondering in onze code is opgetreden. En in deze uitzonderingssituatie hebben we het afsluiten van de transactie niet verwerkt. En we eindigden met een hangende sessie met een open transactie.
- En dat laatste is ook een vrij veel voorkomend geval. Dit is code van lage kwaliteit. Sommige raamwerken openen een transactie. Het blijft hangen, en het kan zijn dat u in de applicatie niet weet dat het hangt.
Waar leiden zulke dingen toe?
Tot het punt dat onze tabellen en indexen dramatisch beginnen te groeien. Dit is precies hetzelfde opgeblazen effect. Voor de database betekent dit dat de responstijd van de database zeer sterk zal toenemen en de belasting van de databaseserver zal toenemen. En als gevolg daarvan zal onze applicatie eronder lijden. Want als je 10 milliseconden aan je code besteedde aan een verzoek aan de database, en 10 milliseconden aan je logica, dan duurde het 20 milliseconden om je functie te voltooien. En nu zal je situatie erg triest zijn.
En laten we kijken wat er gebeurt. De grafiek linksonder laat zien dat we een lange, lange transactie hebben. En als we naar de grafiek linksboven kijken, zien we dat de grootte van onze tabel plotseling is gestegen van twee megabytes naar 300 megabytes. Tegelijkertijd is de hoeveelheid gegevens in de tabel niet veranderd, dat wil zeggen dat er een vrij grote hoeveelheid afval is.
De algemene situatie met betrekking tot de gemiddelde serverresponstijd is ook met verschillende ordes van grootte veranderd. Dat wil zeggen dat alle verzoeken op de server volledig begonnen te verdwijnen. En tegelijkertijd werden interne Postgres-processen gelanceerd in de vorm van autovacuüm, die iets proberen te doen en middelen verbruiken.
Wat is er aan de hand met ons bord? Hetzelfde. Onze gemiddelde responstijd volgens het bord is verschillende ordes van grootte gestegen. Specifiek op het gebied van verbruikte resources zien we dat de belasting op de processor sterk is toegenomen. Dit is de grafiek rechtsboven. En het is toegenomen omdat de processor een aantal nutteloze regels moet doorzoeken op zoek naar de benodigde regel. Dit is de grafiek rechtsonder. En als gevolg daarvan begon ons aantal oproepen per seconde zeer aanzienlijk te dalen, omdat de database geen tijd had om hetzelfde aantal verzoeken te verwerken.
We moeten weer tot leven komen. We gaan online en ontdekken dat lange transacties tot problemen leiden. We vinden en beëindigen deze transactie. En voor ons wordt alles normaal. Alles werkt zoals het hoort.
We zijn gekalmeerd, maar na een tijdje beginnen we te merken dat de applicatie niet meer op dezelfde manier werkt als vóór de noodsituatie. Verzoeken worden nog steeds langzamer verwerkt, en aanzienlijk langzamer. Specifiek in mijn voorbeeld anderhalf tot twee keer langzamer. Ook is de belasting van de server hoger dan vóór het ongeval.
En de vraag: “Wat gebeurt er op dit moment met de basis?” En de volgende situatie doet zich voor met de basis. Op de transactiegrafiek kun je zien dat het is gestopt en dat er echt geen langetermijntransacties zijn. Maar de omvang van het bord nam tijdens het ongeval dodelijk toe. En sindsdien zijn ze niet minder geworden. De gemiddelde tijd op de basis is gestabiliseerd. En de antwoorden lijken adequaat te komen met een voor ons acceptabele snelheid. Het autovacuüm werd actiever en begon iets met het bord te doen, omdat het meer gegevens moet doorzoeken.
Concreet blijkt uit het proefplaatje met rekeningen, waar we saldi wijzigen: de reactietijd op een verzoek lijkt weer normaal te zijn. Maar in werkelijkheid is het anderhalf keer zo hoog.
En aan de belasting van de processor zien we dat de belasting van de processor niet is teruggekeerd naar de vereiste waarde van vóór de crash. En de redenen daar liggen precies in de grafiek rechtsonder. Je kunt zien dat daar een bepaalde hoeveelheid geheugen wordt doorzocht. Dat wil zeggen: om de vereiste regel te vinden, verspillen we de bronnen van de databaseserver terwijl we nutteloze gegevens doorzoeken. Het aantal transacties per seconde is gestabiliseerd.
Over het algemeen goed, maar de situatie is erger dan het was. Duidelijke databasedegradatie als gevolg van onze applicatie die met deze database werkt.
En om te begrijpen wat daar aan de hand is, laten we, als u niet bij het vorige rapport was, nu een beetje theorie krijgen. Theorie over het interne proces. Waarom een autostofzuiger en wat doet hij?
Letterlijk kort voor begrip. Op een gegeven moment hebben we een tafel. We hebben rijen in de tabel. Deze lijnen kunnen actief en levend zijn en wat we nu nodig hebben. Op de foto zijn ze groen gemarkeerd. En er zijn deadlines die al zijn uitgewerkt, bijgewerkt en er nieuwe vermeldingen op zijn verschenen. En ze zijn gemarkeerd dat ze niet langer interessant zijn voor de database. Maar ze staan in de tabel vanwege een Postgres-functie.
Waarom heb je een autostofzuiger nodig? Op een gegeven moment komt het autovacuüm, opent de database en vraagt: “Geef mij alstublieft de ID van de oudste transactie die momenteel in de database geopend is.” De database retourneert deze ID. En het autovacuüm sorteert, erop vertrouwend, de lijnen in de tabel. En als hij ziet dat sommige regels zijn gewijzigd door veel oudere transacties, dan heeft hij het recht om ze te markeren als regels die we in de toekomst kunnen hergebruiken door daar nieuwe gegevens te schrijven. Dit is een achtergrondproces.
Op dit moment blijven we werken met de database en blijven we enkele wijzigingen aanbrengen in de tabel. En op deze regels, die we kunnen hergebruiken, schrijven we nieuwe gegevens. En zo krijgen we een cyclus, d.w.z. er verschijnen voortdurend enkele dode oude regels, in plaats daarvan schrijven we nieuwe regels op die we nodig hebben. En dit is een normale toestand waarin PostgreSQL werkt.
Wat gebeurde er tijdens het ongeval? Hoe verliep dit proces daar?
We hadden een bord in een bepaalde staat, sommige live, sommige dode lijnen. De autostofzuiger is gearriveerd. Hij vroeg de database wat onze oudste transactie is en wat de ID ervan is. Ik heb deze ID ontvangen, wat vele uren geleden kan zijn, misschien tien minuten geleden. Het hangt af van hoe zwaar de belasting van uw database is. En hij ging op zoek naar lijnen die hij als hergebruikt kon markeren. En ik vond zulke regels niet in onze tabel.
Maar op dit moment blijven we met de tafel werken. We doen er iets in, updaten het, wijzigen de gegevens. Wat moet de database op dit moment doen? Ze heeft geen andere keuze dan nieuwe regels toe te voegen aan het einde van de bestaande tabel. En zo begint onze tafelgrootte te groeien.
In werkelijkheid hebben we groene lijnen nodig om te kunnen werken. Maar tijdens een dergelijk probleem blijkt dat het percentage groene lijnen over de hele tabel extreem laag is.
En als we een query uitvoeren, moet de database alle regels doorlopen: zowel rood als groen, om de gewenste regel te vinden. En het effect van het opzwellen van een tabel met nutteloze gegevens wordt “bloat” genoemd, wat ook onze schijfruimte in beslag neemt. Weet je nog, het was 2 MB, het werd 300 MB? Verander nu megabytes in gigabytes en je zult snel al je schijfbronnen kwijtraken.
Welke gevolgen kunnen er voor ons zijn?
- In mijn voorbeeld groeiden de tabel en de index 150 keer. Sommige van onze klanten hebben meer fatale gevallen gehad toen ze simpelweg geen schijfruimte meer hadden.
- De grootte van de tafels zelf zal nooit afnemen. Autovacuüm kan in sommige gevallen de staart van de tafel afsnijden als er alleen dode lijnen zijn. Maar omdat er een constante rotatie is, kan het zijn dat één groene lijn aan het einde vastloopt en niet wordt bijgewerkt, terwijl alle andere ergens aan het begin van de plaat worden opgeschreven. Maar dit is zo'n onwaarschijnlijke gebeurtenis dat uw tafel zelf kleiner wordt, dus u moet er niet op hopen.
- De database moet een hele reeks nutteloze regels doorzoeken. En we verspillen schijfbronnen, we verspillen processorbronnen en elektriciteit.
- En dit heeft rechtstreeks invloed op onze applicatie, want als we in het begin 10 milliseconden aan het verzoek besteedden, 10 milliseconden aan onze code, dan begonnen we tijdens de crash een seconde aan het verzoek te besteden en 10 milliseconden aan de code, d.w.z. een bestelling van De omvang van de applicatieprestaties nam af. En toen het ongeluk was opgelost, begonnen we 20 milliseconden aan een verzoek te besteden, en 10 milliseconden aan een code. Dit betekent dat we nog steeds anderhalf keer in productiviteit zijn gedaald. En dit komt allemaal door één transactie die vastliep, misschien door onze schuld.
- En de vraag: “Hoe krijgen we alles terug?”, zodat alles bij ons in orde is en aanvragen net zo snel binnenkomen als vóór het ongeval.
Voor dit doel wordt er een bepaalde werkcyclus uitgevoerd.
Eerst moeten we de problematische tabellen vinden die opgeblazen zijn. We begrijpen dat in sommige tabellen de opname actiever is, in andere minder actief. En hiervoor gebruiken we de extensie . Door deze extensie te installeren, kunt u query's schrijven die u helpen bij het vinden van tabellen die behoorlijk opgeblazen zijn.
Zodra u deze tabellen heeft gevonden, moet u ze comprimeren. Daar bestaan al hulpmiddelen voor. In ons bedrijf gebruiken we drie tools. De eerste is de ingebouwde VACUÜM VOL. Hij is wreed, hard en meedogenloos, maar soms is hij erg nuttig. и - Dit zijn hulpprogramma's van derden voor het comprimeren van tabellen. En ze gaan zorgvuldiger om met de database.
Ze worden gebruikt afhankelijk van wat voor u handiger is. Maar ik zal je hierover helemaal aan het einde vertellen. Het belangrijkste is dat er drie hulpmiddelen zijn. Er is genoeg om uit te kiezen.
Nadat we alles hebben gecorrigeerd en ervoor hebben gezorgd dat alles in orde is, moeten we weten hoe we deze situatie in de toekomst kunnen voorkomen:
- Het kan vrij eenvoudig worden voorkomen. U moet de duur van sessies op de masterserver controleren. Vooral gevaarlijke sessies in inactiviteit in transactiestatus. Dit zijn degenen die net een transactie hebben geopend, iets hebben gedaan en zijn vertrokken, of gewoon zijn blijven hangen, verdwaald zijn in de code.
- En voor u als ontwikkelaars is het belangrijk om uw code te testen wanneer deze situaties zich voordoen. Het is niet moeilijk om te doen. Dit zal een nuttige controle zijn. U vermijdt een groot aantal ‘kinderachtige’ problemen die gepaard gaan met lange transacties.
In deze grafieken wilde ik laten zien hoe het bord en het gedrag van de database veranderden nadat ik in dit geval het bord met VACUUM FULL had doorlopen. Dit is geen productie voor mij.
De tabelgrootte keerde onmiddellijk terug naar de normale bedrijfsstatus van een paar megabytes. Dit had geen grote invloed op de gemiddelde responstijd van de server.
Maar specifiek voor ons testbord, waar we rekeningsaldi hebben bijgewerkt, zien we dat de gemiddelde responstijd voor een verzoek om gegevens op het bord bij te werken, is teruggebracht tot het niveau van vóór de noodsituatie. De bronnen die de processor verbruikte om dit verzoek te voltooien, daalden ook naar het niveau van vóór de crash. En de grafiek rechtsonder laat zien dat we nu precies de lijn vinden die we nodig hebben, zonder door de stapels dode lijnen te gaan die er waren voordat de tabel werd gecomprimeerd. En de gemiddelde aanvraagtijd bleef op ongeveer hetzelfde niveau. Maar hier heb ik eerder een fout in mijn hardware.
Hier eindigt het eerste verhaal. Het is de meest voorkomende. En het overkomt iedereen, ongeacht de ervaring van de klant en hoe gekwalificeerd de programmeurs zijn. Vroeg of laat gebeurt dit.
Het tweede verhaal, waarin we de belasting verdelen en de serverbronnen optimaliseren
- We zijn al volwassen en serieuze jongens geworden. En we begrijpen dat we een replica hebben en dat het goed voor ons zou zijn om de belasting in evenwicht te brengen: naar de Master schrijven en van de replica lezen. En meestal doet deze situatie zich voor wanneer we enkele rapporten of ETL willen voorbereiden. En het bedrijfsleven is daar erg blij mee. Hij wil echt een verscheidenheid aan rapporten met veel complexe analyses.
- Rapporten nemen vele uren in beslag, omdat complexe analyses niet in milliseconden kunnen worden berekend. Wij, net als dappere jongens, schrijven code. In de invoegapplicatie maken we de opname op de Master, en voeren we de rapportages uit op de replica.
- Het verdelen van de lading.
- Alles werkt perfect. Waren geweldig.
En hoe ziet deze situatie eruit? Specifiek voor deze grafieken heb ik ook de duur van transacties uit de replica toegevoegd voor de transactieduur. Alle andere grafieken hebben alleen betrekking op de masterserver.
Tegen die tijd was mijn rapportbord gegroeid. Er zijn er meer. We zien dat de gemiddelde serverresponstijd stabiel is. We zien dat we op de replica een langlopende transactie hebben die 2 uur duurt. We zien de stille werking van het autovacuüm, dat dode lijnen verwerkt. En alles gaat goed met ons.
Concreet blijven we volgens het geteste kenteken daar de rekeningsaldi bijwerken. En we hebben ook een stabiele reactietijd voor verzoeken en een stabiel hulpbronnenverbruik. Bij ons is alles goed.
Alles gaat goed tot het moment dat deze rapporten terug beginnen te schieten vanwege een conflict met replicatie. En ze schieten met regelmatige tussenpozen terug.
We gaan online en beginnen te lezen waarom dit gebeurt. En wij vinden een oplossing.
De eerste oplossing is het vergroten van de replicatielatentie. We weten dat ons rapport 3 uur duurt. We hebben de replicatievertraging ingesteld op 3 uur. We lanceren alles, maar we hebben nog steeds problemen met het soms annuleren van rapporten.
Wij willen dat alles perfect is. Wij klimmen verder. En we hebben een coole instelling op internet gevonden: hot_standby_feedback. Laten we het inschakelen. Met Hot_standby_feedback kunnen we het autovacuüm op de Master tegenhouden. Zo zijn we volledig verlost van replicatieconflicten. En bij ons werkt alles prima met rapportages.
En wat gebeurt er op dit moment met de Master-server? En we hebben totale problemen met de Master-server. Nu zien we de grafieken wanneer ik beide instellingen heb ingeschakeld. En we zien dat de sessie op onze replica op de een of andere manier de situatie op de Master-server begon te beïnvloeden. Ze heeft wel effect omdat ze het autovacuüm heeft gepauzeerd, waardoor de dode lijnen worden gewist. Onze tafelgrootte is weer omhooggeschoten. De gemiddelde uitvoeringstijd van zoekopdrachten voor de gehele database schoot ook omhoog. De autovacuüms werden een beetje strakker.
Concreet zien we vanaf ons bord dat de gegevensupdate daarop ook de lucht in is gesprongen. Het CPU-verbruik is eveneens enorm toegenomen. We gaan opnieuw door een groot aantal dode, nutteloze regels. En de responstijd voor dit bord en het aantal transacties zijn gedaald.
Hoe zal het eruit zien als we niet weten waar ik het eerder over had?
- We gaan op zoek naar problemen. Als we in het eerste deel problemen tegenkwamen, weten we dat dit te wijten kan zijn aan een lange transactie en naar de Meester gaan. We hebben een probleem met de Master. Worst hem. Het warmt op, het belastingsgemiddelde is ongeveer honderd.
- Verzoeken zijn daar traag, maar we zien daar geen langlopende transacties. En wij begrijpen niet wat er aan de hand is. We begrijpen niet waar we moeten kijken.
- Wij controleren serverapparatuur. Misschien is onze aanval gecrasht. Misschien is onze geheugenstick doorgebrand. Ja, er kan van alles gebeuren. Maar nee, de servers zijn nieuw, alles werkt prima.
- Iedereen draait: beheerders, ontwikkelaars en de regisseur. Niets helpt.
- En op een gegeven moment begint alles zichzelf plotseling te corrigeren.
Op dat moment werd het verzoek op onze replica verwerkt en achtergelaten. Wij hebben het rapport ontvangen. Het bedrijfsleven is nog steeds blij. Zoals je ziet is ons bord weer gegroeid en gaat niet meer krimpen. Op de grafiek met sessies heb ik een stukje van deze lange transactie uit een replica gelaten, zodat je kunt inschatten hoe lang het duurt voordat de situatie stabiliseert.
De sessie is voorbij. En pas na enige tijd komt de server min of meer in orde. En de gemiddelde reactietijd voor verzoeken op de masterserver wordt weer normaal. Omdat het autovacuüm eindelijk de mogelijkheid heeft om deze dode lijnen op te ruimen en te markeren. En hij begon zijn werk te doen. En hoe snel hij het doet, zo snel komen wij op orde.
Volgens de geteste tablet, waar we rekeningsaldi bijwerken, zien we precies hetzelfde beeld. De gemiddelde accountupdatetijd normaliseert ook geleidelijk. De bronnen die door de processor worden verbruikt, worden ook verminderd. En het aantal transacties per seconde keert terug naar normaal. Maar opnieuw zijn we weer normaal, niet meer zoals vóór het ongeval.
In ieder geval krijgen we, net als in het eerste geval, een prestatievermindering van anderhalf tot twee keer, en soms meer.
Het lijkt erop dat we alles goed hebben gedaan. Verdeel de lading. De apparatuur staat niet stil. We verdeelden de verzoeken naar onze mening, maar toch liep alles slecht af.
- Hot_standby_feedback niet inschakelen? Ja, het wordt niet aanbevolen om het in te schakelen zonder bijzonder sterke redenen. Omdat deze twist rechtstreeks van invloed is op de Master-server en de werking van het autovacuüm daar opschort. Door het op een replica in te schakelen en het te vergeten, kun je de Master doden en grote problemen krijgen met de applicatie.
- Max_standby_streaming_delay verhogen? Ja, voor rapporten is dit waar. Als u een rapport van drie uur heeft en u wilt niet dat dit crasht vanwege replicatieconflicten, vergroot dan eenvoudigweg de vertraging. Voor een langetermijnrapport zijn nooit gegevens nodig die op dit moment in de database zijn aangekomen. Als je het drie uur hebt, gebruik je het voor een oude dataperiode. En voor u maakt het niet uit of er sprake is van een vertraging van drie uur of van zes uur, maar u ontvangt wel consistent meldingen en heeft er geen problemen mee dat deze uitvallen.
- Uiteraard moet u lange sessies op replica's beheren, vooral als u besluit hot_standby_feedback in te schakelen op een replica. Omdat er van alles kan gebeuren. We hebben deze replica aan de ontwikkelaar gegeven zodat hij de verzoeken kon testen. Hij schreef een gek verzoek. Hij lanceerde het en ging thee drinken, en we kregen de gevestigde Meester. Of misschien hebben we daar de verkeerde applicatie geplaatst. De situaties zijn gevarieerd. Sessies op replica's moeten net zo zorgvuldig worden gecontroleerd als op de Master.
- En als u snelle en lange vragen over replica's heeft, is het in dit geval beter om ze te splitsen om de belasting te verdelen. Dit is een link naar streaming_delay. Voor snelle versies heeft u één replica met een kleine replicatievertraging. Voor langlopende rapportageverzoeken moet u een replica hebben die een vertraging van zes uur of een dag kan hebben. Dit is een volkomen normale situatie.
We elimineren de gevolgen op dezelfde manier:
- We vinden opgeblazen tafels.
- En we comprimeren het met de handigste tool die bij ons past.
Het tweede verhaal eindigt hier. Laten we verder gaan met het derde verhaal.
Ook voor ons heel gebruikelijk waarin we aan migratie doen.
- Elk softwareproduct groeit. De eisen daarvoor veranderen. Wij willen ons in ieder geval ontwikkelen. En het komt voor dat we de gegevens in de tabel moeten bijwerken, namelijk om een update uit te voeren in termen van onze migratie voor de nieuwe functionaliteit die we introduceren als onderdeel van onze ontwikkeling.
- Het oude dataformaat voldoet niet. Laten we zeggen dat we nu naar de tweede tabel gaan, waar ik transacties op deze rekeningen heb. En laten we zeggen dat ze in roebels waren, en we besloten de nauwkeurigheid te vergroten en het in kopeken te doen. En hiervoor moeten we een update maken: vermenigvuldig het veld met het transactiebedrag met honderd.
- Tegenwoordig gebruiken we geautomatiseerde tools voor versiebeheer van databases. Laten we zeggen . Wij registreren daar onze migratie. Wij testen het op onze testbasis. Alles is in orde. De update is bezig. Het blokkeert het werk een tijdje, maar we krijgen bijgewerkte gegevens. En we kunnen hierop nieuwe functionaliteit lanceren. Alles werd getest en gecontroleerd. Alles werd bevestigd.
- We voerden geplande werkzaamheden uit en voerden migratie uit.
Hier is de migratie met de update voor u gepresenteerd. Omdat dit mijn accounttransacties zijn, was het bord 15 GB. En omdat we elke regel bijwerken, hebben we met de update de grootte van de tabel verdubbeld, omdat we elke regel hebben herschreven.
Tijdens de migratie konden we niets met deze plaat doen, omdat alle verzoeken ernaar in de wachtrij stonden en wachtten tot deze update voltooid was. Maar hier wil ik uw aandacht vestigen op de cijfers die op de verticale as staan. Dat wil zeggen, we hebben een gemiddelde verzoektijd vóór de migratie van ongeveer 5 milliseconden en de processorbelasting, het aantal blokbewerkingen voor het lezen van schijfgeheugen is minder dan 7,5.
We voerden de migratie uit en kregen opnieuw problemen.
De migratie was succesvol, maar:
- Het duurt nu langer om de oude functionaliteit te voltooien.
- De tafel werd weer groter.
- De belasting op de server werd opnieuw groter dan voorheen.
- En natuurlijk zijn we nog steeds aan het sleutelen aan de functionaliteit die goed werkte, we hebben deze een beetje verbeterd.
En dit is weer een opgeblazen gevoel, dat opnieuw ons leven verpest.
Hier laat ik zien dat de tafel, net als de vorige twee gevallen, niet zal terugkeren naar zijn vorige afmetingen. De gemiddelde serverbelasting lijkt voldoende te zijn.
En als we naar de tabel met rekeningen kijken, zien we dat de gemiddelde aanvraagtijd voor deze tabel is verdubbeld. De belasting van de processor en het aantal uitgesorteerde regels in het geheugen sprongen boven de 7,5, maar waren lager. En het sprong 2 keer in het geval van processors, 1,5 keer in het geval van blokbewerkingen, d.w.z. we kregen een verslechtering van de serverprestaties. En als gevolg daarvan: verslechtering van de prestaties van onze applicatie. Tegelijkertijd bleef het aantal oproepen ongeveer op hetzelfde niveau.
En het belangrijkste hier is om te begrijpen hoe u dergelijke migraties correct kunt uitvoeren. En ze moeten gedaan worden. We voeren deze migraties redelijk consistent uit.
- Dergelijke grote migraties gebeuren niet automatisch. Ze moeten altijd onder controle zijn.
- Begeleiding door een deskundig persoon is vereist. Als je een DBA in je team hebt, laat de DBA dat dan doen. Het is zijn taak. Zo niet, laat het dan doen door de meest ervaren persoon, die weet hoe hij met databases moet werken.
- Een nieuw databaseschema, zelfs als we één kolom updaten, bereiden we altijd in fasen voor, dat wil zeggen vooraf voordat de nieuwe versie van de applicatie wordt uitgerold:
- Er zijn nieuwe velden toegevoegd waarin we de bijgewerkte gegevens zullen vastleggen.
- Gegevens van het oude veld zetten we in kleine delen over naar het nieuwe veld. Waarom doen we dit? Ten eerste beheersen wij altijd het proces van dit proces. We weten dat we al zoveel batches hebben overgedragen en dat we er nog zoveel over hebben.
- En het tweede positieve effect is dat we tussen elke batch de transactie sluiten, een nieuwe openen, en hierdoor kan het autovacuüm volgens het bord werken en deadlines markeren voor hergebruik.
- Voor de regels die verschijnen terwijl de applicatie draait (we hebben de oude applicatie nog draaiend), voegen we een trigger toe die nieuwe waarden naar nieuwe velden schrijft. In ons geval is dit een vermenigvuldiging met honderd van de oude waarde.
- Als we totaal eigenwijs zijn en hetzelfde veld willen, hernoemen we de velden na voltooiing van alle migraties en voordat we een nieuwe versie van de applicatie uitrollen. De oude krijgen een verzonnen naam en de nieuwe velden worden hernoemd naar de oude.
- En pas daarna lanceren we een nieuwe versie van de applicatie.
En tegelijkertijd zullen we geen opgeblazen gevoel krijgen en niet lijden onder de prestaties.
Hier eindigt het derde verhaal.
En nu wat meer details over de tools die ik in het allereerste verhaal noemde.
Voordat u naar bloat zoekt, moet u de extensie installeren .
Zodat u geen vragen hoeft te bedenken, hebben we deze vragen al in ons werk geschreven. Je kunt ze gebruiken. Er zijn hier twee verzoeken.
- Het duurt behoorlijk lang voordat de eerste werkt, maar hij laat je de exacte bloat-waarden uit de tabel zien.
- De tweede werkt sneller en is zeer effectief als u snel moet beoordelen of er volgens de tabel een opgeblazen gevoel is of niet. En je moet ook begrijpen dat er altijd een opgeblazen gevoel aanwezig is in een Postgres-tabel. Dit is een kenmerk van het MVCC-model.
- En in de meeste gevallen is een opgeblazen gevoel van 20% normaal voor tafels. Dat wil zeggen, u hoeft zich geen zorgen te maken en deze tabel te comprimeren.
We hebben ontdekt hoe we tabellen kunnen identificeren die vol zitten met nutteloze gegevens.
Nu over het oplossen van een opgeblazen gevoel:
- Als we een kleine tablet en goede schijven hebben, dat wil zeggen op een tablet tot een gigabyte, is het heel goed mogelijk om VACUUM FULL te gebruiken. Hij zal een paar seconden een exclusief slot van je op tafel nemen en oké, maar hij zal alles snel en hardhandig doen. Wat doet VACUÜM VOL? Het vereist een exclusieve vergrendeling van de tafel en herschrijft live rijen van de oude tabellen naar de nieuwe tabel. En aan het einde vervangt hij ze. Het verwijdert oude bestanden en vervangt de oude door nieuwe. Maar voor de duur van zijn werk heeft hij een exclusief slot op tafel nodig. Dit betekent dat u niets met deze tabel kunt doen: er niet naar schrijven, er niet in lezen, noch wijzigen. En VACUUM FULL vereist extra schijfruimte om gegevens te schrijven.
- Volgende hulpmiddel . In principe lijkt het erg op VACUUM FULL, omdat het ook gegevens van oude bestanden naar nieuwe herschrijft en in de tabel vervangt. Maar tegelijkertijd neemt het niet een exclusief slot op tafel aan het begin van zijn werk, maar neemt het pas op het moment dat het al over gegevens beschikt om de bestanden te vervangen. De vereisten voor schijfbronnen zijn vergelijkbaar met die van VACUUM FULL. U hebt extra schijfruimte nodig, en dit is soms van cruciaal belang als u terabyte-tabellen heeft. En het is behoorlijk processor-hongerig omdat het actief met I/O werkt.
- Het derde hulpprogramma is . Er wordt voorzichtiger omgegaan met middelen, omdat het volgens iets andere principes werkt. Het belangrijkste idee van pgcompacttable is dat het alle live rijen naar het begin van de tabel verplaatst met behulp van updates in de tabel. En dan loopt er een vacuüm op deze tafel, omdat we weten dat we aan het begin live rijen hebben en aan het einde dode rijen. En het vacuüm zelf snijdt deze staart af, d.w.z. er is niet veel extra schijfruimte voor nodig. En tegelijkertijd kan er nog steeds onder druk worden gezet qua middelen.
Alles met gereedschap.
Als je het bloat-onderwerp interessant vindt om er verder in te duiken, zijn hier enkele nuttige links:
- - Dit is een rapport van mijn collega. Het is algemeen over waar de ruimte van Postgres naartoe gaat tijdens zijn werk en leven. En er is een heel groot en gedetailleerd technisch stuk voor databasebeheerders over bloat.
- – dit is een link naar onze repository, waar we een aantal nuttige scripts opslaan om de status van de database te controleren. Daar kun je scripts vinden om naar bloat te zoeken.
- и links naar tools waarmee u borden kunt verkleinen.
- – dit is een bericht van mijn collega. Daar analyseert hij bloat behoorlijk serieus en technisch tot in detail op een niveau dat dicht bij de beheerders ligt.
Ik heb meer geprobeerd een horrorverhaal voor ontwikkelaars te laten zien, omdat zij onze directe klanten van databases zijn en moeten begrijpen waartoe en waartoe acties leiden. Ik hoop dat het mij is gelukt. Bedankt voor uw aandacht!
vragen
Bedankt voor het rapport! U sprak over hoe u problemen kunt identificeren. Hoe kunnen ze gewaarschuwd worden? Dat wil zeggen, ik had een situatie waarin verzoeken niet alleen bleven hangen omdat ze toegang hadden tot bepaalde externe services. Dit waren slechts enkele wilde joins. Er waren een paar kleine, onschuldige verzoeken die een dag bleven hangen, en toen onzin begonnen te doen. Dat wil zeggen, zeer vergelijkbaar met wat u beschrijft. Hoe dit te volgen? Zitten en voortdurend kijken welk verzoek vastloopt? Hoe kan dit worden voorkomen?
In dit geval is dit een taak voor de beheerders van uw bedrijf en niet noodzakelijkerwijs voor de DBA.
Ik ben een beheerder.
PostgreSQL heeft een weergave genaamd pg_stat_activity die bungelende zoekopdrachten toont. En je kunt zien hoe lang het daar hangt.
Moet ik elke 5 minuten komen kijken?
Cron instellen en controleren. Als u een langetermijnverzoek heeft, schrijft u een brief en dat is alles. Dat wil zeggen, u hoeft niet met uw ogen te kijken, het kan geautomatiseerd worden. U ontvangt een brief, u reageert erop. Of u kunt automatisch fotograferen.
Zijn er duidelijke redenen waarom dit gebeurt?
Ik heb er een paar op een rij gezet. Andere, complexere voorbeelden. En een gesprek kan lang duren.
Bedankt voor het rapport! Ik wilde opheldering geven over het hulpprogramma pg_repack. Als ze geen exclusieve lock doet, dan...
Ze doet een exclusief slot.
... dan kan ik mogelijk gegevens verliezen. Moet mijn aanvraag gedurende deze periode niets opnemen?
Nee, het werkt soepel met de tabel, d.w.z. pg_repack draagt eerst alle bestaande live-lijnen over. Uiteraard vindt daar een soort van toegang tot de tabel plaats. Hij gooit gewoon deze paardenstaart eruit.
Dat wil zeggen: doet hij het uiteindelijk ook daadwerkelijk?
Uiteindelijk neemt hij een exclusief slot om deze bestanden uit te wisselen.
Zal het sneller zijn dan VACUÜM VOL?
VACUÜM VOL, zodra het begon, meteen een exclusief slot meegenomen. En totdat hij alles doet, zal hij haar niet laten gaan. En pg_repack neemt alleen een exclusieve vergrendeling op het moment van bestandsvervanging. Op dit moment schrijf je daar niet, maar de gegevens gaan niet verloren, alles komt goed.
Hallo! Je had het over de werking van een autostofzuiger. Er was een grafiek met rode, gele en groene registratiecellen. Dat wil zeggen, gele - hij heeft ze gemarkeerd als verwijderd. En als gevolg daarvan kan er iets nieuws in worden geschreven?
Ja. Postgres verwijdert geen regels. Hij heeft zo'n specificiteit. Als we een regel hebben bijgewerkt, hebben we de oude gemarkeerd als verwijderd. De ID van de transactie die deze regel heeft gewijzigd, verschijnt daar en we schrijven een nieuwe regel. En we hebben sessies die ze mogelijk kunnen lezen. Op een gegeven moment worden ze behoorlijk oud. En de essentie van hoe het autovacuüm werkt, is dat het door deze lijnen gaat en ze als onnodig markeert. En u kunt daar gegevens overschrijven.
Ik begrijp. Maar daar gaat de vraag niet over. Ik ben niet klaar. Laten we aannemen dat we een tafel hebben. Het heeft velden van variabele grootte. En als ik iets nieuws probeer in te voegen, past het misschien gewoon niet in de oude cel.
Nee, in ieder geval wordt daar de hele lijn bijgewerkt. Postgres heeft twee modellen voor gegevensopslag. Er wordt geselecteerd op basis van het gegevenstype. Er zijn gegevens die rechtstreeks in de tabel worden opgeslagen, en er zijn ook tos-gegevens. Dit zijn grote hoeveelheden gegevens: tekst, json. Ze worden in afzonderlijke platen opgeslagen. En volgens deze tablets doet zich hetzelfde verhaal met een opgeblazen gevoel voor, d.w.z. alles is hetzelfde. Ze worden alleen afzonderlijk vermeld.
Bedankt voor het rapport! Is het acceptabel om time-outquery's voor instructies te gebruiken om de duur te beperken?
Zeer acceptabel. Wij gebruiken dit overal. En omdat we geen eigen diensten hebben, bieden we ondersteuning op afstand, we hebben een grote verscheidenheid aan klanten. En iedereen is hier helemaal tevreden mee. Dat wil zeggen, we hebben cronjobs die dit controleren. De duur van de sessies wordt eenvoudigweg met de klant afgesproken, daarvoor zijn wij het niet eens. Het kan een minuut zijn, het kan ook 10 minuten zijn. Het hangt af van de belasting van de basis en het doel ervan. Maar we gebruiken allemaal pg_stat_activity.
Bedankt voor het rapport! Ik probeer uw rapport toe te passen op mijn sollicitaties. En het lijkt alsof we overal een transactie starten en deze duidelijk overal voltooien. Als er een uitzondering is, vindt er nog steeds een terugdraaiing plaats. En toen begon ik na te denken. De transactie mag immers niet expliciet starten. Dit is waarschijnlijk een hint voor het meisje. Als ik alleen een record bijwerk, start de transactie dan in PostgreSQL en wordt deze pas voltooid als de verbinding wordt verbroken?
Als je het nu over het applicatieniveau hebt, dan hangt het af van de driver die je gebruikt, van de ORM die gebruikt wordt. Er zijn veel instellingen daar. Als u automatische vastlegging hebt ingeschakeld, wordt daar een transactie gestart en onmiddellijk gesloten.
Dat wil zeggen, het sluit onmiddellijk na de update?
Het hangt af van de instellingen. Ik heb één instelling genoemd. Dit is een automatische commit. Het is heel gebruikelijk. Als dit is ingeschakeld, is de transactie geopend en gesloten. Tenzij u expliciet “starttransactie” en “eindtransactie” zei, maar eenvoudigweg een verzoek in de sessie lanceerde.
Hallo! Bedankt voor het rapport! Laten we ons voorstellen dat we een database hebben die steeds groter wordt en dat de ruimte op de server opraakt. Zijn er hulpmiddelen om deze situatie op te lossen?
De ruimte op de server moet goed worden bewaakt.
De DBA ging bijvoorbeeld thee drinken, was in een resort, etc.
Wanneer een bestandssysteem wordt gemaakt, wordt er op zijn minst een soort back-upruimte gecreëerd waar geen gegevens worden geschreven.
Wat als het volledig onder nul is?
Daar wordt het gereserveerde ruimte genoemd, d.w.z. het kan worden vrijgegeven en afhankelijk van hoe groot het is gemaakt, krijg je vrije ruimte. Standaard weet ik niet hoeveel er zijn. En in een ander geval schijven aanleveren zodat je ruimte hebt om een reconstructieve operatie uit te voeren. U kunt een tabel verwijderen die u gegarandeerd niet nodig heeft.
Zijn er nog andere hulpmiddelen?
Het is altijd handgemaakt. En lokaal wordt duidelijk wat je daar het beste kunt doen, omdat sommige data kritisch zijn en andere niet-kritisch. En voor elke database en de applicatie die ermee werkt, is het afhankelijk van de business. Het wordt altijd lokaal beslist.
Bedankt voor het rapport! Ik heb twee vragen. Ten eerste liet u dia's zien waaruit bleek dat wanneer transacties vastlopen, zowel de tabelruimtegrootte als de indexgrootte toenemen. En verderop in het rapport waren er een aantal hulpprogramma's die de tablet verpakken. Hoe zit het met de index?
Ze pakken ze ook in.
Maar het vacuüm heeft geen invloed op de index?
Sommige werken met een index. Bijvoorbeeld pg_rapack, pgcompacttable. Het vacuüm herschept de indexen en beïnvloedt deze. Met VACUUM FULL is het de bedoeling om alles te overschrijven, d.w.z. het werkt met iedereen.
En de tweede vraag. Ik begrijp niet waarom rapporten over replica's zo afhankelijk zijn van de replicatie zelf. Het leek mij dat rapporten worden gelezen en replicatie schrijven is.
Wat veroorzaakt een replicatieconflict? Wij hebben een Master waarop processen plaatsvinden. Er is een autostofzuiger aan de gang. Wat doet een autovacuüm eigenlijk? Hij knipt wat oude regels uit. Als we op dit moment een verzoek hebben voor de replica die deze oude regels leest, en op de Master deed zich een situatie voor dat het autovacuüm deze regels markeerde als mogelijk om te worden overschreven, dan hebben we ze overschreven. En we hebben een datapakket ontvangen. Wanneer we de regels die het verzoek nodig heeft op de replica moeten herschrijven, wacht het replicatieproces op de time-out die u hebt geconfigureerd. En dan zal PostgreSQL beslissen wat belangrijker voor hem is. En replicatie is belangrijker voor hem dan het verzoek, en hij zal het verzoek opnemen om deze wijzigingen op de replica aan te brengen.
Andrej, ik heb een vraag. Zijn deze prachtige grafieken die u tijdens de presentatie liet zien het resultaat van uw werk? Hoe zijn de grafieken gemaakt?
Dit is een dienst .
Is dit een commercieel product?
Ja. Dit is een commercieel product.
Bron: www.habr.com