Jeg foreslår at du leser utskriften av rapporten fra begynnelsen av 2016 av Andrey Salnikov "Typiske feil i applikasjoner som fører til oppblåsthet i postgresql"
I denne rapporten vil jeg analysere hovedfeilene i applikasjoner som oppstår ved utforming og skriving av applikasjonskode. Og jeg tar bare de feilene som fører til oppblåsthet i Postgresql. Som regel er dette begynnelsen på slutten av ytelsen til systemet som helhet, selv om det i utgangspunktet ikke var synlige forutsetninger for dette.
Hyggelig å ønske alle velkommen! Denne rapporten er ikke så teknisk som den forrige fra min kollega. Denne rapporten er hovedsakelig rettet mot backend-systemutviklere fordi vi har et ganske stort antall kunder. Og de gjør alle de samme feilene. Jeg skal fortelle deg om dem. Jeg vil forklare hvilke fatale og dårlige ting disse feilene fører til.
Hvorfor gjøres det feil? De gjøres av to grunner: tilfeldig, kanskje det vil ordne seg og på grunn av uvitenhet om noen mekanismer som oppstår på nivået mellom databasen og applikasjonen, så vel som i selve databasen.
Jeg skal gi deg tre eksempler med forferdelige bilder av hvor ille ting ble. Jeg skal kort fortelle deg om mekanismen som skjer der. Og hvordan håndtere dem, når de skjedde, og hvilke forebyggende metoder du bør bruke for å forhindre feil. Jeg vil fortelle deg om hjelpeverktøyene og gi nyttige lenker.
Jeg brukte en testdatabase hvor jeg hadde to tabeller. En plate med kundekontoer, den andre med transaksjoner på disse kontoene. Og med en viss frekvens oppdaterer vi saldoene på disse kontoene.
Opprinnelige data for platen: den er ganske liten, 2 MB. Responstiden for databasen og spesifikt for skiltet er også veldig god. Og en ganske god belastning - 2 operasjoner i sekundet ifølge platen.
Og gjennom denne rapporten vil jeg vise deg grafer slik at du tydelig kan forstå hva som skjer. Det vil alltid være 2 lysbilder med grafer. Det første lysbildet er det som skjer generelt på serveren.
Og i denne situasjonen ser vi at vi virkelig har et lite skilt. Indeksen er liten på 2 MB. Dette er den første grafen til venstre.
Gjennomsnittlig responstid på serveren er også stabil og kort. Dette er grafen øverst til høyre.
Grafen nederst til venstre viser de lengste transaksjonene. Vi ser at transaksjoner gjennomføres raskt. Og autovakuum fungerer ikke her ennå, fordi det var en starttest. Det vil fortsette å fungere og vil være nyttig for oss.
Det andre lysbildet vil alltid være dedikert til platen som testes. I denne situasjonen oppdaterer vi kontinuerlig kundens kontosaldo. Og vi ser at den gjennomsnittlige responstiden for en oppdateringsoperasjon er ganske god, mindre enn et millisekund. Vi ser at prosessorressurser (dette er grafen øverst til høyre) også forbrukes jevnt og ganske lite.
Grafen nederst til høyre viser hvor mye drifts- og diskminne vi går gjennom på leting etter ønsket linje før vi oppdaterer den. Og antall operasjoner ifølge skiltet er 2 per sekund, som jeg sa innledningsvis.
Og nå har vi en tragedie. Av en eller annen grunn er det en lenge glemt transaksjon. Årsakene er vanligvis alle banale:
- En av de vanligste er at vi begynte å få tilgang til en ekstern tjeneste i applikasjonskoden. Og denne tjenesten svarer oss ikke. Det vil si at vi åpnet en transaksjon, gjorde en endring i databasen og gikk fra applikasjonen til å lese e-post eller til en annen tjeneste innenfor vår infrastruktur, og av en eller annen grunn svarer den ikke til oss. Og økten vår sitter fast i en tilstand der det er ukjent når det vil bli løst.
- Den andre situasjonen er når et unntak oppstod i koden vår av en eller annen grunn. Og i unntaket behandlet vi ikke gjennomføringen av transaksjonen. Og vi endte opp med en hengende økt med en åpen transaksjon.
- Og det siste er også et ganske vanlig tilfelle. Dette er kode av lav kvalitet. Noen rammer åpner en transaksjon. Den henger, og du vet kanskje ikke i applikasjonen at du har den hengende.
Hvor fører slike ting?
Til det punktet at våre tabeller og indekser begynner å svulme dramatisk. Dette er nøyaktig den samme oppblåste effekten. For databasen vil dette bety at databasens responstid vil øke veldig kraftig og belastningen på databaseserveren øker. Og som et resultat vil søknaden vår lide. For hvis du brukte 10 millisekunder i koden din på en forespørsel til databasen, 10 millisekunder på logikken din, så tok funksjonen din 20 millisekunder å fullføre. Og nå vil situasjonen din være helt trist.
Og la oss se hva som skjer. Grafen nederst til venstre viser at vi har en lang lang transaksjon. Og hvis vi ser på grafen øverst til venstre, ser vi at størrelsen på tabellen vår plutselig har hoppet fra to megabyte til 300 megabyte. Samtidig er datamengden i tabellen ikke endret, det vil si at det er en ganske stor mengde søppel der.
Den generelle situasjonen angående gjennomsnittlig serverresponstid har også endret seg i flere størrelsesordener. Det vil si at alle forespørsler på serveren begynte å falle helt. Og samtidig ble det lansert interne Postgres-prosesser i form av autovakuum, som prøver å gjøre noe og tærer på ressurser.
Hva skjer med skiltet vårt? Det samme. Vår gjennomsnittlige responstid ifølge skiltet har hoppet opp flere størrelsesordener. Spesielt når det gjelder forbrukte ressurser, ser vi at belastningen på prosessoren har økt kraftig. Dette er grafen øverst til høyre. Og det har økt fordi prosessoren må sortere gjennom en haug med ubrukelige linjer på jakt etter den som trengs. Dette er grafen nederst til høyre. Og som et resultat begynte antallet anrop per sekund å synke veldig betydelig, fordi databasen ikke hadde tid til å behandle det samme antall forespørsler.
Vi må komme tilbake til livet. Vi går på nett og finner ut at lange transaksjoner fører til problemer. Vi finner og dreper denne transaksjonen. Og alt begynner å bli normalt for oss. Alt fungerer som det skal.
Vi roet oss ned, men etter en stund begynner vi å merke at applikasjonen ikke fungerer på samme måte som før utrykningen. Forespørsler behandles fortsatt langsommere, og betydelig langsommere. En og en halv til to ganger langsommere spesielt i mitt eksempel. Belastningen på serveren er også høyere enn den var før ulykken.
Og spørsmålet: "Hva skjer med basen i dette øyeblikket?" Og følgende situasjon oppstår med basen. På transaksjonsdiagrammet kan du se at det har stoppet, og det er egentlig ingen langsiktige transaksjoner. Men størrelsen på skiltet økte dødelig under ulykken. Og siden har de ikke blitt mindre. Gjennomsnittstiden på basen har stabilisert seg. Og svarene ser ut til å komme tilstrekkelig med en hastighet som er akseptabel for oss. Autovakuumet ble mer aktivt og begynte å gjøre noe med skiltet, fordi det trenger å sile gjennom mer data.
Nærmere bestemt, ifølge testplaten med regnskap, hvor vi endrer saldoene: responstiden for forespørselen ser ut til å ha normalisert seg. Men i virkeligheten er den halvannen ganger høyere.
Og fra belastningen på prosessoren ser vi at belastningen på prosessoren ikke har returnert til den nødvendige verdien før krasjen. Og årsakene der ligger nettopp i grafen nederst til høyre. Det kan sees at en viss mengde minne blir søkt der. Det vil si at for å finne den nødvendige linjen, kaster vi bort ressursene til databaseserveren mens vi sorterer gjennom ubrukelige data. Antall transaksjoner per sekund har stabilisert seg.
Generelt bra, men situasjonen er verre enn den var. Fjern databasedegradering som en konsekvens av vår applikasjon som fungerer med denne databasen.
Og for å forstå hva som skjer der, hvis du ikke var på den forrige rapporten, la oss nå få en liten teori. Teori om den interne prosessen. Hvorfor en bilstøvsuger og hva gjør den?
Bokstavelig talt kort for forståelse. På et tidspunkt har vi et bord. Vi har rader i tabellen. Disse linjene kan være aktive, levende og det vi trenger nå. De er markert med grønt på bildet. Og det er dead lines som allerede er utarbeidet, har blitt oppdatert, og nye oppføringer har dukket opp på dem. Og de er markert med at de ikke lenger er interessante for databasen. Men de er i tabellen på grunn av en Postgres-funksjon.
Hvorfor trenger du en bilstøvsuger? På et tidspunkt kommer autovakuumet, får tilgang til databasen og spør: "Vennligst gi meg ID-en til den eldste transaksjonen som for øyeblikket er åpen i databasen." Databasen returnerer denne IDen. Og autovakuum, avhengig av det, sorterer gjennom linjene i tabellen. Og hvis han ser at noen linjer ble endret av mye eldre transaksjoner, så har han rett til å merke dem som linjer som vi kan gjenbruke i fremtiden ved å skrive nye data der. Dette er en bakgrunnsprosess.
På dette tidspunktet fortsetter vi å jobbe med databasen og fortsetter å gjøre noen endringer i tabellen. Og på disse linjene, som vi kan gjenbruke, skriver vi nye data. Og dermed får vi en syklus, dvs. hele tiden dukker det opp noen døde gamle linjer der, i stedet for dem skriver vi ned nye linjer som vi trenger. Og dette er en normal tilstand for at PostgreSQL skal fungere.
Hva skjedde under ulykken? Hvordan skjedde denne prosessen der?
Vi hadde et skilt i en eller annen tilstand, noen live, noen døde linjer. Bilstøvsugeren har kommet. Han spurte databasen hva vår eldste transaksjon er og hva dens id er. Jeg mottok denne ID-en, som kan være mange timer siden, kanskje ti minutter siden. Det avhenger av hvor stor belastning du har på databasen din. Og han gikk på jakt etter linjer som han kunne merke som gjenbrukt. Og jeg fant ikke slike linjer i tabellen vår.
Men på dette tidspunktet fortsetter vi å jobbe med tabellen. Vi gjør noe i det, oppdaterer det, endrer dataene. Hva bør databasen gjøre på dette tidspunktet? Hun har ikke noe annet valg enn å legge til nye linjer på slutten av den eksisterende tabellen. Og dermed begynner bordstørrelsen vår å svelle.
I realiteten trenger vi grønne linjer for å fungere. Men under et slikt problem viser det seg at prosentandelen av grønne linjer er ekstremt lav gjennom hele tabellen.
Og når vi utfører en spørring, må databasen gå gjennom alle linjene: både rød og grønn, for å finne ønsket linje. Og effekten av å blåse opp et bord med ubrukelige data kalles "bloat", som også spiser opp diskplassen vår. Husk at det var 2 MB, det ble 300 MB? Bytt nå megabyte til gigabyte og du vil raskt miste alle diskressursene dine.
Hvilke konsekvenser kan det få for oss?
- I mitt eksempel vokste tabellen og indeksen 150 ganger. Noen av våre klienter har hatt flere fatale tilfeller da de rett og slett begynte å gå tom for diskplass.
- Størrelsen på selve bordene vil aldri reduseres. Autovakuum kan i noen tilfeller kutte av halen på bordet hvis det bare er dead lines. Men siden det er konstant rotasjon, kan en grønn linje fryse på slutten og ikke bli oppdatert, mens alle de andre vil bli skrevet ned et sted i begynnelsen av platen. Men dette er en så usannsynlig hendelse at selve bordet ditt vil krympe i størrelse, så du bør ikke håpe på det.
- Databasen må sortere gjennom en hel haug med ubrukelige linjer. Og vi kaster bort diskressurser, vi kaster bort prosessorressurser og elektrisitet.
- Og dette påvirker applikasjonen vår direkte, for hvis vi i begynnelsen brukte 10 millisekunder på forespørselen, 10 millisekunder på koden vår, begynte vi under krasj å bruke et sekund på forespørselen og 10 millisekunder på koden, dvs. en ordre på omfanget i applikasjonsytelsen redusert. Og da ulykken ble løst, begynte vi å bruke 20 millisekunder på en forespørsel, 10 millisekunder på en kode. Dette betyr at vi fortsatt falt halvannen gang i produktivitet. Og alt dette er på grunn av en transaksjon som frøs, kanskje på grunn av vår skyld.
- Og spørsmålet: «Hvordan kan vi få alt tilbake?» slik at alt står bra til med oss og forespørsler kommer inn like raskt som før ulykken.
For dette formålet er det en viss syklus av arbeid som utføres.
Først må vi finne de problematiske tabellene som er oppblåste. Vi forstår at i noen tabeller er opptaket mer aktivt, i andre mindre aktivt. Og til dette bruker vi utvidelsen . Ved å installere denne utvidelsen kan du skrive spørringer som vil hjelpe deg å finne tabeller som er ganske oppblåste.
Når du har funnet disse tabellene, må du komprimere dem. Det finnes allerede verktøy for dette. I vårt selskap bruker vi tre verktøy. Den første er den innebygde VACUUM FULL. Han er grusom, barsk og nådeløs, men noen ganger er han veldig nyttig. и - Dette er tredjepartsverktøy for å komprimere tabeller. Og de behandler databasen mer forsiktig.
De brukes avhengig av hva som er mer praktisk for deg. Men jeg skal fortelle deg om dette helt til slutt. Hovedsaken er at det er tre verktøy. Det er nok å velge mellom.
Etter at vi har korrigert alt og sørget for at alt er i orden, må vi vite hvordan vi kan forhindre denne situasjonen i fremtiden:
- Det kan forhindres ganske enkelt. Du må overvåke varigheten av øktene på masterserveren. Spesielt farlige økter i inaktiv i transaksjonstilstand. Dette er de som nettopp åpnet en transaksjon, gjorde noe og dro, eller rett og slett ble hengt, gikk seg vill i koden.
- Og for deg som utviklere er det viktig å teste koden din når disse situasjonene oppstår. Det er ikke vanskelig å gjøre. Dette vil være en nyttig sjekk. Du vil unngå et stort antall "barnslige" problemer forbundet med lange transaksjoner.
I disse grafene ville jeg vise deg hvordan tegnet og oppførselen til databasen endret seg etter at jeg gikk gjennom skiltet med VACUUM FULL i dette tilfellet. Dette er ikke produksjon for meg.
Tabellstørrelsen gikk umiddelbart tilbake til normal driftstilstand på et par megabyte. Dette påvirket ikke den gjennomsnittlige responstiden for serveren i stor grad.
Men spesifikt for testskiltet vårt, der vi oppdaterte kontosaldoene, ser vi at gjennomsnittlig responstid for en forespørsel om å oppdatere data i skiltet ble redusert til nivåer før nødstilfeller. Ressursene som forbrukes av prosessoren for å fullføre denne forespørselen, falt også til nivåer før krasj. Og grafen nederst til høyre viser at nå finner vi akkurat den linjen vi trenger med en gang, uten å gå gjennom haugene med dødlinjer som var der før bordet ble komprimert. Og den gjennomsnittlige forespørselstiden holdt seg på omtrent samme nivå. Men her har jeg snarere en feil i maskinvaren min.
Det er her den første historien slutter. Det er det vanligste. Og det skjer med alle, uavhengig av kundens erfaring og hvor kvalifiserte programmererne er. Før eller siden skjer dette.
Den andre historien, der vi fordeler belastningen og optimaliserer serverressurser
- Vi har allerede vokst opp og blitt seriøse karer. Og vi forstår at vi har en kopi og det ville være bra for oss å balansere belastningen: skriv til Mesteren og les fra kopien. Og vanligvis oppstår denne situasjonen når vi ønsker å utarbeide noen rapporter eller ETL. Og næringslivet er veldig glade for dette. Han vil virkelig ha en rekke rapporter med mange komplekse analyser.
- Rapporter tar mange timer, fordi komplekse analyser ikke kan beregnes i millisekunder. Vi, som modige gutter, skriver kode. I innsettingsapplikasjonen gjør vi opptaket på Master, og utfører rapportene på replikaen.
- Fordeling av lasten.
- Alt fungerer perfekt. Vi er flinke.
Og hvordan ser denne situasjonen ut? Spesielt på disse grafene la jeg også til varigheten av transaksjoner fra replikaen for transaksjonsvarigheten. Alle andre grafer refererer kun til hovedserveren.
På dette tidspunktet hadde rapporten min vokst. Det er flere av dem. Vi ser at gjennomsnittlig serverresponstid er stabil. Vi ser at på kopien har vi en langvarig transaksjon som varer i 2 timer. Vi ser den stillegående driften av autovakuumet, som behandler deadlines. Og alt er bra med oss.
Spesielt, i henhold til testplaten, fortsetter vi å oppdatere kontosaldoene der. Og vi har også en stabil responstid på forespørsler, stabilt ressursforbruk. Alt er bra med oss.
Alt er bra til det øyeblikket disse rapportene begynner å skyte tilbake på grunn av en konflikt med replikering. Og de skyter tilbake med jevne mellomrom.
Vi går på nettet og begynner å lese hvorfor dette skjer. Og vi finner en løsning.
Den første løsningen er å øke replikeringsforsinkelsen. Vi vet at rapporten vår varer i 3 timer. Vi setter replikeringsforsinkelsen til 3 timer. Vi lanserer alt, men vi har fortsatt problemer med at rapporter noen ganger kanselleres.
Vi vil at alt skal være perfekt. Vi klatrer videre. Og vi fant en kul innstilling på Internett - hot_standby_feedback. La oss slå den på. Hot_standby_feedback lar oss holde tilbake autovakuumet på masteren. Dermed blir vi fullstendig kvitt replikeringskonflikter. Og alt fungerer bra for oss med rapporter.
Og hva skjer med Master-serveren på dette tidspunktet? Og vi har totalt problemer med Master-serveren. Nå ser vi grafene når jeg har begge disse innstillingene aktivert. Og vi ser at økten på vår replika på en eller annen måte begynte å påvirke situasjonen på Master-serveren. Hun har en effekt fordi hun stoppet autovakuumet, som fjerner dødlinjene. Bordstørrelsen vår har skutt i været igjen. Den gjennomsnittlige utføringstiden for spørringer i hele databasen skjøt også i været. Autovacuumsene strammet seg litt opp.
Nærmere bestemt, fra tallerkenen vår, ser vi at dataoppdateringen på den også hoppet til himmels. CPU-forbruket har tilsvarende økt kraftig. Vi går igjen gjennom et stort antall døde, ubrukelige linjer. Og responstiden for dette skiltet og antall transaksjoner har gått ned.
Hvordan vil det se ut hvis vi ikke vet hva jeg snakket om før?
- Vi begynner å lete etter problemer. Hvis vi støtt på problemer i første del, vet vi at dette kan skyldes en lang transaksjon og gå til Mesteren. Vi har et problem med Mesteren. Pølser ham. Den varmes opp, belastningsgjennomsnittet er omtrent hundre.
- Forespørsler der er trege, men vi ser ingen langvarige transaksjoner der. Og vi forstår ikke hva som er i veien. Vi forstår ikke hvor vi skal lete.
- Vi sjekker serverutstyr. Kanskje raidet vårt krasjet. Kanskje minnepinnen vår er utbrent. Ja, alt kan skje. Men nei, serverne er nye, alt fungerer bra.
- Alle kjører: administratorer, utviklere og direktøren. Ingenting hjelper.
- Og på et tidspunkt begynner alt plutselig å rette seg opp.
På dette tidspunktet ble forespørselen på vår replika behandlet og forlatt. Vi mottok rapporten. Business er fortsatt fornøyd. Som du kan se, har skiltet vårt vokst igjen og kommer ikke til å krympe. På grafen med økter la jeg en del av denne lange transaksjonen fra en kopi slik at du kan anslå hvor lang tid det tar før situasjonen stabiliserer seg.
Økten er over. Og først etter en tid kommer serveren mer eller mindre i orden. Og den gjennomsnittlige responstiden for forespørsler på hovedserveren går tilbake til det normale. For endelig har autostøvsugeren muligheten til å rense ut og markere disse dødlinjene. Og han begynte å gjøre jobben sin. Og hvor raskt han gjør det, så raskt får vi orden.
I følge det testede nettbrettet, hvor vi oppdaterer kontosaldo, ser vi nøyaktig det samme bildet. Den gjennomsnittlige kontooppdateringstiden normaliseres også gradvis. Ressursene som forbrukes av prosessoren reduseres også. Og antall transaksjoner per sekund går tilbake til det normale. Men igjen er vi tilbake til normalen, ikke det samme som vi var før ulykken.
Uansett får vi en ytelsesreduksjon, som i det første tilfellet, med en og en halv til to ganger, og noen ganger mer.
Vi ser ut til å ha gjort alt riktig. Fordel belastningen. Utstyret er ikke inaktivt. Vi delte opp forespørslene etter tankene våre, men likevel gikk alt dårlig.
- Aktiverer du ikke hot_standby_feedback? Ja, det anbefales ikke å slå den på uten særlig sterke grunner. Fordi denne vridningen påvirker hovedserveren direkte og stanser driften av autovakuum der. Ved å aktivere det på en kopi og glemme det, kan du drepe mesteren og få store problemer med applikasjonen.
- Øke max_standby_streaming_delay? Ja, for rapporter er dette sant. Hvis du har en tre-timers rapport og du ikke vil at den skal krasje på grunn av replikeringskonflikter, er det bare å øke forsinkelsen. En langtidsrapport krever aldri data som har kommet inn i databasen akkurat nå. Hvis du har den i tre timer, kjører du den i en gammel dataperiode. Og for deg, om det er en tre-timers forsinkelse eller en seks-timers forsinkelse vil ikke gjøre noen forskjell, men du vil motta rapporter konsekvent og vil ikke ha noen problemer med at de faller.
- Naturligvis må du kontrollere lange økter på replikaer, spesielt hvis du bestemmer deg for å aktivere hot_standby_feedback på en replika. Fordi alt kan skje. Vi ga denne kopien til utvikleren slik at han kunne teste spørringene. Han skrev en gal forespørsel. Han lanserte den og dro for å drikke te, og vi fikk den etablerte Mesteren. Eller kanskje vi legger inn feil applikasjon der. Situasjonene er varierte. Sesjoner på replikaer må overvåkes like nøye som på masteren.
- Og hvis du har raske og lange spørsmål om replikaer, er det i dette tilfellet bedre å dele dem for å fordele belastningen. Dette er en lenke til streaming_delay. For raske, ha én replika med en liten replikeringsforsinkelse. For langvarige rapporteringsforespørsler, ha en replika som kan forsinke med 6 timer eller en dag. Dette er en helt normal situasjon.
Vi eliminerer konsekvensene på samme måte:
- Vi finner oppblåste bord.
- Og vi komprimerer den med det mest praktiske verktøyet som passer oss.
Den andre historien slutter her. La oss gå videre til den tredje historien.
Også ganske vanlig for oss der vi gjør migrering.
- Ethvert programvareprodukt vokser. Kravene til det er i endring. Vi ønsker uansett å utvikle oss. Og det hender at vi trenger å oppdatere dataene i tabellen, nemlig å kjøre en oppdatering i forhold til vår migrering for den nye funksjonaliteten som vi introduserer som en del av utviklingen vår.
- Det gamle dataformatet er ikke tilfredsstillende. La oss si at vi nå går til den andre tabellen, hvor jeg har transaksjoner på disse kontoene. Og la oss si at de var i rubler, og vi bestemte oss for å øke nøyaktigheten og gjøre det i kopek. Og for dette må vi gjøre en oppdatering: multipliser feltet med transaksjonsbeløpet med hundre.
- I dagens verden bruker vi automatiserte verktøy for databaseversjonskontroll. La oss si . Vi registrerer vår migrasjon dit. Vi tester det på vår testbase. Alt er bra. Oppdateringen går gjennom. Det blokkerer arbeid en stund, men vi får oppdaterte data. Og vi kan lansere ny funksjonalitet på dette. Alt ble testet og sjekket. Alt ble bekreftet.
- Vi utførte planlagte arbeider og gjennomførte migrering.
Her er migreringen med oppdateringen presentert foran deg. Siden dette er kontotransaksjonene mine, var platen 15 GB. Og siden vi oppdaterer hver linje, doblet vi størrelsen på tabellen med oppdateringen, fordi vi skrev om hver linje.
Under migreringen kunne vi ikke gjøre noe med denne platen, fordi alle forespørsler til den ble satt i kø og ventet til denne oppdateringen ble fullført. Men her vil jeg trekke oppmerksomheten til tallene som er på den vertikale aksen. Det vil si at vi har en gjennomsnittlig forespørselstid før migrering på omtrent 5 millisekunder og prosessorbelastningen, antall blokkoperasjoner for lesing av diskminne er mindre enn 7,5.
Vi gjennomførte migreringen og fikk problemer igjen.
Migreringen var vellykket, men:
- Den gamle funksjonaliteten tar nå lengre tid å fullføre.
- Bordet vokste i størrelse igjen.
- Belastningen på serveren ble igjen større enn før.
- Og selvfølgelig pirker vi fortsatt med funksjonaliteten som fungerte bra, vi har forbedret den litt.
Og dette er igjen oppblåsthet, som igjen ødelegger livene våre.
Her demonstrerer jeg at bordet, i likhet med de to foregående tilfellene, ikke kommer til å gå tilbake til sine tidligere størrelser. Den gjennomsnittlige serverbelastningen ser ut til å være tilstrekkelig.
Og hvis vi vender oss til tabellen med kontoer, vil vi se at gjennomsnittlig forespørselstid er doblet for denne tabellen. Belastningen på prosessoren og antall linjer sortert ut i minnet hoppet over 7,5, men var lavere. Og det hoppet 2 ganger når det gjelder prosessorer, 1,5 ganger når det gjelder blokkoperasjoner, det vil si at vi fikk en forringelse i serverytelsen. Og som et resultat - forringelse av ytelsen til applikasjonen vår. Samtidig holdt antall samtaler seg omtrent på samme nivå.
Og det viktigste her er å forstå hvordan man gjør slike migrasjoner riktig. Og de må gjøres. Vi gjør disse migreringene ganske konsekvent.
- Slike store migrasjoner skjer ikke automatisk. De må alltid være under kontroll.
- Det kreves veiledning av en kyndig person. Hvis du har en DBA på laget ditt, så la DBA gjøre det. Det er jobben hans. Hvis ikke, så la den mest erfarne personen gjøre det, som vet hvordan man jobber med databaser.
- Et nytt databaseskjema, selv om vi oppdaterer én kolonne, forbereder vi oss alltid i etapper, dvs. på forhånd før den nye versjonen av applikasjonen rulles ut:
- Nye felt legges til der vi vil registrere de oppdaterte dataene.
- Vi overfører data fra det gamle feltet til det nye feltet i små deler. Hvorfor gjør vi dette? For det første kontrollerer vi alltid prosessen i denne prosessen. Vi vet at vi allerede har overført så mange partier og vi har så mange igjen.
- Og den andre positive effekten er at mellom hver slik batch lukker vi transaksjonen, åpner en ny, og dette lar autovakuumet fungere i henhold til platen, markerer tidsfrister for gjenbruk.
- For linjene som vises mens applikasjonen kjører (vi har fortsatt den gamle applikasjonen kjører), legger vi til en trigger som skriver nye verdier til nye felt. I vårt tilfelle er dette multiplikasjon med hundre av den gamle verdien.
- Hvis vi er helt sta og vil ha det samme feltet, vil vi ganske enkelt endre navn på feltene ved fullføring av alle migreringer og før vi ruller ut en ny versjon av applikasjonen. De gamle får et oppfunnet navn, og de nye feltene blir omdøpt til de gamle.
- Og først etter det lanserer vi en ny versjon av applikasjonen.
Og samtidig vil vi ikke få en oppblåsthet og vil ikke lide når det gjelder ytelse.
Det er her den tredje historien slutter.
Og nå litt mer detaljer om verktøyene som jeg nevnte i den aller første historien.
Før du søker etter bloat, må du installere utvidelsen .
For at du ikke trenger å komme med spørsmål, har vi allerede skrevet disse spørsmålene i arbeidet vårt. Du kan bruke dem. Det er to forespørsler her.
- Den første tar ganske lang tid å virke, men den vil vise deg de nøyaktige oppblåsningsverdiene fra tabellen.
- Den andre fungerer raskere og er veldig effektiv når du raskt skal vurdere om det er oppblåsthet eller ikke i henhold til tabellen. Og du bør også forstå at oppblåsthet alltid er tilstede i et Postgres-bord. Dette er en funksjon i MVCC-modellen.
- Og 20 % oppblåsthet er normalt for bord i de fleste tilfeller. Det vil si at du ikke bør bekymre deg og komprimere denne tabellen.
Vi fant ut hvordan vi identifiserer tabeller som er hovne med ubrukelige data.
Nå om hvordan du fikser oppblåsthet:
- Har vi et lite nettbrett og gode disker, altså på et nettbrett opp til en gigabyte, er det fullt mulig å bruke VACUUM FULL. Han vil ta en eksklusiv lås fra deg på bordet i noen sekunder og greit, men han vil gjøre alt raskt og hardt. Hva gjør VACUUM FULL? Den tar en eksklusiv lås på bordet og omskriver live-rader fra de gamle bordene til det nye bordet. Og til slutt erstatter han dem. Den sletter gamle filer og erstatter de gamle med nye. Men i løpet av arbeidet tar den en eksklusiv lås på bordet. Dette betyr at du ikke kan gjøre noe med denne tabellen: verken skrive til den, lese inn i den, eller endre den. Og VACUUM FULL krever ekstra diskplass for å skrive data.
- Neste verktøy . I sitt prinsipp ligner den veldig på VACUUM FULL, fordi den også skriver om data fra gamle filer til nye og erstatter dem i tabellen. Men samtidig trenger den ikke en eksklusiv lås på bordet helt i begynnelsen av arbeidet, men tar den bare i det øyeblikket den allerede har klare data for å erstatte filene. Kravene til diskressursene ligner kravene til VACUUM FULL. Du trenger ekstra diskplass, og dette er noen ganger kritisk hvis du har terabyte-tabeller. Og den er ganske prosessorsulten fordi den aktivt fungerer med I/O.
- Det tredje verktøyet er . Det er mer forsiktig med ressurser fordi det fungerer etter litt andre prinsipper. Hovedideen til pgcompacttable er at den flytter alle live-rader til begynnelsen av tabellen ved å bruke oppdateringer i tabellen. Og så kjører det et vakuum på dette bordet, fordi vi vet at vi har levende rader i begynnelsen og døde rader på slutten. Og selve vakuumet kutter av denne halen, det vil si at det ikke krever mye ekstra diskplass. Og samtidig kan det fortsatt presses ressursmessig.
Alt med verktøy.
Hvis du finner oppblåst emne interessant med tanke på å dykke lenger inne, her er noen nyttige linker:
- – Dette er en rapport fra min kollega. Det handler generelt om hvor Postgres plass går i løpet av arbeidet og livet. Og det er en veldig stor og detaljert teknisk del for databaseadministratorer om oppblåsthet.
- – dette er en lenke til vårt depot, hvor vi lagrer en haug med nyttige skript for å sjekke statusen til databasen. Der kan du finne skript for å søke etter oppblåsthet.
- и lenker til verktøy som vil hjelpe deg å krympe skilt.
- – Dette er et innlegg fra min kollega. Der analyserer han ganske seriøst og teknisk bloat i detalj på et nivå nært administratorer.
Jeg prøvde mer å vise en skrekkhistorie for utviklere, fordi de er våre direkte kunder av databaser og må forstå hva og hvilke handlinger som fører til. Jeg håper jeg lyktes. Takk for din oppmerksomhet!
spørsmål
Takk for rapporten! Du snakket om hvordan du kan identifisere problemer. Hvordan kan de bli advart? Det vil si at jeg hadde en situasjon der forespørslene hang ikke bare fordi de fikk tilgang til noen eksterne tjenester. Dette var bare noen ville sammenføyninger. Det var noen bittesmå, harmløse forespørsler som hang rundt i en dag, og så begynte å gjøre noe tull. Altså veldig likt det du beskriver. Hvordan spore dette? Sitte og hele tiden se hvilken forespørsel som sitter fast? Hvordan kan dette forhindres?
I dette tilfellet er dette en oppgave for administratorene i din bedrift, ikke nødvendigvis for DBA.
Jeg er administrator.
PostgreSQL har en visning kalt pg_stat_activity som viser hengende spørringer. Og du kan se hvor lenge den henger der.
Må jeg komme inn og se hvert 5. minutt?
Sett opp cron og sjekk. Hvis du har en langsiktig forespørsel, skriv et brev og det er det. Det vil si at du ikke trenger å se med øynene, det kan automatiseres. Du vil motta et brev, du reagerer på det. Eller du kan skyte automatisk.
Er det noen åpenbare grunner til at dette skjer?
Jeg har listet opp noen. Andre mer komplekse eksempler. Og det kan være en samtale i lang tid.
Takk for rapporten! Jeg ønsket å avklare om pg_repack-verktøyet. Hvis hun ikke gjør en eksklusiv lås, så...
Hun lager en eksklusiv lås.
... da kan jeg potensielt miste data. Bør ikke applikasjonen min registrere noe i løpet av denne tiden?
Nei, det fungerer problemfritt med tabellen, dvs. pg_repack overfører først alle live-linjene som finnes. Naturligvis skjer det en slags inntreden i tabellen der. Han kaster bare denne hestehalen ut.
Det vil si at han faktisk gjør det til slutt?
Til slutt tar han en eksklusiv lås for å bytte disse filene.
Vil det være raskere enn VAKUUM FULL?
VACUUM FULL, så snart den startet, tok umiddelbart en eksklusiv lås. Og før han gjør alt, vil han ikke la henne gå. Og pg_repack tar en eksklusiv lås bare på tidspunktet for filutskifting. I dette øyeblikket vil du ikke skrive der, men dataene vil ikke gå tapt, alt vil gå bra.
Hallo! Du snakket om driften av en bilstøvsuger. Det var en graf med røde, gule og grønne registreringsceller. Det vil si gule - han markerte dem som slettet. Og som et resultat kan noe nytt skrives inn i dem?
Ja. Postgres sletter ikke linjer. Han har en slik spesifisitet. Hvis vi oppdaterte en linje, markerte vi den gamle som slettet. ID-en til transaksjonen som endret denne linjen vises der, og vi skriver en ny linje. Og vi har økter som potensielt kan lese dem. På et tidspunkt blir de ganske gamle. Og essensen av hvordan autovakuum fungerer er at det går gjennom disse linjene og markerer dem som unødvendige. Og du kan overskrive data der.
Jeg forstår. Men det er ikke det spørsmålet handler om. Jeg ble ikke ferdig. La oss anta at vi har en tabell. Den har felt av variabel størrelse. Og hvis jeg prøver å sette inn noe nytt, kan det rett og slett ikke passe inn i den gamle cellen.
Nei, i alle fall er hele linjen oppdatert der. Postgres har to datalagringsmodeller. Den velger fra datatypen. Det er data som lagres direkte i tabellen, og det er også tos-data. Dette er store mengder data: tekst, json. De oppbevares i separate tallerkener. Og ifølge disse tablettene oppstår den samme historien med oppblåsthet, det vil si at alt er det samme. De er bare oppført separat.
Takk for rapporten! Er det akseptabelt å bruke tidsavbruddsspørringer for å begrense varigheten?
Veldig akseptabelt. Vi bruker dette overalt. Og siden vi ikke har våre egne tjenester, tilbyr vi ekstern støtte, vi har ganske mange forskjellige kunder. Og alle er helt fornøyd med dette. Det vil si at vi har cron-jobber som sjekker. Varigheten av øktene avtales ganske enkelt med klienten, før dette er vi ikke enige. Det kan være et minutt, det kan være 10 minutter. Det avhenger av belastningen på basen og formålet. Men vi bruker alle pg_stat_activity.
Takk for rapporten! Jeg prøver å bruke rapporten din på søknadene mine. Og det virker som om vi starter en transaksjon overalt, og klart fullfører den overalt. Hvis det er noen unntak, skjer tilbakerulling fortsatt. Og så begynte jeg å tenke. Tross alt kan det hende at transaksjonen ikke starter eksplisitt. Dette er nok et hint til jenta. Hvis jeg bare oppdaterer en post, vil transaksjonen starte i PostgreSQL og først fullføres når tilkoblingen kobles fra?
Hvis du snakker nå om applikasjonsnivået, så avhenger det av driveren du bruker, på ORM som brukes. Det er mange innstillinger der. Hvis du har aktivert automatisk forpliktelse, starter en transaksjon der og avsluttes umiddelbart.
Det vil si at den stenger umiddelbart etter oppdateringen?
Det avhenger av innstillingene. Jeg nevnte én innstilling. Dette er automatisk commit på. Det er ganske vanlig. Hvis det er aktivert, har transaksjonen åpnet og lukket. Med mindre du eksplisitt sa "start transaksjon" og "avslutt transaksjon", men bare lanserte en forespørsel i økten.
Hallo! Takk for rapporten! La oss tenke oss at vi har en database som svulmer og svulmer og så går plassen på serveren tom. Finnes det noen verktøy for å fikse denne situasjonen?
Plassen på serveren må overvåkes ordentlig.
For eksempel gikk DBA for te, var på et feriested osv.
Når et filsystem er opprettet, opprettes det i det minste en slags backupplass der data ikke skrives.
Hva om det er helt under null?
Der kalles det reservert plass, det vil si at den kan frigjøres og avhengig av hvor stor den ble opprettet, får du ledig plass. Som standard vet jeg ikke hvor mange det er. Og i et annet tilfelle, lever disker slik at du har plass til å utføre en rekonstruktiv operasjon. Du kan slette en tabell som du garantert ikke trenger.
Finnes det andre verktøy?
Det er alltid håndlaget. Og lokalt blir det klart hva som er best å gjøre der, fordi noen data er kritiske og noen er ikke-kritiske. Og for hver database og applikasjonen som fungerer med den, avhenger det av virksomheten. Det avgjøres alltid lokalt.
Takk for rapporten! Jeg har to spørsmål. Først viste du lysbilder som viste at når transaksjoner sitter fast, vokser både tabellplassstørrelsen og indeksstørrelsen. Og videre på rapporten var det en haug med verktøy som pakker nettbrettet. Hva med indeksen?
De pakker dem også.
Men vakuumet påvirker ikke indeksen?
Noen jobber med en indeks. For eksempel, pg_rapack, pgcompacttable. Vakuumet gjenskaper indeksene og påvirker dem. Med VACUUM FULL er tanken å overskrive alt, det vil si at det fungerer med alle.
Og det andre spørsmålet. Jeg forstår ikke hvorfor rapporter om replikaer avhenger så mye av selve replikeringen. Det virket for meg at rapporter blir lest, og replikering er å skrive.
Hva forårsaker en replikeringskonflikt? Vi har en Master som prosesser foregår på. Vi har en bilstøvsuger på gang. Hva gjør en autovakuum egentlig? Han klipper ut noen gamle linjer. Hvis vi på dette tidspunktet har en forespørsel på replikaen som leser disse gamle linjene, og det oppsto en situasjon på Masteren at autovakuumet markerte disse linjene som mulige for overskrivning, så overskrev vi dem. Og vi mottok en datapakke, når vi trenger å skrive om linjene som forespørselen trenger på replikaen, vil replikeringsprosessen vente på tidsavbruddet du konfigurerte. Og så vil PostgreSQL bestemme hva som er viktigere for den. Og replikering er viktigere for ham enn forespørselen, og han vil skyte forespørselen for å gjøre disse endringene på replikaen.
Andrey, jeg har et spørsmål. Disse fantastiske grafene som du viste under presentasjonen, er disse et resultat av arbeidet med en slags verktøy for deg? Hvordan ble grafene laget?
Dette er en tjeneste .
Er dette et kommersielt produkt?
Ja. Dette er et kommersielt produkt.
Kilde: www.habr.com