Linux-indstilling for at forbedre PostgreSQL-ydeevnen. Ilya Kosmodemyansky

Transskription af 2015-rapporten af ​​Ilya Kosmodemyansky "Linux-indstilling for at forbedre PostgreSQL-ydelsen"

Ansvarsfraskrivelse: Jeg bemærker, at denne rapport er dateret november 2015 - der er gået mere end 4 år, og der er gået meget tid. Version 9.4, der er omtalt i rapporten, understøttes ikke længere. I løbet af de sidste 4 år har der været 5 nye udgivelser af PostgreSQL og 15 versioner af Linux-kernen. Hvis du omskriver disse steder, vil du ende med en anden rapport. Men her er en grundlæggende Linux-tuning til PostgreSQL, som stadig er relevant i dag.

Mit navn er Ilya Kosmodemyansky. Jeg arbejder for PostgreSQL-konsulentfirmaet. Og nu vil jeg snakke lidt om, hvad man skal gøre med Linux i forhold til databaser generelt og PostgreSQL i særdeleshed, for principperne er ret ens.

Hvad vil blive diskuteret? Hvis du har at gøre med PostgreSQL, så skal du være UNIX-administrator til en vis grad. Hvad betyder det? Hvis vi sammenligner Oracle og PostgreSQL, så skal du i Oracle være 80% DBA database admin og 20% ​​Linux admin.

PostgreSQL er lidt sværere. Med PostgreSQL skal du have en meget bedre ide om, hvordan Linux fungerer. Og løb samtidig lidt efter lokomotivet, for på det seneste er alt blevet opdateret ret fedt. Og nye kerner kommer ud, og ny funktionalitet dukker op, ydeevnen forbedres osv.

Hvorfor taler vi om Linux? Slet ikke fordi vi er til Linux-konferencen Peter, men fordi et af de mest berettigede styresystemer til at operere med databaser generelt og med PostgreSQL i moderne forhold er Linux. Fordi FreeBSD, desværre, udvikler sig i en eller anden meget mærkelig retning. Og der vil være problemer med både ydeevne og mange andre ting. Ydeevnen for PostgreSQL på Windows er generelt et særskilt barsk emne, der hviler på det faktum, at Windows ikke har en sådan delt hukommelse som UNIX, og PostgreSQL handler om denne forretning, fordi det er et multi-proces system.

Og eksotiske ting som Solaris, tror jeg, er af mindre interesse for alle, så lad os gå.

En moderne Linux-distribution har over 1 syctl-muligheder, afhængigt af hvordan kernen er bygget. Hvis vi samtidig ser på forskellige nødder, så kan der stadig være mange måder at justere noget på. Der er filsystem muligheder for, hvordan man monterer. Hvis du har spørgsmål om, hvordan du starter: hvad skal du aktivere i BIOS, hvordan du konfigurerer hardwaren osv.

Dette er en meget stor mængde, som kan tales om i flere dage, og ikke i en kort rapport, men jeg vil nu fokusere på vigtige ting, hvordan man undgår de rakes, der ikke vil tillade dig at betjene en database på Linux godt, hvis du fikser dem ikke.. Og samtidig er en vigtig pointe, at mange standardparametre ikke er inkluderet i de indstillinger, der er korrekte for databasen. Det vil sige, at det som standard vil fungere dårligt eller slet ikke virker.

Hvad er de traditionelle tuning-mål på Linux? Jeg tror, ​​at da I alle beskæftiger jer med Linux-administration, er der ingen grund til at forklare, hvad mål er.

Du kan tune:

• CPU.
• Hukommelse.
• Opbevaring.
• Andet. Vi vil tale om dette til sidst for en snack. Selv for eksempel indstillinger som strømsparepolitik kan påvirke ydeevnen på en meget uforudsigelig og ikke særlig behagelig måde.

Hvad er det specifikke ved PostgreSQL og databasen generelt? Problemet er, at du ikke kan justere en bestemt møtrik og se, at vores ydeevne er forbedret meget.

Ja, der er sådanne gadgets, men databasen er en kompliceret ting. Hun interagerer med alle de ressourcer, som serveren har, og foretrækker at interagere fuldt ud. Hvis du ser på Oracles nuværende retningslinjer for, hvordan man bruger et værts-OS, er det ligesom den mongolske astronauts joke – foder hunden og rør ikke ved noget. Lad os give databasen alle ressourcerne, selve databasen vil ødelægge alt.

I princippet er situationen til en vis grad nøjagtig den samme med PostgreSQL. Forskellen ligger i, at basen heller ikke er i stand til at tage alle ressourcerne for sig selv, det vil sige, et sted på Linux-niveau skal du ordne det hele på egen hånd.

Hovedideen er ikke at vælge et enkelt mål og begynde at tune det, for eksempel hukommelse, CPU eller sådan noget, men at analysere arbejdsbyrden og forsøge at forbedre gennemløbet så meget som muligt, så den belastning, som gode programmører skabte for os, herunder vores brugere.

Her er et billede for at forklare, hvad det er. Der er en Linux OS buffer, og der er delt hukommelse, og der er PostgreSQL delte buffere. PostgreSQL, i modsætning til Oracle, virker kun direkte gennem kernebufferen, det vil sige, for at en side fra disk kan komme ind i dens delte hukommelse, skal den gå gennem kernebufferen og tilbage nøjagtig den samme situation.

Diske lever under dette system. Jeg tegnede det som diske. Faktisk kan der være en RAID-controller osv.

Og dette input-output sker på den ene eller anden måde gennem denne forretning.

PostgreSQL er en klassisk database. Det er inde på siden. Og al input-output sker ved hjælp af sider. Vi hæver blokke i hukommelsen efter sider. Og hvis der ikke skete noget, læser vi dem bare, så synker de gradvist fra denne cache, fra delte buffere og kommer tilbage til disken.

Hvis vi har udskiftet noget et sted, så er hele vores side markeret som beskidt. Jeg har markeret dem med blåt her. Og det betyder, at denne side skal synkroniseres med bloklagring. Det vil sige, at når vi gjorde det beskidt, lavede vi en indtastning i WAL. Og på et eller andet fint tidspunkt kom et fænomen kaldet checkpoint. Og denne log registrerede oplysninger om, at han kom. Og det betyder, at alle de beskidte sider, der var her på det tidspunkt i disse delte buffere, blev synkroniseret med lagerdisken ved hjælp af fsync gennem kernebufferen.

Hvad er det for? Hvis vi mistede spænding, så fik vi ikke den situation, at alle data gik tabt. Vedvarende hukommelse, som alle fortalte os om, er indtil videre i databaseteorien - det er en lys fremtid, som vi selvfølgelig stræber efter, og vi kan lide det, men indtil videre lever de stadig om minus 20 år. Og alt dette skal selvfølgelig overvåges.

Og opgaven med at maksimere gennemløbet er at tune på alle disse stadier, så det hele går hurtigt frem og tilbage. Delt hukommelse er dybest set en sidecache. I PostgreSQL sendte vi en udvælgelse af noget der anmodning, den fik disse data fra disken. De kom ind i delte buffere. For at dette skal fungere bedre, skal der derfor være meget hukommelse.

For at alt dette skal fungere godt og hurtigt, skal du konfigurere operativsystemet korrekt på alle stadier. Og vælg balanceret jern, for hvis du har en ubalance et eller andet sted, så kan du lave en masse hukommelse, men det bliver serveret med utilstrækkelig hastighed.

Lad os gennemgå hvert af disse punkter.

For at disse sider kan rejse hurtigere frem og tilbage, skal du opnå følgende:

• For det første skal du arbejde mere effektivt med hukommelsen.
• For det andet burde denne overgang være mere effektiv, når sider fra hukommelsen går til disk.
• Og for det tredje skal der være gode skiver.

Hvis du har 512 GB RAM på serveren, og alt dette ender på en SATA-harddisk uden nogen cache, så bliver hele databaseserveren ikke bare til et græskar, men til et græskar med et SATA-interface. Du vil løbe direkte ind i det. Og intet vil redde dig.

Hvad angår det første punkt med hukommelsen, er der tre ting, der kan gøre livet meget svært.

Den første er NUMA. NUMA er en ting, der er lavet for at forbedre ydeevnen. Alt efter arbejdsbelastningen kan du optimere forskellige ting. Og i sin nye nuværende form er den ikke særlig god til applikationer som en database, der intensivt bruger sidecache-delte buffere.

I en nøddeskal. Hvordan forstår man, at der er noget galt med NUMA? Du får en form for ubehagelig bank, pludselig er en eller anden CPU overbelastet. Samtidig analyserer du forespørgsler i PostgreSQL og ser, at der ikke er noget lignende der. Disse anmodninger bør ikke være så CPU-intensive. Du kan fange det i lang tid. Det er nemmere at bruge de rigtige råd fra starten af, hvordan man opsætter NUMA til PostgreSQL.

Hvad foregår der egentlig? NUMA står for Non-Uniform Memory Access. Hvad er pointen? Du har en CPU, ved siden af ​​den er der dens lokale hukommelse. Og disse hukommelsesforbindelser kan trække hukommelse fra andre CPU'er.

Hvis du løber numactl --hardware, så får du sådan et stort ark. Der vil blandt andet være et distancefelt. Der vil være tal - 10-20, sådan noget. Disse tal er intet andet end antallet af hop for at hente denne fjernhukommelse og bruge den lokalt. Grundlæggende en god idé. Dette forbedrer ydeevnen godt i en række arbejdsbelastninger.

Forestil dig nu, at du har én CPU, der først prøver at bruge dens lokale hukommelse, og derefter prøver at trække en anden hukommelse op via sammenkobling til noget. Og hele din PostgreSQL-sidecache kommer til denne CPU - det er det, hvor mange gigabyte er der. Du får altid det værste tilfælde, fordi der normalt er lidt hukommelse på CPU'en direkte i det modul. Og al den hukommelse, der serveres, går gennem disse forbindelser. Det viser sig langsomt og trist. Og du har en processor, der betjener denne node er konstant overbelastet. Og adgangstiden for denne hukommelse er dårlig, langsom. Det er den slags situation, du ikke ønsker, hvis du bruger denne sag til en database.

Derfor er en mere korrekt mulighed for databasen, at Linux-operativsystemet slet ikke ved, hvad der sker der. Så hun henvender sig til hukommelsen, som hun tiltaler.

Hvorfor det? Det ser ud til, at det burde være omvendt. Dette sker af en simpel grund, at vi har brug for meget hukommelse til sidecache - titusinder, hundredvis af gigabyte.

Og hvis vi allokerer alt dette og cachelagrede vores data der, så vil gevinsten ved at bruge cachen være betydeligt større end gevinsten fra sådan en snedig hukommelsesadgang. Og på denne måde vil vi vinde uforlignelig i forhold til, at vi får adgang til hukommelsen mere effektivt ved hjælp af NUMA.

Derfor er der to tilgange i øjeblikket, indtil en lys fremtid er kommet, og databasen ikke selv kan finde ud af, hvilke CPU'er den fungerer på, og hvor den skal trække noget fra.

Derfor er den korrekte tilgang at deaktivere NUMA helteks ved genstart. I de fleste tilfælde er gevinsterne i sådanne rækkefølger, at der overhovedet ikke er nogen tvivl, hvilket er bedre.

Der er en anden mulighed. Vi bruger det oftere end den første, for når en klient kommer til os for at få support, så er det en hel ting for ham at genstarte serveren. Han har en forretning der. Og de oplever problemer på grund af NUMA. Derfor forsøger vi at deaktivere det på mindre invasive måder end at genstarte, men her skal du være opmærksom på at tjekke, at det er deaktiveret. Fordi, som erfaringen viser, at vi deaktiverer NUMA på den overordnede proces af PostgreSQL, er dette godt, men det er slet ikke nødvendigt, at dette vil virke. Vi skal tjekke og se, at hun virkelig slukkede.

Der er et godt indlæg af Robert Haas. Dette er en af ​​PostgreSQL-committerne. En af nøgleudviklerne af alle indmad på lavt niveau. Og hvis du følger linkene fra dette indlæg, beskriver det flere farverige historier om, hvordan NUMA gjorde livet svært for mennesker. Se, læs systemadministratorens tjekliste over, hvad der skal konfigureres på serveren, for at vores database kan fungere godt. Disse indstillinger skal registreres og kontrolleres, for ellers bliver det ikke særlig godt.

Jeg gør opmærksom på, at dette gælder for alle de indstillinger, som jeg vil tale om. Men normalt samles databaser i master-slave-tilstand for fejltolerance. Glem ikke at lave disse indstillinger på slaven, for en dag kommer du ud for en ulykke, og du skifter til slaven, og den bliver herre.

I en nødsituation, når alt er meget dårligt, din telefon konstant ringer, og din chef kommer løbende med en stor pind, vil du ikke have tid til at tænke på at tjekke. Og resultaterne kan være meget katastrofale.

Det næste øjeblik er store sider. Kæmpe sider er svære at teste separat, og det nytter ikke noget, selvom der er benchmarks, der kan gøre dette. De er nemt at google.

Hvad er pointen? Du har en ikke særlig dyr server, der har meget RAM, for eksempel mere end 30 GB. Du bruger ikke store sider. Dette betyder, at du helt sikkert har en overhead på hukommelsesforbrug. Og denne overhead er langt fra den mest behagelige.

Hvorfor det? Og hvad sker der? Operativsystemet tildeler hukommelse i små bidder. Så praktisk, så historisk. Og hvis du går i detaljer, så skal OS'et oversætte virtuelle adresser til fysiske. Og denne proces er ikke den nemmeste, så OS cacher resultatet af denne operation i Translation Lookaside Buffer (TLB).

Og da TLB er en cache, så opstår i denne situation alle de problemer, der er iboende i cachen. For det første, hvis du har meget RAM, og det hele er allokeret i små bidder, så bliver denne buffer meget stor. Og hvis cachen er stor, så er det langsommere at søge efter det. Overhead er sundt og optager plads i sig selv, det vil sige, at der er noget galt med at forbruge RAM. Denne gang.

To - jo mere cachen vokser i en sådan situation, jo mere sandsynligt er det, at du vil have cache-misser. Og effektiviteten af ​​denne cache falder hurtigt, efterhånden som dens størrelse vokser. Så operativsystemer kom op med en enkel tilgang. Linux har brugt det i lang tid. Det dukkede op i FreeBSD for ikke så længe siden. Men vi taler om Linux. Det er store sider.

Og her skal det bemærkes, at enorme sider, som en idé, oprindeligt blev presset igennem af fællesskaber, der omfattede Oracle og IBM, det vil sige, at databaseproducenter tænkte grundigt over, at dette ville være nyttigt, også til databaser.

Og hvordan bliver man venner med PostgreSQL? For det første skal enorme sider aktiveres i Linux-kernen.

For det andet skal de udtrykkeligt specificeres af sysctl-parameteren - hvor mange der er. Tallene her er fra en gammel server. Du kan beregne cirka hvor mange delte buffere du har, så store sider passer der.

Og hvis du har hele serveren dedikeret til PostgreSQL, så er et godt udgangspunkt enten at give 25% RAM til delte buffere, eller 75% hvis du er sikker på at din database helt sikkert vil passe ind i disse 75%. Udgangspunkt først. Og overvej, hvis du har 256 GB RAM, vil du derfor have 64 GB shred-buffere. Beregn cirka med en vis margin - hvad du skal have dette tal sat til.

Før version 9.2 (hvis jeg ikke tager fejl, siden version 8.2) var det muligt at blive venner med store PostgreSQL-sider ved hjælp af et tredjepartsbibliotek. Og dette bør altid gøres. Først skal du bruge kernen for at kunne allokere enorme sider korrekt. Og for det andet, så den applikation, der arbejder med dem, kan bruge dem. Det bliver bare ikke brugt på den måde. Da PostgreSQL allokerede hukommelse i en system 5-stil, kunne dette gøres ved hjælp af libhugetlbfs - dette er det fulde navn på biblioteket.

9.3 forbedrede PostgreSQL-hukommelsesydelsen og fjernede system 5-hukommelsesallokeringsmetoden. Alle var meget glade, for ellers prøver man at køre to PostgreSQL-instanser på samme maskine, og han siger, at jeg ikke har nok delt hukommelse. Og han siger, at du skal rette sysctl. Og der er sådan en sysctl, at du stadig skal genstarte osv. Generelt var alle glade. Men tildeling af mmap-hukommelse gik i stykker ved at bruge enorme sider. De fleste af vores kunder bruger store fælles buffere. Og vi anbefalede kraftigt ikke at skifte til 9.3, fordi der begyndte at blive beregnet overhead i gode procenter.

Men på den anden side gjorde samfundet opmærksom på dette problem, og i 9.4 omarbejdede de denne begivenhed meget godt. Og i 9.4 dukkede en parameter op i postgresql.conf, hvor du kan slå try, til eller fra.

Prøv er den mest sikre mulighed. Når PostgreSQL starter, når den tildeler delt hukommelse, forsøger den at fange denne hukommelse fra enorme sider. Og hvis det ikke virker, så ruller det tilbage til det sædvanlige udvalg. Og hvis du har FreeBSD eller Solaris, så kan du prøve, det er altid sikkert.

Hvis den er aktiveret, så starter den simpelthen ikke, hvis den ikke kunne vælge fra store sider. Her allerede - til hvem og hvad er mere sød. Men hvis du har et forsøg, så tjek, at du virkelig har fremhævet det, du har brug for, for der er mange pladser til en fejl. I øjeblikket virker denne funktionalitet kun på Linux.

Endnu en lille bemærkning inden vi går videre. Gennemsigtige enorme sider handler ikke om PostgreSQL endnu. Han kan ikke bruge dem normalt. Og med gennemsigtige enorme sider til sådan en arbejdsbyrde, når du har brug for et stort stykke delt hukommelse, kommer fordelene kun med meget store mængder. Hvis du har terabyte hukommelse, kan dette spille en rolle. Hvis vi taler om mere hverdagsapplikationer, når du har 32, 64, 128, 256 GB hukommelse på maskinen, så er de sædvanlige enorme sider Ok, og vi slår bare Transparent fra.

Og det sidste ved hukommelsen er ikke direkte relateret til fruput, det kan ødelægge livet rigtig meget. Al gennemstrømning vil i høj grad blive påvirket af, at serveren konstant skifter.

Og det vil være meget ubehageligt på nogle punkter. Og det største problem er, at adfærden i moderne kerner er lidt anderledes end ældre Linux-kerner. Og denne ting, som er ret ubehagelig at træde på, for når vi taler om noget arbejde med bytte, ender det med den alt for tidlige ankomst af OOM-morderen. Og OOM-dræberen, som ikke kom i tide og smed PostgreSQL af sig, er ubehagelig. Alle vil vide om det, det vil sige indtil den sidste bruger.

Hvad sker der? Du har en stor mængde RAM der, alt fungerer godt. Men af ​​en eller anden grund hænger serveren i swap og sænker farten på grund af dette. Det ser ud til, at der er meget hukommelse, men det sker.

Tidligere anbefalede vi vm.swappiness at være sat til nul, dvs. deaktiver swap. Tidligere så det ud til, at 32 GB RAM og tilsvarende delte buffere var en enorm mængde. Hovedformålet med byttet er at have et sted at kaste en skorpe, hvis vi falder af. Og det er ikke blevet gjort særlig godt. Og hvad vil du så gøre med denne skorpe? Dette er allerede sådan en opgave, når det ikke er særlig klart, hvorfor det er nødvendigt at bytte, især af en sådan størrelse.

Men i mere moderne, dvs. i den tredje version af kernen, har adfærden ændret sig. Og hvis du indstiller swap til nul, dvs. slår det fra, så vil før eller siden, selv med noget RAM tilbage, en OOM-dræber komme til dig for at dræbe de mest intensive forbrugere. For han vil overveje, at med sådan en arbejdsbyrde har vi stadig en lille smule tilbage, og vi vil springe ud, altså ikke dræbe systemprocessen, men dræbe noget mindre vigtigt. Denne mindre vigtige vil være storforbrugeren af ​​delt hukommelse, nemlig postmesteren. Og derefter vil det være godt, hvis basen ikke skal genoprettes.

Derfor er standarden, så vidt jeg husker, de fleste distributioner et sted omkring 6, dvs. på hvilket tidspunkt man skal begynde at bruge swap, afhængigt af hvor meget hukommelse der er tilbage. Vi anbefaler nu at indstille vm.swappiness = 1, fordi det praktisk talt slår det fra, men ikke giver sådanne effekter som med en uventet OOM-dræber, der kom og dræbte det hele.

Hvad er det næste? Når vi taler om databasers ydeevne og gradvist, gradvist, er vi som diske, begynder alle at gribe deres hoveder. Fordi sandheden om, at disken er langsom og hukommelsen er hurtig, har været kendt for alle siden barndommen. Og alle ved, at der vil være problemer med diskens ydeevne i databasen.

Det største PostgreSQL-ydeevneproblem med checkpoints-spidser er ikke, fordi disken er langsom. Dette er mere sandsynligt på grund af det faktum, at hukommelsen og diskbåndbredden ikke er afbalanceret. De kan dog ikke være afbalanceret forskellige steder. PostgreSQL er ikke konfigureret, OS er ikke konfigureret, hardware er ikke konfigureret og hardware er forkert. Og dette problem opstår ikke kun, hvis alt går som det skal, dvs. enten er der ingen belastning, eller indstillingerne og hardwaren er velvalgte.

Hvad er det og hvordan ser det ud? Normalt er folk, der arbejder med PostgreSQL, gået ind i denne forretning mere end én gang. Jeg vil forklare. Som sagt laver PostgreSQL med jævne mellemrum kontrolpunkter for at dumpe beskidte sider i delt hukommelse til disk. Hvis vi har en stor mængde delt hukommelse, begynder checkpoint at påvirke disken intensivt, fordi fsync dumper disse sider. Den ankommer i kernebufferen og skrives til disk ved hjælp af fsync. Og hvis volumen af ​​denne sag er stor, så kan vi observere en ubehagelig effekt, nemlig en meget stor udnyttelse af diske.

Her har jeg to billeder. Jeg vil nu forklare, hvad det er. Disse er to tidskorrelerede grafer. Den første graf er diskudnyttelse. Her når den næsten 90 % på dette tidspunkt. Hvis du har et databasefald med fysiske diske, med en RAID-controller under 90% udnyttelse, så er dette dårlige nyheder. Det betyder, at der kommer lidt mere og 100, og input/output stopper.

Hvis du har et diskarray, så er der en lidt anden historie. Der kommer det an på hvordan det er konfigureret, hvilken slags array osv.

Og sideløbende her konfigureres en graf fra den interne postgres-visning, som fortæller, hvordan checkpointet opstår. Og den grønne farve her viser, hvor mange buffere af disse beskidte sider i det øjeblik, der ankom til dette kontrolpunkt for synkronisering. Og det er det vigtigste at vide her. Vi ser, at vi har mange sider her og på et tidspunkt løb vi ind i et gebyr, det vil sige, vi skrev og skrev, her er disksystemet tydeligvis meget optaget. Og vores checkpoint har en meget stærk effekt på disken. Ideelt set skulle situationen se mere sådan ud, dvs. vi havde mindre rekord her. Og vi kan rette det med indstillinger, så det fortsætter sådan. Det vil sige, at genbruget er lille, men et eller andet sted skriver vi noget her.

Hvad skal der gøres for at overvinde dette problem? Hvis du har stoppet IO under databasen, betyder det, at alle brugere, der kom for at udføre deres anmodninger, venter.

Hvis du ser fra Linux-synspunktet, hvis du tog god hardware, konfigurerede det korrekt, konfigurerede PostgreSQL normalt, så det ville lave disse kontrolpunkter sjældnere, sprede dem i tid mellem hinanden, så træder du ind i Debian-standardparametrene . For de fleste Linux-distributioner er dette billedet: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Hvad betyder det? Siden kerne 2.6 er der dukket op på én dæmon-flushing. Pdglush, afhængigt af hvem der bruger hvad, som handler om, at baggrunden smider beskidte sider af fra kernebufferen og smider beskidte sider af, når det er nødvendigt, uanset hvad, når baggrundskastningen ikke hjælper.

Hvornår kommer baggrunden? Når 10% af den samlede RAM, der er på serveren, er optaget af beskidte sider i kernebufferen, så kaldes en speciel snydefunktion i baggrunden. Hvorfor har hun baggrund? Det tager som parameter, hvor mange sider der skal afskrives. Og lad os sige, afskriver N sider. Og for et stykke tid falder denne ting i søvn. Og så kommer hun tilbage og afskriver nogle flere sider.

Dette er en meget enkel historie. Her er opgaven som med en pool, når den hælder i et rør, hælder i et andet. Vores kontrolpunkt kom, og hvis det sendte et par beskidte sider til kassering, så vil det hele gradvist løses pænt fra kernebufferen pgflush.

Hvis disse snavsede sider fortsætter med at akkumulere, akkumuleres de op til 20%, derefter er OS-prioriteten at afskrive det hele til disken, fordi strømmen vil flyve ud, og alt vil være dårligt for os. Vi mister f.eks. disse data.

Hvad er fidusen? Tricket er, at disse parametre i den moderne verden på 20 og 10% af al den RAM, der er på maskinen, de er helt monstrøse med hensyn til gennemstrømningen af ​​ethvert disksystem, du har.

Forestil dig, at du har 128 GB RAM. 12,8 GB kommer til dit disksystem. Og uanset hvilken cache du har der, uanset hvilken array du har der, vil de ikke modstå så meget.

Derfor anbefaler vi, at disse tal justeres med det samme afhængigt af din RAID-controllers muligheder. Jeg gav straks en anbefaling her til en controller, der har 512 MB cache.

Alt betragtes som meget simpelt. Du kan sætte vm.dirty_background i bytes. Og disse indstillinger tilsidesætter de to foregående. Enten er forholdet som standard, eller dem med bytes er aktiveret, så vil dem med bytes fungere. Men da jeg er DBA-konsulent og arbejder med forskellige kunder, forsøger jeg at lægge sugerør og derfor, hvis i bytes, så i bytes. Ingen gav nogen garanti for, at en god administrator ikke ville tilføje hukommelse til serveren, ikke genstarte den, og tallet ville forblive det samme. Bare udregn disse tal, så alt passer der med garanti.

Hvad sker der, hvis du ikke passer ind? Jeg har skrevet, at det effektivt stopper enhver rødmen, men faktisk er det en talemåde. Operativsystemet har et stort problem - det har mange beskidte sider, så den IO, som dine klienter genererer, stopper effektivt, dvs. applikationen er kommet til at sende en sql-forespørgsel til databasen, den venter. Enhver I/O til den har den laveste prioritet, fordi basen er optaget af kontrolpunktet. Og når hun er færdig, er det helt uforståeligt. Og når du har nået ikke-baggrund, ikke-baggrundsskylning, betyder det, at hele din IO er optaget af det. Og indtil det slutter, vil du ikke gøre noget.

Der er yderligere to vigtige punkter, som ligger uden for denne betænknings rammer. Disse indstillinger skal matche indstillingerne i postgresql.conf, dvs. indstillingerne for kontrolpunkter. Og dit disksystem skal være tilstrækkeligt konfigureret. Hvis du har en cache på RAID'en, så skal den have et batteri. Folk køber RAID med god cache uden batteri. Hvis du har en SSD i RAID, så skal det være server, der skal være kondensatorer. Her er den udvidede tjekliste. På dette link er der min rapport om hvordan man opsætter diskydeevne i PostgreSQL. Alle de tjeklister er der.

Hvad ellers kan gøre livet meget svært? Det er to muligheder. De er forholdsvis nye. Som standard kan de inkluderes i forskellige applikationer. Og de kan komplicere livet lige så meget, hvis de er tændt forkert.

Der er to relativt nye stykker. De er allerede dukket op i de tredje kerner. Disse er sched_migration_cost i nanosekunder og sched_autogroup_enabled, som er en som standard.

Og hvordan ødelægger de livet? Hvad er sched_migration_cost? Linux-planlæggeren kan migrere en proces fra én CPU til en anden. Og for PostgreSQL, som udfører forespørgsler, er det fuldstændig uforståeligt at migrere til en anden CPU. Fra et operativsystem synspunkt, når du skifter vinduer mellem openoffice og terminal, kan det være fint, men for databasen - det er meget dårligt. Derfor er en rimelig politik at sætte migration_cost til en eller anden stor værdi, mindst et par tusinde nanosekunder.

Hvad vil det betyde for planlæggeren? Det antages, at denne proces stadig er varm i denne periode. Det vil sige, at hvis du har en form for lang transaktion, der gør noget i lang tid, vil planlæggeren forstå dette. Han vil antage, at indtil denne timeout går, så behøver denne proces ikke at blive migreret nogen steder. Hvis processen samtidig gør noget, så vil den ikke blive migreret nogen steder, den vil roligt afslutte på den CPU, der blev allokeret til den. Og resultatet er fremragende.

Det andet punkt er autogruppe. Der er en god idé til specifikke arbejdsbelastninger, der ikke er relateret til moderne databaser - det er at gruppere processer efter den virtuelle terminal, hvorfra de startes. Det er praktisk til nogle opgaver. I praksis er PostgreSQL et prefork multi-proces system, der kører fra en enkelt terminal. Du har en låseskriver, et kontrolpunkt, og alle dine klientanmodninger er grupperet i en planlægger pr. CPU. Og de vil vente sammen der, når han er fri, for at blande sig i hinanden og holde ham beskæftiget længere. Dette er en historie, der er helt unødvendig i tilfælde af en sådan belastning, og derfor bør den slukkes.

Min kollega Alexey Lesovsky lavede test med en simpel pgbench, hvor han øgede migration_cost med en størrelsesorden og slog autogruppe fra. Forskellen på et dårligt stykke jern viste sig at være næsten 10 %. Der er en diskussion på postgres-mailinglisten, hvor folk rapporterer resultater som lignende ændringer i forespørgselshastigheden påvirket 50 %. Der er en del sådanne historier.

Og endelig om strømbesparelsespolitikken. Det er godt, at Linux nu kan bruges på en bærbar. Og det vil angiveligt forbruge batteriet godt. Men pludselig viser det sig, at dette også kan ske på serveren.

Desuden, hvis du lejer servere fra en hoster, så er "gode" hostere ligeglade med, at du har bedre ydeevne. Deres opgave er at sørge for, at deres jern bliver udnyttet så effektivt som muligt. Derfor kan de som standard aktivere den bærbare strømsparetilstand på operativsystemet.

Hvis du bruger dette på en stærkt belastet databaseserver, så er dit valg acpi_cpufreq + permormance. Selv med ondemand vil der allerede være problemer.

Intel_pstate er en lidt anderledes driver. Og nu gives fortrinsret til denne, som til en senere og bedre fungerende.

Og derfor er guvernøren kun præstation. Ondemand, strømbesparelse og alt det andet - det handler ikke om dig.

Resultaterne af forklar analyse PostgreSQL kan afvige i flere størrelsesordener, hvis du slår strømbesparelse til, fordi du i praksis vil have CPU-udfald under databasen på en fuldstændig uforudsigelig måde.

Disse ting kan aktiveres som standard. Se omhyggeligt for at se, om de er aktiveret som standard. Dette kan være et rigtig stort problem.

Og til sidst ville jeg sige tak til fyrene fra vores PosgreSQL-Consulting DBA-team, nemlig Max Boguk og Alexey Lesovsky, som hver dag udfylder bump i denne forretning. Og for vores kunder forsøger vi at gøre det bedste, så det hele fungerer for dem. Det er ligesom med luftfartssikkerhedsinstruktioner. Alt her er skrevet med blod. Hver af disse nødder opdages i færd med en eller anden form for problem. Jeg er glad for at dele dem med dig.

Spørgsmål:

Tak skal du have! Hvis for eksempel en virksomhed vil spare penge og hoste databasen og applikationslogikken på samme server, eller hvis virksomheden følger modetrenden med mikroservicearkitekturer, hvor PostgreSQL kører i en container. Hvad er pointen? Sysctl påvirker hele kernen globalt. Jeg har ikke hørt, at sysctl på en eller anden måde er virtualiseret, så de fungerer separat på containeren. Der er kun cgroup, og kun en del af den har kontrol. Hvordan kan du leve med dette? Eller hvis du vil have ydeevne, så kør PostgreSQL på en separat jernserver og tune den?

Vi har besvaret dit spørgsmål på cirka tre måder. Hvis vi ikke taler om en jernserver, der kan tunes osv., så slap af, alt fungerer fint uden disse indstillinger. Hvis du har en sådan belastning, at du skal foretage disse indstillinger, så kommer du til jernserveren tidligere end disse indstillinger.

Hvad er problemet? Hvis dette er en virtuel maskine, så vil du højst sandsynligt have mange problemer, for eksempel med det faktum, at de fleste virtuelle maskiner har ret inkonsekvent disklatens. Selvom diskgennemstrømningen er god, en enkelt mislykket I/O-transaktion, som ikke i høj grad påvirker den gennemsnitlige gennemstrømning, der skete på tidspunktet for kontrolpunktet eller på tidspunktet for skrivningen til WAL, så vil databasen lide meget under dette. Og du vil bemærke dette, før du løber ind i disse problemer.

Hvis du har NGINX på den samme server, vil du også have det samme problem. Han vil kæmpe for fælles hukommelse. Og du når ikke de problemer, der er beskrevet her.

Men på den anden side vil nogle af disse parametre stadig være relevante for dig. For eksempel, med sysctl, indstil dirty_ratio, så det ikke er så skørt - under alle omstændigheder vil dette hjælpe. På en eller anden måde vil du have interaktion med disken. Og det bliver forkert. Dette er generelt standarden for de parametre, jeg viste. Og under alle omstændigheder er det bedre at ændre dem.

Og med NUMA kan der være problemer. VmWare fungerer for eksempel godt med NUMA med præcis de modsatte indstillinger. Og her skal du vælge - en jernserver eller en ikke-jernet.

Jeg har et spørgsmål relateret til Amazon AWS. De har billeder forudkonfigureret. En af dem hedder Amazon RDS. Er der nogen brugerdefinerede indstillinger for deres operativsystem?

Der er indstillinger, men det er forskellige indstillinger. Her konfigurerer vi styresystemet i forhold til, hvordan databasen vil bruge denne virksomhed. Og der er parametre, der bestemmer, hvor vi skal hen nu, sådan en formgivning. Det vil sige, at vi har brug for så mange ressourcer, vi vil æde dem op nu. Derefter fastgør Amazon RDS disse ressourcer, og ydeevnen falder der. Der er separate historier om, hvordan folk begynder at kemi med denne sag. Nogle gange endda ganske vellykket. Men det har intet at gøre med OS-indstillinger. Det er ligesom cloud hacking. Det er en anden historie.

Hvorfor har gennemsigtige enorme sider ingen effekt sammenlignet med enorme TLB?

Giv ikke. Dette kan forklares på mange måder. Men faktisk giver de det bare ikke. Hvad er historien om PostgreSQL? Ved opstart tildeler den en stor del af delt hukommelse. Gennemsigtige de er på samme tid eller ikke gennemsigtige - det er lige meget. Det, at de skiller sig ud i starten, forklarer alt. Og hvis der er meget hukommelse, og du skal genopbygge shared_memory-segmentet, så vil gennemsigtige enorme sider være relevante. I PostgreSQL er det blot fremhævet i starten med et kæmpe stykke og det er det, og så sker der ikke noget særligt der. Du kan selvfølgelig bruge det, men der er en chance for at få curruption shared_memory, når den gentildeler noget. PostgreSQL kender ikke til dette.

Kilde: www.habr.com