Linux-innstilling for å forbedre PostgreSQL-ytelsen. Ilya Kosmodemyansky

Transkripsjon av 2015-rapporten av Ilya Kosmodemyansky "Linux-innstilling for å forbedre PostgreSQL-ytelsen"

Ansvarsfraskrivelse: Jeg legger merke til at denne rapporten er datert november 2015 - mer enn 4 år har gått og mye tid har gått. Versjon 9.4 som er omtalt i rapporten støttes ikke lenger. I løpet av de siste 4 årene har 5 nye utgivelser av PostgreSQL blitt utgitt, og 15 versjoner av Linux-kjernen har blitt utgitt. Hvis du skriver om disse passasjene, vil du ende opp med en annen rapport. Men her vurderer vi grunnleggende Linux-innstilling for PostgreSQL, som fortsatt er relevant i dag.

Mitt navn er Ilya Kosmodemyansky. Jeg jobber hos PostgreSQL-Consulting. Og nå skal jeg snakke litt om hva jeg skal gjøre med Linux i forhold til databaser generelt og PostgreSQL spesielt, fordi prinsippene er ganske like.

Hva skal vi snakke om? Hvis du kommuniserer med PostgreSQL, må du til en viss grad være UNIX-administrator. Hva betyr det? Hvis vi sammenligner Oracle og PostgreSQL, må du i Oracle være 80 % DBA-databaseadministrator og 20 % Linux-admin.

Med PostgreSQL er det litt mer komplisert. Med PostgreSQL må du ha en mye bedre forståelse av hvordan Linux fungerer. Og samtidig løpe litt etter lokomotivet, for i det siste har alt blitt oppdatert ganske fint. Og nye kjerner slippes, og ny funksjonalitet vises, ytelsen forbedres, etc.

Hvorfor snakker vi om Linux? Ikke i det hele tatt fordi vi er på Linux-konferansen Peter, men fordi et av de mest berettigede operativsystemene for bruk av databaser generelt og PostgreSQL spesielt i moderne forhold er Linux. Fordi FreeBSD, dessverre, utvikler seg i en veldig merkelig retning. Og det vil være problemer både med ytelsen og med mange andre ting. Ytelsen til PostgreSQL på Windows er generelt et eget alvorlig problem, basert på det faktum at Windows ikke har det samme delte minnet som UNIX, mens PostgreSQL er knyttet til dette, fordi det er et multiprosesssystem.

Og jeg tror alle er mindre interessert i eksotiske ting som Solaris, så la oss gå.

En moderne Linux-distribusjon har over 1 syctl-alternativer, avhengig av hvordan du bygger kjernen. Samtidig, hvis vi ser på de forskjellige mutterne, kan vi justere noe på mange måter. Det er filsystemparametere for hvordan du monterer dem. Hvis du har spørsmål om hvordan du starter det: hva du skal aktivere i BIOS, hvordan du konfigurerer maskinvaren, etc.

Dette er et veldig stort volum som kan diskuteres over flere dager, og ikke i en kort rapport, men nå skal jeg fokusere på viktige ting, hvordan unngå de rakene som garantert hindrer deg i å bruke databasen din godt på Linux hvis du ikke rett dem. Og samtidig er et viktig poeng at mange standardparametere ikke er inkludert i innstillingene som er riktige for databasen. Det vil si at det som standard vil fungere dårlig eller ikke i det hele tatt.

Hvilke tradisjonelle tuning-mål finnes i Linux? Jeg tror at siden dere alle har med Linux-administrasjon å gjøre, er det ikke noe særlig behov for å forklare hva mål er.

Можно тюнить:

• CPU.
• Hukommelse.
• Oppbevaring.
• Annen. Vi snakker om dette på slutten for en matbit. Selv for eksempel parametere som energisparepolitikk kan påvirke ytelsen på en svært uforutsigbar og ikke den mest behagelig måte.

Hva er detaljene til PostgreSQL og databasen generelt? Problemet er at du ikke kan justere noen individuelle mutter og se at ytelsen vår har forbedret seg betydelig.

Ja, det finnes slike gadgets, men en database er en kompleks ting. Den samhandler med alle ressursene som serveren har og foretrekker å samhandle til det fulle. Hvis du ser på Oracles nåværende anbefalinger om hvordan du bruker et verts-OS, vil det være som spøken om den mongolske kosmonauten - mat hunden og ikke rør noe. La oss gi databasen alle ressursene, selve databasen vil ordne opp i alt.

I prinsippet er situasjonen til en viss grad nøyaktig den samme med PostgreSQL. Forskjellen er at databasen ennå ikke er i stand til å ta alle ressursene for seg selv, det vil si et sted på Linux-nivået må du ordne opp selv.

Hovedideen er ikke å velge et enkelt mål og begynne å justere det, for eksempel minne, CPU eller noe sånt, men å analysere arbeidsbelastningen og prøve å forbedre gjennomstrømningen så mye som mulig slik at belastningen som gode programmerere skapte den for oss, inkludert våre brukere.

Her er et bilde for å forklare hva det er. Det er en Linux OS-buffer og det er delt minne og det er PostgreSQL delte buffere. PostgreSQL, i motsetning til Oracle, fungerer bare direkte gjennom kjernebufferen, det vil si at for at en side fra disken skal komme inn i det delte minnet, må den gå gjennom kjernebufferen og tilbake, nøyaktig samme situasjon.

Disker lever under dette systemet. Jeg tegnet dette som disker. Faktisk kan det være en RAID-kontroller, etc.

Og denne input-output på en eller annen måte skjer gjennom denne saken.

PostgreSQL er en klassisk database. Det er en side inni. Og all input og output skjer ved hjelp av sider. Vi hever blokker inn i minnet med sider. Og hvis ingenting skjedde, leser vi dem bare, så forsvinner de gradvis fra denne cachen, fra de delte bufferne og havner tilbake på disken.

Hvis vi erstatter noe et sted, blir hele siden merket som skitten. Jeg merket dem her med blått. Og dette betyr at denne siden må synkroniseres med blokklagring. Det vil si at når vi gjorde det skittent, gjorde vi en oppføring i WAL. Og på et eller annet fantastisk tidspunkt kom et fenomen kalt sjekkpunkt. Og det ble registrert informasjon i denne loggen om at han var kommet. Og dette betyr at alle de skitne sidene som var her på det tidspunktet i disse delte bufferne ble synkronisert med lagringsdisken ved å bruke fsync gjennom kjernebufferen.

Hvorfor gjøres dette? Hvis vi mistet spenningen, så fikk vi ikke situasjonen at all data gikk tapt. Vedvarende hukommelse, som alle fortalte oss om, er så langt i databaseteorien - dette er en lys fremtid, som vi selvfølgelig streber etter og vi liker det, men for nå lever de om minus 20 år. Og selvfølgelig må alt dette overvåkes.

Og oppgaven med å maksimere gjennomstrømningen er å finjustere på alle disse stadiene slik at det hele beveger seg raskt frem og tilbake. Delt minne er i utgangspunktet en sidebuffer. I PostgreSQL sendte vi en utvalgsspørring eller noe, den hentet disse dataene fra disken. De havnet i delte buffere. Følgelig, for at dette skal fungere bedre, må det være mye minne.

For at alt dette skal fungere godt og raskt, må du konfigurere operativsystemet riktig i alle stadier. Og velg balansert maskinvare, for hvis du har ubalanse et sted, så kan du lage mye minne, men det vil ikke bli betjent i tilstrekkelig hastighet.

Og la oss gå gjennom hvert av disse punktene.

For å få disse sidene til å reise frem og tilbake raskere, må du oppnå følgende:

• For det første må du jobbe mer effektivt med minne.
• For det andre bør denne overgangen når sider fra minne går til disk være mer effektiv.
• Og for det tredje må det være gode disker.

Hvis du har 512 GB RAM på serveren og alt ender opp på en SATA-harddisk uten cache, blir hele databaseserveren ikke bare til et gresskar, men et gresskar med et SATA-grensesnitt. Du vil støte på det direkte. Og ingenting vil redde deg.

Når det gjelder det første punktet med hukommelse, er det tre ting som kan gjøre livet veldig vanskelig.

Den første av dem er NUMA. NUMA er en ting som er laget for å forbedre ytelsen. Avhengig av arbeidsmengden kan forskjellige ting optimaliseres. Og i sin nye nåværende form er det ikke særlig bra for applikasjoner som databaser som intensivt bruker delte buffere for sidebuffer.

I et nøtteskall. Hvordan kan du finne ut om noe er galt med NUMA? Du har en slags ubehagelig banking, plutselig er en CPU overbelastet. Samtidig analyserer du spørringer i PostgreSQL og ser at det ikke er noe lignende der. Disse spørringene bør ikke være så CPU-intensive. Dette kan du fange lenge. Det er lettere å bruke riktig anbefaling helt fra begynnelsen av hvordan du konfigurerer NUMA for PostgreSQL.

Hva skjer egentlig? NUMA står for Non-Uniform Memory Access. Hva er poenget? Du har en CPU, ved siden av den er det det lokale minnet. Og disse minneforbindelsene kan trekke opp minne fra andre CPUer.

Hvis du løper numactl --hardware, så får du et så stort ark. Det blir blant annet et avstandsfelt. Det blir tall - 10-20, noe sånt. Disse tallene er ikke mer enn antall hopp for å plukke opp dette eksterne minnet og bruke det lokalt. I prinsippet en god idé. Dette øker ytelsen godt under en rekke arbeidsbelastninger.

Tenk deg nå at du har én CPU som først prøver å bruke det lokale minnet, og deretter prøver å trekke opp et annet minne via sammenkobling for noe. Og denne CPU-en får hele PostgreSQL-sidebufferen din - det er det, noen gigabyte. Du får alltid det verste tilfellet, for på CPUen er det vanligvis lite minne i selve modulen. Og alt minnet som betjenes går gjennom disse sammenkoblingene. Det viser seg tregt og trist. Og prosessoren din som betjener denne noden er konstant overbelastet. Og tilgangstiden til dette minnet er dårlig, treg. Dette er situasjonen du ikke ønsker hvis du bruker dette for en database.

Derfor er et mer riktig alternativ for databasen at Linux-operativsystemet ikke vet hva som skjer der i det hele tatt. Slik at den får tilgang til minnet som den gjør.

Hvorfor det? Det ser ut til at det burde være omvendt. Dette skjer av én enkel grunn: vi trenger mye minne for sidebufferen - titalls, hundrevis av gigabyte.

Og hvis vi allokerte alt dette og cachede dataene våre der, så vil gevinsten ved å bruke cachen være betydelig større enn gevinsten fra en så vanskelig tilgang til minnet. Og vi vil dermed ha en uforlignelig fordel sammenlignet med det faktum at vi får tilgang til minne mer effektivt ved å bruke NUMA.

Derfor er det to tilnærminger her for øyeblikket, helt til den lyse fremtiden har kommet, og databasen selv ikke klarer å finne ut hvilke CPUer den kjører på og hvor den må hente noe fra.

Derfor er den riktige tilnærmingen å deaktivere NUMA helt, for eksempel ved omstart. I de fleste tilfeller er gevinstene av en slik størrelsesorden at spørsmålet om hva som er best ikke oppstår i det hele tatt.

Det er et annet alternativ. Vi bruker den oftere enn den første, fordi når en klient kommer til oss for å få støtte, er det en stor sak for ham å starte serveren på nytt. Han har en virksomhet der. Og de opplever problemer på grunn av NUMA. Derfor prøver vi å deaktivere den på mindre invasive måter enn omstart, men vær forsiktig med å sjekke at den er deaktivert. Fordi, som erfaring viser, er det bra at vi deaktiverer NUMA på den overordnede PostgreSQL-prosessen, men det er slett ikke nødvendig at det vil fungere. Vi må sjekke og se at hun virkelig slo seg av.

Det er et godt innlegg av Robert Haas. Dette er en av PostgreSQL-committerne. En av nøkkelutviklerne av alle lavnivå-innmat. Og hvis du følger lenkene fra dette innlegget, beskriver de flere fargerike historier om hvordan NUMA gjorde livet vanskelig for mennesker. Se, studer systemadministratorens sjekkliste over hva som må konfigureres på serveren for at databasen vår skal fungere bra. Disse innstillingene må skrives ned og kontrolleres, for ellers blir det ikke veldig bra.

Vær oppmerksom på at dette gjelder alle innstillinger som jeg vil snakke om. Men vanligvis samles databaser i master-slave-modus for feiltoleranse. Ikke glem å gjøre disse innstillingene på slaven fordi en dag vil du ha en ulykke og du vil bytte til slaven og den vil bli masteren.

I en nødsituasjon, når alt er veldig dårlig, telefonen ringer konstant og sjefen din kommer løpende med en stor pinne, vil du ikke ha tid til å tenke på å sjekke. Og resultatene kan være ganske katastrofale.

Neste punkt er store sider. Enorme sider er vanskelig å teste hver for seg, og det er ingen vits i å gjøre det, selv om det finnes benchmarks som kan gjøre dette. De er enkle å Google.

Hva er poenget? Du har en ikke veldig dyr server med mye RAM, for eksempel mer enn 30 GB. Du bruker ikke store sider. Dette betyr at du definitivt har overhead når det gjelder minnebruk. Og denne overheaden er langt fra den mest behagelige.

Hvorfor det? Så hva skjer? Operativsystemet tildeler minne i små biter. Det er så praktisk, det er slik det skjedde historisk. Og hvis vi går i detalj, må operativsystemet oversette virtuelle adresser til fysiske. Og denne prosessen er ikke den enkleste, så OS cacher resultatet av denne operasjonen i Translation Lookaside Buffer (TLB).

Og siden TLB er en cache, oppstår alle problemene som ligger i en cache i denne situasjonen. For det første, hvis du har mye RAM og alt er tildelt i små biter, blir denne bufferen veldig stor. Og hvis cachen er stor, går det tregere å søke gjennom den. Overhead er sunt og tar i seg selv plass, det vil si at RAM blir konsumert av noe feil. Denne gangen.

To - jo mer cachen vokser i en slik situasjon, jo mer sannsynlig er det at du vil ha cache-misser. Og effektiviteten til denne cachen reduseres raskt ettersom størrelsen øker. Derfor kom operativsystemene opp med en enkel tilnærming. Det har vært brukt i Linux i lang tid. Det dukket opp i FreeBSD for ikke så lenge siden. Men vi snakker om Linux. Dette er store sider.

Og her bør det bemerkes at enorme sider, som en idé, i utgangspunktet ble presset av fellesskap som inkluderte Oracle og IBM, dvs. databaseprodusenter trodde sterkt at dette ville være nyttig for databaser også.

Og hvordan kan dette bli venner med PostgreSQL? For det første må enorme sider aktiveres i Linux-kjernen.

For det andre må de spesifiseres eksplisitt av sysctl-parameteren - hvor mange det er. Tallene her er fra en gammel server. Du kan beregne hvor mange delte buffere du har slik at store sider får plass der.

Og hvis hele serveren din er dedikert til PostgreSQL, så er et godt utgangspunkt å allokere enten 25 % av RAM til delte buffere, eller 75 % hvis du er sikker på at databasen din definitivt vil passe inn i disse 75 %. Utgangspunkt én. Og tenk på at hvis du har 256 GB RAM, vil du følgelig ha 64 GB store buffere. Beregn omtrentlig med litt margin - hva dette tallet skal settes til.

Før versjon 9.2 (hvis jeg ikke tar feil, siden versjon 8.2), var det mulig å koble PostgreSQL med enorme sider ved hjelp av et tredjepartsbibliotek. Og dette bør alltid gjøres. Først trenger du kjernen for å kunne tildele enorme sider riktig. Og for det andre, slik at applikasjonen som fungerer med dem kan bruke dem. Det vil ikke bare brukes på den måten. Siden PostgreSQL allokerte minne i system 5-stilen, kan dette gjøres ved å bruke libhugetlbfs - dette er det fulle navnet på biblioteket.

I 9.3 ble PostgreSQL-ytelsen forbedret ved arbeid med minne, og system 5-minnetildelingsmetoden ble forlatt. Alle var veldig fornøyde, for ellers prøver du å kjøre to PostgreSQL-forekomster på en maskin, og han sier at jeg ikke har nok delt minne. Og han sier at sysctl må korrigeres. Og det er en slik sysctl at du fortsatt trenger å starte på nytt osv. Generelt var alle fornøyde. Men tildeling av mmap-minne brøt bruken av enorme sider. De fleste av våre kunder bruker store delte buffere. Og vi anbefalte på det sterkeste å ikke bytte til 9.3, fordi overhead der begynte å bli beregnet i gode prosenter.

Men samfunnet tok hensyn til dette problemet, og i 9.4 omarbeidet de denne hendelsen veldig bra. Og i 9.4 dukket det opp en parameter i postgresql.conf der du kan aktivere forsøk, på eller av.

Prøv er det sikreste alternativet. Når PostgreSQL starter, når den tildeler delt minne, prøver den å hente dette minnet fra de enorme sidene. Og hvis det ikke fungerer, går det tilbake til det normale valget. Og hvis du har FreeBSD eller Solaris, så kan du prøve, det er alltid trygt.

Hvis den er på, starter den rett og slett ikke hvis den ikke kunne velge fra de enorme sidene. Her handler det allerede om hvem og hva som er finest. Men hvis du har prøvd, så sjekk at du virkelig har uthevet det du trenger, for det er mye rom for feil. Foreløpig fungerer denne funksjonaliteten bare på Linux.

En liten merknad til før vi går videre. Gjennomsiktige enorme sider handler ikke om PostgreSQL ennå. Han kan ikke bruke dem normalt. Og med transparente enorme sider for en slik arbeidsmengde, når et stort stykke delt minne er nødvendig, kommer fordelene bare med svært store volumer. Hvis du har terabyte med minne, kan dette spille inn. Hvis vi snakker om mer hverdagslige applikasjoner, når du har 32, 64, 128, 256 GB minne på maskinen din, så er de vanlige enorme sidene Ok, og vi deaktiverer ganske enkelt Transparent.

Og det siste med hukommelse er ikke direkte relatert til frukt, det kan virkelig ødelegge livet ditt. All gjennomstrømming vil bli sterkt påvirket av at serveren stadig bytter.

Og dette vil være veldig ubehagelig på flere måter. Og hovedproblemet er at moderne kjerner oppfører seg litt annerledes enn eldre Linux-kjerner. Og denne tingen er ganske ubehagelig å tråkke på, for når vi snakker om en slags arbeid med bytte, ender det med den utidige ankomsten til OOM-morderen. Og OOM-morderen, som ikke kom i tide og droppet PostgreSQL, er ubehagelig. Alle vil vite om dette, det vil si helt til siste bruker.

Hva skjer? Du har en stor mengde RAM der, alt fungerer bra. Men av en eller annen grunn henger serveren i swap og bremser ned på grunn av dette. Det ser ut til at det er mye minne, men dette skjer.

Tidligere anbefalte vi å sette vm.swappiness til null, det vil si å deaktivere swap. Tidligere så det ut til at 32 GB RAM og tilsvarende delte buffere var en enorm mengde. Hovedformålet med byttet er å ha et sted å kaste skorpen hvis vi faller av. Og det var ikke lenger spesielt oppfylt. Og hva skal du gjøre med denne skorpen? Dette er en oppgave hvor det ikke er veldig klart hvorfor bytte er nødvendig, spesielt av en slik størrelse.

Men i mer moderne, dvs. tredje versjoner av kjernen, har oppførselen endret seg. Og hvis du setter swap til null, dvs. slår den av, så før eller siden, selv om det er litt RAM igjen, vil en OOM-killer komme til deg for å drepe de mest intensive forbrukerne. Fordi han vil vurdere at med en slik arbeidsmengde har vi fortsatt litt igjen og vi vil hoppe ut, det vil si ikke for å spikre fast systemprosessen, men for å spikre noe mindre viktig. Denne mindre viktige vil være den intensive forbrukeren av delt minne, nemlig postmesteren. Og etter det vil det være bra hvis basen ikke må gjenopprettes.

Derfor, nå standard, så vidt jeg husker, er de fleste distribusjoner et sted rundt 6, dvs. på hvilket tidspunkt bør du begynne å bruke swap avhengig av hvor mye minne som er igjen. Vi anbefaler nå å sette vm.swappiness = 1, fordi dette praktisk talt slår den av, men ikke gir de samme effektene som med en OOM-killer som uventet kom og drepte hele greia.

Hva blir det neste? Når vi snakker om ytelsen til databaser og gradvis beveger oss mot disker, begynner alle å ta tak i hodet. Fordi sannheten om at disken er treg og minnet er rask er kjent for alle fra barndommen. Og alle vet at databasen vil ha problemer med diskytelse.

Det viktigste PostgreSQL-ytelsesproblemet knyttet til sjekkpunktspiker oppstår ikke fordi disken er treg. Dette er mest sannsynlig på grunn av det faktum at minne og diskbåndbredde ikke er balansert. Imidlertid kan de ikke balanseres på forskjellige steder. PostgreSQL er ikke konfigurert, OS er ikke konfigurert, maskinvaren er ikke konfigurert og maskinvaren er feil. Og dette problemet skjer ikke bare hvis alt skjer som det skal, det vil si enten det ikke er noen belastning, eller innstillingene og maskinvaren er godt valgt.

Hva er det og hvordan ser det ut? Vanligvis har folk som jobber med PostgreSQL gått inn i denne saken mer enn én gang. Jeg skal forklare. Som sagt, PostgreSQL lager med jevne mellomrom sjekkpunkter for å dumpe skitne sider i delt minne til disk. Hvis vi har en stor mengde delt minne, begynner sjekkpunkt å ha en intensiv innvirkning på disken, fordi den dumper disse sidene med fsync. Den kommer til kjernebufferen og skrives til disker ved hjelp av fsync. Og hvis volumet av denne virksomheten er stort, kan vi observere en ubehagelig effekt, nemlig en veldig stor utnyttelse av disker.

Her har jeg to bilder. Jeg skal nå forklare hva det er. Dette er to tidskorrelerte grafer. Den første grafen er diskutnyttelse. Her når den nesten 90 % på dette tidspunktet. Hvis du har en databasefeil med fysiske disker, med en RAID-kontrollerutnyttelse på 90 %, så er dette dårlige nyheter. Dette betyr at litt mer og det vil nå 100 og I/O vil stoppe.

Hvis du har en diskarray, er det en litt annen historie. Det avhenger av hvordan det er konfigurert, hva slags array det er osv.

Og parallelt konfigureres her en graf fra den interne postgres-visningen, som forteller hvordan sjekkpunktet oppstår. Og den grønne fargen her viser hvor mange buffere, disse skitne sidene, i det øyeblikket ankom dette sjekkpunktet for synkronisering. Og dette er det viktigste du trenger å vite her. Vi ser at vi har mange sider her og på et tidspunkt traff vi brettet, det vil si at vi skrev og skrev, her er disksystemet helt klart veldig travelt. Og sjekkpunktet vårt har en veldig sterk innvirkning på disken. Ideelt sett burde situasjonen se mer slik ut, det vil si at vi hadde mindre opptak her. Og vi kan fikse det med innstillingene slik at det fortsetter å være slik. Det vil si at gjenvinningen er liten, men et sted skriver vi noe her.

Hva må gjøres for å overvinne dette problemet? Hvis du har stoppet IO under databasen, betyr dette at alle brukere som kom for å oppfylle sine forespørsler vil vente.

Hvis du ser fra Linux-synspunktet, hvis du tok god maskinvare, konfigurerte den riktig, konfigurerte PostgreSQL normalt slik at den gjør disse sjekkpunktene sjeldnere, sprer dem over tid mellom hverandre, så går du inn i standard Debian-parametere. For de fleste Linux-distribusjoner er dette bildet: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Hva betyr det? En spylingsdemon dukket opp fra kjerne 2.6. Pdglush, avhengig av hvem som bruker hvilken, som er engasjert i bakgrunnskasting av skitne sider fra kjernebufferen og forkasting når det er nødvendig å forkaste skitne sider uansett hva, når bakgrunnskasting ikke hjelper.

Når kommer bakgrunnen? Når 10 % av total RAM tilgjengelig på serveren er okkupert av skitne sider i kjernebufferen, kalles en spesiell avskrivingsfunksjon i bakgrunnen. Hvorfor er det bakgrunn? Som en parameter tar den hensyn til hvor mange sider som skal avskrives. Og la oss si at han avskriver N sider. Og for en stund sovner denne tingen. Og så kommer hun igjen og kopierer noen sider til.

Dette er en ekstremt enkel historie. Problemet her er som med et svømmebasseng, når det renner inn i ett rør, renner det inn i et annet. Kontrollpunktet vårt ankom, og hvis det sendte noen skitne sider for forkasting, vil det hele gradvis løses pent fra kjernebufferen pgflush.

Hvis disse skitne sidene fortsetter å samle seg, akkumuleres de opptil 20%, hvoretter OS-prioriteten er å skrive av hele greia til disken, fordi strømmen vil svikte og alt blir dårlig for oss. Vi mister for eksempel disse dataene.

Hva er trikset? Trikset er at disse parameterne i den moderne verden er 20 og 10% av den totale RAM-en som er på maskinen, de er helt monstrøse når det gjelder gjennomstrømmingen til ethvert disksystem du har.

Tenk deg at du har 128 GB RAM. 12,8 GB kommer til disksystemet ditt. Og uansett hvilken cache du har der, uansett hvilken array du har der, vil de ikke vare så lenge.

Derfor anbefaler vi at du umiddelbart justerer disse tallene basert på egenskapene til RAID-kontrolleren. Jeg ga umiddelbart en anbefaling her for en kontroller som har 512 MB cache.

Alt anses som veldig enkelt. Du kan sette vm.dirty_background i byte. Og disse innstillingene avbryter de to foregående. Enten forholdet er som standard, eller de med byte er aktivert, så vil de med byte fungere. Men siden jeg er DBA-konsulent og jobber med forskjellige kunder, prøver jeg å trekke sugerør og derfor, hvis i byte, så i byte. Ingen ga noen garanti for at en god admin ikke ville legge til mer minne til serveren, starte den på nytt, og tallet ville forbli det samme. Bare regn ut disse tallene slik at alt passer inn der med garanti.

Hva skjer hvis du ikke passer inn? Jeg har skrevet at enhver rødming effektivt stoppes, men faktisk er dette en talemåte. Operativsystemet har et stort problem - det har mange skitne sider, så IO-en som dine klienter genererer blir effektivt stoppet, det vil si at applikasjonen har kommet for å sende en sql-spørring til databasen, den venter. Enhver input/output til den har lavest prioritet, fordi databasen er okkupert av et sjekkpunkt. Og når hun blir ferdig er det helt uklart. Og når du har oppnådd ikke-bakgrunnsspyling, betyr det at all IO er opptatt av det. Og inntil det slutter, vil du ikke gjøre noe.

Det er ytterligere to viktige punkter her som ligger utenfor rammen av denne rapporten. Disse innstillingene skal samsvare med innstillingene i postgresql.conf, dvs. sjekkpunktinnstillinger. Og disksystemet ditt må være tilstrekkelig konfigurert. Hvis du har en cache på en RAID, så må den ha et batteri. Folk kjøper RAID med god cache uten batteri. Hvis du har SSD-er i RAID, så må de være servere, det må være kondensatorer der. Her er en detaljert sjekkliste. Denne lenken inneholder rapporten min om hvordan du konfigurerer en ytelsesdisk i PostgreSQL. Det er alle disse sjekklistene der.

Hva annet kan gjøre livet veldig vanskelig? Dette er to parametere. De er relativt nye. Som standard kan de inkluderes i forskjellige applikasjoner. Og de kan gjøre livet like vanskelig hvis de slås feil på.

Det er to relativt nye ting. De har allerede dukket opp i de tredje kjernene. Dette er sched_migration_cost i nanosekunder og sched_autogroup_enabled, som er en som standard.

Og hvordan ødelegger de livet ditt? Hva er sched_migration_cost? På Linux kan planleggeren migrere en prosess fra én CPU til en annen. Og for PostgreSQL, som utfører spørringer, er migrering til en annen CPU helt uklart. Fra et operativsystem synspunkt, når du bytter windows mellom openoffice og terminal, kan dette være bra, men for en database er dette veldig dårlig. Derfor er en rimelig policy å sette migration_cost til en eller annen stor verdi, minst flere tusen nanosekunder.

Hva vil dette bety for planleggeren? Det vil bli vurdert at i løpet av denne tiden er prosessen fortsatt varm. Det vil si at hvis du har en langvarig transaksjon som har gjort noe lenge, vil planleggeren forstå dette. Han vil anta at inntil denne tidsavbruddet går, er det ikke nødvendig å migrere denne prosessen noe sted. Hvis prosessen samtidig gjør noe, vil den ikke bli migrert noe sted, den vil stille og rolig fungere på CPU-en som ble tildelt den. Og resultatet er utmerket.

Det andre punktet er autogruppe. Det er en god idé for spesifikke arbeidsbelastninger som ikke er relatert til moderne databaser - dette er å gruppere prosesser etter den virtuelle terminalen de lanseres fra. Dette er praktisk for noen oppgaver. I praksis er PostgreSQL et multiprosesssystem med en forgaffel som kjører fra en enkelt terminal. Du har en låseskriver, sjekkpunkt, og alle klientforespørslene dine vil bli gruppert i én planlegger, per CPU. Og de vil vente der unisont på at han skal være fri, for å forstyrre hverandre og holde ham opptatt lenger. Dette er en historie som er helt unødvendig i tilfelle en slik belastning og derfor må den slås av.

Min kollega Alexey Lesovsky gjorde tester med en enkel pgbench, hvor han økte migration_cost med en størrelsesorden og slo av autogruppe. Forskjellen på dårlig maskinvare var nesten 10 %. Det er en diskusjon på postgres e-postliste der folk gir resultater av lignende endringer i spørringshastighet påvirket 50 %. Det er ganske mange slike historier.

Og til slutt, om strømsparingspolitikk. Det gode er at Linux nå kan brukes på en bærbar datamaskin. Og den vil visstnok bruke opp batteriet godt. Men plutselig viser det seg at dette også kan skje på serveren.

Dessuten, hvis du leier servere fra en eller annen hoster, bryr ikke de "gode" hosterne seg om at du har bedre ytelse. Deres oppgave er å sørge for at jernet deres blir utnyttet så effektivt som mulig. Derfor kan de som standard aktivere strømsparingsmodus for bærbar datamaskin på operativsystemet.

Hvis du bruker disse tingene på en server med en database under tung belastning, er valget ditt acpi_cpufreq + permormance. Selv med ondemand vil det være problemer.

Intel_pstate er en litt annen driver. Og nå foretrekkes denne, som den er senere og fungerer bedre.

Og følgelig er guvernør bare ytelse. Ondemand, strømsparing og alt annet handler ikke om deg.

Resultatene av forklaringsanalysen PostgreSQL kan variere med flere størrelsesordener hvis du aktiverer strømsparing, fordi praktisk talt CPUen under databasen din vil kjøre på en helt uforutsigbar måte.

Disse elementene kan være inkludert som standard. Se nøye for å se om de har slått den på som standard. Dette kan være et veldig stort problem.

Og til slutt ville jeg si takk til gutta fra vårt PosgreSQL-Consulting DBA-team, nemlig Max Boguk og Alexey Lesovsky, som gjør fremskritt i denne saken hver dag. Og vi prøver å gjøre det beste vi kan for kundene våre slik at alt fungerer for dem. Det er som med flysikkerhetsinstruksjoner. Alt her er skrevet i blod. Hver av disse nøttene er funnet i ferd med en slags problem. Jeg deler dem gjerne med deg.

spørsmål:

Takk skal du ha! Hvis for eksempel et selskap ønsker å spare penger og plassere databasen og applikasjonslogikken på én server, eller hvis selskapet følger den moteriktige trenden med mikrotjenestearkitekturer, der PostgreSQL kjører i en container. Hva er trikset? Sysctl vil påvirke hele kjernen globalt. Jeg har ikke hørt om sysctls som på en eller annen måte er virtualisert slik at de fungerer separat på en container. Det er bare en cgroup og det er bare en del av kontrollen der. Hvordan kan du leve med dette? Eller hvis du vil ha ytelse, så kjør PostgreSQL på en egen maskinvareserver og finjuster den?

Vi svarte på spørsmålet ditt på omtrent tre måter. Hvis vi ikke snakker om en maskinvareserver som kan stilles inn osv., så slapp av, alt vil fungere fint uten disse innstillingene. Hvis du har en slik belastning at du må gjøre disse innstillingene, så kommer du til jernserveren tidligere enn til disse innstillingene.

Hva er problemet? Hvis dette er en virtuell maskin, vil du mest sannsynlig ha mange problemer, for eksempel med det faktum at på de fleste virtuelle maskiner er latensen til disken ganske inkonsekvent. Selv om diskgjennomstrømningen er god, så vil én mislykket I/O-transaksjon som ikke i stor grad påvirker den gjennomsnittlige gjennomstrømningen som skjedde på tidspunktet for sjekkpunkt eller i skrivende stund til WAL, da vil databasen lide mye av dette. Og du vil merke dette før du støter på disse problemene.

Hvis du har NGINX på samme server, vil du også ha det samme problemet. Han vil kjempe for felles minne. Og du kommer ikke til problemene som er beskrevet her.

Men på den annen side vil noen av disse parameterne fortsatt være relevante for deg. Sett for eksempel dirty_ratio med sysctl slik at det ikke er så sprøtt - i alle fall vil dette hjelpe. På en eller annen måte vil du ha interaksjon med disken. Og det blir etter feil mønster. Dette er vanligvis en standard for parameterne jeg viste. Og i alle fall er det bedre å endre dem.

Men det kan være problemer med NUMA. VmWare, for eksempel, fungerer bra med NUMA med nøyaktig motsatte innstillinger. Og her må du velge - en jernserver eller en ikke-jernholdig.

Jeg har et spørsmål knyttet til Amazon AWS. De har forhåndskonfigurerte bilder. En av dem heter Amazon RDS. Er det noen egendefinerte innstillinger for deres operativsystem?

Det er innstillinger der, men det er forskjellige innstillinger. Her konfigurerer vi operativsystemet i forhold til hvordan databasen vil bruke denne tingen. Og det er parametere som bestemmer hvor vi skal gå nå, for eksempel forming. Det vil si at vi trenger så mange ressurser, vi skal nå spise dem opp. Etter dette strammer Amazon RDS inn disse ressursene, og ytelsen synker der. Det er individuelle historier om hvordan folk begynner å rote med denne saken. Noen ganger til og med ganske vellykket. Men dette har ingenting med OS-innstillinger å gjøre. Det er som å hacke skyen. Det er en annen historie.

Hvorfor har Transparente enorme sider ingen effekt sammenlignet med Huge TLB?

Ikke gi. Dette kan forklares på mange måter. Men faktisk gir de det rett og slett ikke. Hva er historien til PostgreSQL? Ved oppstart tildeler den et stort stykke delt minne. Om de er gjennomsiktige eller ikke er helt irrelevant. Det at de skiller seg ut i starten forklarer alt. Og hvis det er mye minne og du trenger å gjenoppbygge shared_memory-segmentet, vil Transparente enorme sider være relevante. I PostgreSQL blir det ganske enkelt tildelt i en stor del i starten, og det er det, og så skjer det ikke noe spesielt der. Du kan selvfølgelig bruke det, men det er en sjanse for å få en korrupsjon av shared_memory når den tildeler noe på nytt. PostgreSQL vet ikke om dette.

Kilde: www.habr.com