serveren<\/a> and all of this ultimately connects to a SATA hard drive without any cache, the entire database server will turn not just into a pumpkin, but into a pumpkin with a SATA interface. You will hit this directly. And nothing will save you.<\/p>\n<\/p>\n
<\/p>\n
Regarding the first point with memory, there are three things that can greatly complicate life. <\/p>\n
<\/p>\n
The first of these is NUMA. NUMA is designed to improve performance. Depending on the workload, different things can be optimized. In its new current form, it is not very good for applications like databases that extensively use page cache shared buffers. <\/p>\n
<\/p>\n
<\/p>\n
In short, how do you know something is wrong with NUMA? You have some unpleasant glitches, suddenly some CPU is overloaded. Meanwhile, you analyze queries in PostgreSQL and see that there is nothing similar there. These queries should not consume CPU so intensively. It can take a long time to catch this. It\u2019s easier to use the right recommendation from the start on how to configure NUMA for PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
What is actually happening? NUMA stands for Non-Uniform Memory Access. What is its essence? You have a CPU, and next to it is its local memory. And this memory interconnect can access memory from other CPUs.<\/p>\n
<\/p>\n
If you run numactl --hardware<\/code>, you will get a long output. Among other things, there will be a field for distances. There will be numbers - 10-20, something like that. These numbers represent the number of hops to access and use that remote memory locally. In principle, it\u2019s a good idea. It significantly improves performance under certain loads.<\/p>\n<\/p>\n
Forestil dig, at du har en CPU, der f\u00f8rst fors\u00f8ger at bruge sit lokale hukommelse, og derefter fors\u00f8ger at hente anden hukommelse via interconnect til noget. Og p\u00e5 denne CPU kommer hele din page cache fra PostgreSQL \u2013 hvor mange gigabyte det nu er. Du f\u00e5r altid den v\u00e6rste situation, fordi der normalt er lidt hukommelse direkte i denne hukommelsesmodul. Al hukommelse, der betjenes, g\u00e5r gennem disse interconnects. Det bliver langsomt og trist. Og du har en processor, der betjener denne node, der konstant er overbelastet. Og adgangstiden til denne hukommelse er d\u00e5rlig og langsom. Det er den situation, du ikke \u00f8nsker, hvis du bruger det til en database. <\/p>\n
<\/p>\n
Derfor er en mere korrekt l\u00f8sning for databasen, at operativsystemet Linux overhovedet ikke ved, hvad der foreg\u00e5r. S\u00e5 det vil tilg\u00e5 hukommelsen som det skal. <\/p>\n
<\/p>\n
Hvorfor er det s\u00e5dan? Tilsyneladende burde det v\u00e6re omvendt. Det sker af den enkle grund, at vi har brug for meget hukommelse til page cache \u2013 flere titusinder, hundreder af gigabyte. <\/p>\n
<\/p>\n
Og hvis vi har allokeret det hele og cached vores data der, vil gevinsten ved at bruge cachen v\u00e6re v\u00e6sentligt st\u00f8rre end gevinsten ved s\u00e5dan en snedig tilgang til hukommelsen. Og p\u00e5 den m\u00e5de vil vi vinde uforholdsm\u00e6ssigt i forhold til, at vi mere effektivt vil tilg\u00e5 hukommelsen ved at bruge NUMA.<\/p>\n
<\/p>\n
Derfor er der i \u00f8jeblikket to tilgange, indtil den lysere fremtid kommer, og databasen selv kan finde ud af, hvilke CPU'er den arbejder med, og hvor den skal hente hvad. <\/p>\n
<\/p>\n
<\/p>\n
Derfor er den rigtige tilgang helt at deaktivere NUMA<\/strong>, for eksempel ved genstart. I de fleste tilf\u00e6lde er gevinsterne s\u00e5 store, at sp\u00f8rgsm\u00e5let om, hvad der er bedre, slet ikke opst\u00e5r. <\/p>\n<\/p>\n
Der er en anden mulighed. Vi bruger den oftere end den f\u00f8rste, fordi n\u00e5r en kunde henvender sig til os for support, er det en stor sag for dem at genstarte serveren. Der er forretning, der k\u00f8rer der. Og de oplever problemer p\u00e5 grund af NUMA. Derfor pr\u00f8ver vi at deaktivere det p\u00e5 mindre invasive m\u00e5der end genstart, men v\u00e6r her omhyggelig med at kontrollere, at det virkelig er blevet deaktiveret. For som erfaringen viser, fungerer det fint at deaktivere NUMA for PostgreSQL's overordnede proces, men det er ikke n\u00f8dvendigvis sikkert, at det vil virke. Vi skal kontrollere og sikre, at det virkelig er blevet deaktiveret. <\/p>\n
<\/p>\n
Der er et godt indl\u00e6g af Robert Haas. Han er en af udviklerne til PostgreSQL. En af de centrale udviklere bag alle de lavniveau komponenter. Hvis man f\u00f8lger linksene i dette indl\u00e6g, beskriver de flere farverige historier om, hvordan NUMA har gjort livet sv\u00e6rt for folk. Tag et kig, gennemg\u00e5 tjeklisten for systemadministratorer over, hvad der skal konfigureres p\u00e5 serveren, s\u00e5 vores database fungerer godt. Disse indstillinger skal noteres og kontrolleres, fordi ellers vil det ikke g\u00e5 s\u00e5 godt. <\/p>\n
<\/p>\n
Bem\u00e6rk, at dette g\u00e6lder for alle de indstillinger, jeg vil tale om. Men normalt samles databaser i master-slave mode for redundans. Glem ikke at foretage disse indstillinger p\u00e5 slave-serveren, for p\u00e5 et tidspunkt vil der opst\u00e5 en fejl, og du vil skifte til slave, som s\u00e5 bliver master. <\/p>\n
<\/p>\n
I tilf\u00e6lde af n\u00f8dssituation, n\u00e5r alt ser skidt ud, ringer telefonen konstant, og chefen kommer styrtende med en stor stok, vil du ikke have tid til at t\u00e6nke p\u00e5 at kontrollere. Og resultaterne kan v\u00e6re meget triste.<\/p>\n
<\/p>\n
<\/p>\n
N\u00e6ste punkt er huge pages. Huge pages er sv\u00e6re at teste isoleret, og der er egentlig ikke megen mening i det, selvom der findes benchmarks, der kan g\u00f8re det. De kan let findes p\u00e5 nettet. <\/p>\n
<\/p>\n
Hvad er meningen? Du har en server, der ikke er s\u00e6rlig dyr, og som har meget RAM, for eksempel mere end 30 GB. Du bruger ikke huge pages. Det betyder, at du un\u00e6gteligt har overhead ved hukommelsesbrugen. Og det overhead er langtfra det mest behagelige. <\/p>\n
<\/p>\n
<\/p>\n
Hvorfor er det s\u00e5dan? Hvad sker der? Operativsystemet tildeler hukommelse i sm\u00e5 bidder. Det er praktisk, det er s\u00e5dan, det historisk har v\u00e6ret. Og hvis man g\u00e5r i dybden, skal OS konvertere virtuelle adresser til fysiske. Og det er ikke den nemmeste proces, s\u00e5 OS cacher resultatet af denne operation i Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Da TLB er en cache, opst\u00e5r der alle de problemer, der er forbundet med caching. For det f\u00f8rste, hvis du har meget RAM, der er tildelt i sm\u00e5 bidder, s\u00e5 bliver bufferen meget stor. Og hvis cachen er stor, tager det l\u00e6ngere tid at s\u00f8ge i den. Overheadet er betydeligt, og det optager plads, dvs. noget un\u00f8dvendigt bruger RAM. <\/p>\n
<\/p>\n
Jo mere cachen vokser i en s\u00e5dan situation, jo st\u00f8rre er chancen for cache misses. Og effektiviteten af denne cache falder hurtigt med st\u00f8rre st\u00f8rrelse. Derfor har operativsystemer udviklet en simpel tilgang. I Linux har denne metode l\u00e6nge v\u00e6ret anvendt. I FreeBSD er det for nylig blevet introduceret. Men vi taler om Linux. Det er huge pages.<\/p>\n
<\/p>\n
Og her skal det bem\u00e6rkes, at id\u00e9en om huge pages oprindeligt blev fremf\u00f8rt af f\u00e6llesskaber, der inkluderede Oracle og IBM, dvs. producenter af databaser t\u00e6nkte grundigt over, at dette ville v\u00e6re nyttigt, ogs\u00e5 for databaser. <\/p>\n
<\/p>\n
<\/p>\n
Og hvordan f\u00e5r man det til at fungere med PostgreSQL? For det f\u00f8rste skal huge pages v\u00e6re aktiveret i Linux-kernen.<\/p>\n
<\/p>\n
For det andet skal de angives eksplicit med sysctl parameteren - hvor mange der skal v\u00e6re. Tallene her stammer fra en gammel server. Du kan beregne, hvor mange shared buffers du har, s\u00e5 huge pages kan blive indpasset. <\/p>\n
<\/p>\n
Og hvis hele serveren er dedikeret til PostgreSQL, s\u00e5 er et godt udgangspunkt at afs\u00e6tte enten 25 % af den samlede RAM til shared buffers eller 75 %, hvis du er sikker p\u00e5, at din database vil passe ind i de 75 %. Dette er dit f\u00f8rste udgangspunkt. Hvis du har 256 GB RAM, s\u00e5 vil 64 GB v\u00e6re til shared buffers. Beregn med en smule margen - hvad denne v\u00e6rdi skal s\u00e6ttes til.<\/p>\n
<\/p>\n
F\u00f8r version 9.2 (hvis jeg ikke tager fejl, fra version 8.2) kunne PostgreSQL integreres med huge pages ved hj\u00e6lp af et tredjepartsbibliotek. Og dette skal altid g\u00f8res. For det f\u00f8rste skal kernen kunne allokere huge pages korrekt. Og for det andet skal applikationen, der arbejder med dem, kunne udnytte dem. Det kan ikke g\u00f8res uden videre. Da PostgreSQL allokerede hukommelse i stil med system 5, kunne dette g\u00f8res med libhugetlbfs - det fulde navn p\u00e5 biblioteket.<\/p>\n
<\/p>\n
I version 9.3 forbedrede vi PostgreSQL's ydeevne ved h\u00e5ndtering af hukommelse og opgav system 5 metoden til hukommelsestildeling. Alle var meget glade, fordi ellers n\u00e5r man pr\u00f8ver at k\u00f8re to PostgreSQL-instans p\u00e5 \u00e9n maskine, s\u00e5 siger den, at der ikke er nok delt hukommelse. Og den siger, at man skal justere sysctl. Og der er s\u00e5dan en sysctl, at man skal genstarte osv. Generelt var alle glade. Men hukommelsestildelingen med mmap br\u00f8d brugen af huge pages. De fleste af vores kunder bruger store delte buffere. Og vi anbefalede kraftigt ikke at opgradere til 9.3, fordi overheadet begyndte at t\u00e6lle i gode procenter.<\/p>\n
<\/p>\n
Men community'en lagde m\u00e6rke til dette problem og i 9.4 arbejdede de virkelig godt med denne udfordring. I 9.4 blev der introduceret en parameter i postgresql.conf, hvor man kan aktivere try, on eller off.<\/p>\n
<\/p>\n
Try er den mest sikre parameter. Ved opstart af PostgreSQL, n\u00e5r den tildeler delt hukommelse, fors\u00f8ger den at f\u00e5 denne hukommelse fra huge pages. Hvis det ikke er muligt, falder den tilbage til almindelig tildeling. Og hvis du bruger FreeBSD eller Solaris, kan du s\u00e6tte try, det er altid sikkert. <\/p>\n
<\/p>\n
Hvis on, starter den simpelthen ikke, hvis den ikke kunne tildele fra huge pages. Her er der \u2013 hvem der \u00f8nsker hvad. Men hvis du har try, s\u00e5 skal du tjekke, at du virkelig har f\u00e5et tildelt det, du har brug for, fordi der er mange fejlmarginer. Nu fungerer denne funktion kun p\u00e5 Linux.<\/p>\n
<\/p>\n
Endnu et lille bem\u00e6rkning, f\u00f8r vi g\u00e5r videre. Transparent huge pages handler ikke om PostgreSQL endnu. Den kan ikke drage fordel af dem ordentligt. Og med Transparent huge pages for en arbejdsbyrde, der kr\u00e6ver en stor del delt hukommelse, kommer fordelene kun ved meget store m\u00e6ngder. Hvis du har terabyte hukommelse, kan det spille en rolle. Hvis vi taler om mere almindelige anvendelser, n\u00e5r du har 32, 64, 128, 256 GB hukommelse p\u00e5 maskinen, s\u00e5 er almindelige huge pages Ok, og vi deaktiverer bare Transparent. <\/p>\n
<\/p>\n
<\/p>\n
Og den sidste ting, der vedr\u00f8rer hukommelse, er ikke direkte relateret til throughput, men den kan virkelig forringe livskvaliteten. Hele b\u00e5ndbredden vil lide st\u00e6rkt af, at serveren konstant swappes. <\/p>\n
<\/p>\n
Og det vil v\u00e6re meget ubehageligt i en r\u00e6kke situationer. Den prim\u00e6re ubehagelighed er, at adf\u00e6rden i moderne kerner lidt adskiller sig fra de \u00e6ldre Linux-kerner. Og dette er noget, man helst vil undg\u00e5, fordi n\u00e5r vi taler om at arbejde med swap, ender det ikke med en rettidig ankomst af OOM-killeren. Og en OOM-killer, der ikke kommer til tiden og afslutter PostgreSQL, er ubehageligt. Dette f\u00e5r alle til at opdage det, dvs. op til den sidste bruger. <\/p>\n
<\/p>\n
<\/p>\n
Hvad sker der? I har en stor m\u00e6ngde RAM, alt fungerer godt. Men af en eller anden grund h\u00e6nger serveren i swap og bliver langsom p\u00e5 grund af det. Det virker som om, der er masser af hukommelse, men s\u00e5dan g\u00e5r det. <\/p>\n
<\/p>\n
<\/p>\n
Tidligere r\u00e5dgav vi at s\u00e6tte vm.swappiness til nul, dvs. deaktivere swap. Det s\u00e5 ud som om, at 32 GB RAM og de tilsvarende delte buffere var en enorm m\u00e6ngde. Hovedform\u00e5let med swap er, at der er et sted at smide en kerne, hvis vi falder fra. Men det blev ikke l\u00e6ngere udf\u00f8rt. Og hvad skal man s\u00e5 g\u00f8re med denne kerne? Det er allerede et problem, hvor det ikke er helt klart, hvorfor swap er n\u00f8dvendigt, is\u00e6r i s\u00e5 stort omfang. <\/p>\n
<\/p>\n
Men i nyere, dvs. i de tredje versioner af kernen, er adf\u00e6rden \u00e6ndret. Og hvis man s\u00e6tter swap til nul, dvs. slukker det, vil OOM-killeren p\u00e5 et tidspunkt komme, selv med en vis m\u00e6ngde RAM tilbage, for at dr\u00e6be de mest intensive forbrugere. Fordi den vil vurdere, at med s\u00e5dan en arbejdsbelastning har vi kun lidt tilbage, og vi vil g\u00e5 ned, dvs. ikke dr\u00e6be et systemprocess, men dr\u00e6be noget mindre vigtigt. Dette mindre vigtige vil v\u00e6re en intens forbruger af delt hukommelse, nemlig postmaster. Og derefter vil det v\u00e6re godt, hvis databasen ikke skal genskabes. <\/p>\n
<\/p>\n
Derfor er standards\u00e6tningen nu, s\u00e5 vidt jeg husker, for de fleste distributioner omkring 6, dvs. hvorn\u00e5r man skal begynde at bruge swap afh\u00e6ngigt af hvor meget hukommelse der er tilbage. Vi r\u00e5dgiver nu at s\u00e6tte vm.swappiness = 1, fordi det n\u00e6sten slukker for det, men ikke giver de samme effekter som en uventet ankommet OOM-killer, der afslutter det hele.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Hvad sker der nu? N\u00e5r vi taler om databases ydeevne og gradvist kommer til diskene, begynder alle at gribe hovedet. For det er en sandhed, som vi har kendt siden barndommen: diske er langsomme, og hukommelse er hurtig. Og alle ved, at der vil v\u00e6re problemer med diskydelsen i databasen.<\/p>\n
<\/p>\n
Det prim\u00e6re problem med PostgreSQL's ydeevne, relateret til checkpoint spikes, opst\u00e5r ikke fordi disken er langsom. Det skyldes snarere, at b\u00e5ndbredden mellem hukommelse og disk ikke er afbalanceret. Og de kan v\u00e6re ubalancerede p\u00e5 forskellige m\u00e5der. PostgreSQL er ikke konfigureret korrekt, operativsystemet er ikke konfigureret, hardwaren er ikke korrekt, og hardwaren er forkert. Dette problem opst\u00e5r kun, hvis alt fungerer som det skal, dvs. enten er der ingen belastning, eller indstillingerne og hardwaren er godt tilpasset. <\/p>\n
<\/p>\n
<\/p>\n
Hvad er det, og hvordan ser det ud? Normalt har folk, der arbejder med PostgreSQL, v\u00e6ret igennem dette flere gange. Jeg vil forklare. Som jeg sagde, laver PostgreSQL periodisk checkpoints for at overf\u00f8re de \u201cbeskidte\u201d sider fra den delte hukommelse til disken. Hvis vi har en stor m\u00e6ngde delt hukommelse, s\u00e5 begynder checkpoint at p\u00e5virke disken intensivt, fordi det overf\u00f8rer disse sider via fsync. Det kommer ind i kernel buffer og skrives til diskene med fsync. Og hvis omfanget af dette er stort, kan vi observere en ubehagelig effekt, nemlig en meget h\u00f8j diskudnyttelse.<\/p>\n
<\/p>\n
Her har jeg to billeder. Jeg vil lige forklare, hvad det er. Det er to tidskorrelerede grafer. Den f\u00f8rste graf viser diskudnyttelsen. Her n\u00e5r den n\u00e6sten op p\u00e5 90 % p\u00e5 dette tidspunkt. Hvis din databaseserver har fysiske diske med en RAID-controller, og udnyttelsen n\u00e6rmer sig 90 %, er det d\u00e5rlige nyheder. Det betyder, at hvis det forts\u00e6tter, vil det n\u00e5 100, og ind- og uddata vil stoppe. <\/p>\n
<\/p>\n
Hvis du har et diskarray, er historien lidt anderledes. Det afh\u00e6nger af, hvordan det er konfigureret, hvad slags array det er osv. <\/p>\n
<\/p>\n
Samtidig er her konfigureret en grafik fra den interne PostgreSQL-visning, der viser, hvordan checkpoint-processen forl\u00f8ber. Den gr\u00f8nne farve viser, hvor mange buffere, disse 'snuskede' sider, der i \u00f8jeblikket kom til dette checkpoint for synkronisering. Og det vigtigste, man her skal vide. Vi kan se, at der er kommet mange sider ind, og p\u00e5 et tidspunkt ramte vi gr\u00e6nsen, dvs. vi har skrevet og skrevet, og det er tydeligt, at diskdrevssystemet er meget optaget. Og vores checkpoint har en stor p\u00e5virkning p\u00e5 disken. Ideelt set burde situationen se mere s\u00e5dan ud, dvs. vi burde have haft mindre skrivning her. Og vi kan justere indstillingerne for at sikre, at det forts\u00e6tter s\u00e5dan. Det vil sige, at udnyttelsen er lille, men der er stadig noget, vi skriver. <\/p>\n
<\/p>\n
Hvad skal der til for at overvinde dette problem? Hvis IO er stoppet under databasen, betyder det, at alle brugere, som fors\u00f8ger at udf\u00f8re deres foresp\u00f8rgsler, vil skulle vente. <\/p>\n
<\/p>\n
<\/p>\n
Set fra et Linux-perspektiv, hvis du har et godt hardware, har konfigureret det korrekt, og har sat PostgreSQL op, s\u00e5 den sj\u00e6ldnere udf\u00f8rer disse checkpoints og spredte dem over tid, s\u00e5 falder du tilbage til de standardparametre, der findes i Debian. For de fleste Linux-distributioner ser situationen s\u00e5dan her ud: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Hvad betyder det? Siden kerne 2.6 er der en demon, der h\u00e5ndterer flushing. Pdglush, afh\u00e6ngigt af hvilken der anvendes, der besk\u00e6ftiger sig med baggrunds-kasseren af snuskede sider fra kernel-bufferen og kasserer, n\u00e5r det er n\u00f8dvendigt at kassere snuskede sider, n\u00e5r baggrunds-kasseringen ikke l\u00e6ngere hj\u00e6lper. <\/p>\n
<\/p>\n
Hvorn\u00e5r opst\u00e5r baggrunden? N\u00e5r 10 % af al den tilg\u00e6ngelige RAM, der er p\u00e5 serveren, er optaget af snuskede sider i kernel-bufferen, kaldes der en specifik funktion til at kassere i baggrunden. Hvorfor er den baggrunds? Den tager som parameter, hvor mange sider der skal kasseres. Og eksempelvis kasserer den N sider. Og i en periode g\u00e5r denne enhed i dvale. Og s\u00e5 kommer den tilbage og kasserer et bestemt antal sider igen. <\/p>\n
<\/p>\n
Det er en ganske enkel sag. Her er opgaven som med en swimmingpool, hvor den ene r\u00f8v fyldes, mens den anden t\u00f8mmes. Vores checkpoint kom, og hvis den sendte f\u00e5 snuskede sider til kassering, s\u00e5 vil pgflush forsigtigt fordele det hele fra kernel-bufferen. <\/p>\n
<\/p>\n
Hvis disse beskidte sider forts\u00e6tter med at opbygge sig, n\u00e5r de n\u00e5r op p\u00e5 20 %, vil operativsystemet prioritere at skrive dem til disk, fordi str\u00f8mmen kan g\u00e5, og vi vil ende i problemer. Vi vil miste disse data, for eksempel. <\/p>\n
<\/p>\n
Hvad er trikset? Trikset er, at disse parametre i den moderne verden, 20 og 10 % af den samlede RAM i maskinen, langt fra er tilstr\u00e6kkelige i forhold til kapaciteten af ethvert disk system, du har.<\/strong> <\/p>\n<\/p>\n
Forestil dig, at du har 128 GB RAM. 12,8 GB kommer til dit disksystem. Uanset hvilken cache eller array du har, kan de ikke h\u00e5ndtere s\u00e5 meget. <\/p>\n
<\/p>\n
<\/p>\n
Derfor anbefaler vi, at disse tal straks tilpasses dit RAID-kontrols muligheder.<\/strong> Her er der straks givet en anbefaling til en controller, der har 512 MB cache. <\/p>\n<\/p>\n
Det regnes meget enkelt. Man kan s\u00e6tte vm.dirty_background i bytes. Og disse indstillinger oph\u00e6ver de to foreg\u00e5ende. Hvis der er en ratio som standard, eller hvis de, der er i bytes, er aktiveret, vil dem, der er i bytes, virke. Men da jeg er DBA-konsulent og arbejder med forskellige kunder, pr\u00f8ver jeg at v\u00e6re forsigtig, og derfor, hvis det er i bytes, s\u00e5 er det i bytes. Ingen har givet nogen garanti for, at en god admin ikke tilf\u00f8rer mere RAM til serveren, genstarter den, mens tallet forbliver det samme. Bare beregn disse tal for at sikre, at alt passer. <\/p>\n
<\/p>\n
Hvad sker der, hvis du ikke passer ind? Jeg har skrevet, at al flushing stopper effektivt, men i virkeligheden er det en figurativ talem\u00e5de. Operativsystemet har et stort problem - det har mange beskidte sider, s\u00e5 den effektive I\/O stopper, der genereres af dine klienter, dvs. en applikation er til stede for at sende en SQL-foresp\u00f8rgsel til databasen og venter. Enhver I\/O til den - i laveste prioritet, fordi databasen er optaget af checkpoint. Og hvorn\u00e5r det vil v\u00e6re f\u00e6rdigt, er helt uforudsigeligt. Og n\u00e5r du har n\u00e5et ikke-baggrunds-flushing, betyder det, at al din I\/O er optaget af det. Og indtil det er f\u00e6rdigt, kan du ikke g\u00f8re noget. <\/p>\n
<\/p>\n
Der er ogs\u00e5 to vigtige punkter, der g\u00e5r ud over denne pr\u00e6sentation. Disse indstillinger skal matche indstillingerne i postgresql.conf, dvs. checkpoint-indstillinger. Og dit disksystem skal v\u00e6re korrekt konfigureret. Hvis du har cache p\u00e5 RAID, skal der v\u00e6re et batteri p\u00e5 det.<\/strong> Folk k\u00f8ber RAID med god cache uden batteri. Hvis du har SSD i RAID, skal de v\u00e6re serverklasse, der skal v\u00e6re kondensatorer p\u00e5.<\/strong> Her er en detaljeret tjekliste. P\u00e5 dette link findes min pr\u00e6sentation om, hvordan man konfigurerer diskperformance i PostgreSQL. Der er alle disse tjeklister. <\/p>\n<\/p>\n
<\/p>\n
Hvad andet kan virkelig komplicere livet? Det er to parametre. De er relativt nye. De kan som standard v\u00e6re aktiveret i forskellige applikationer. Og de kan g\u00f8re livet mindst lige s\u00e5 besv\u00e6rligt, hvis de er forkert aktiveret. <\/p>\n
<\/p>\n
<\/p>\n
Der er to relativt nye funktioner. De er allerede dukket op i tredje kerner. Det er sched_migration_cost i nanosekunder og sched_autogroup_enabled, som som standard er en. <\/p>\n
<\/p>\n
Og hvordan \u00f8del\u00e6gger de livet? Hvad er sched_migration_cost? Linux scheduler kan migrere en proces fra en CPU til en anden. Og for PostgreSQL, som udf\u00f8rer foresp\u00f8rgsler, er migration til en anden CPU helt uforst\u00e5eligt. Set fra operativsystemets perspektiv, n\u00e5r du skifter vinduer mellem openoffice og terminalen, kan det v\u00e6re godt, men for databasen er det meget d\u00e5rligt.<\/strong> Derfor er en fornuftig politik at s\u00e6tte migration_cost til en stor v\u00e6rdi, mindst et par tusind nanosekunder.<\/strong> <\/p>\n<\/p>\n
Hvad vil det betyde for scheduler? Det vil tro, at i denne periode er denne proces stadig 'hot'. Det vil sige, hvis du har en lang transaktion, som besk\u00e6ftiger sig med noget, vil scheduler forst\u00e5 dette. Han vil tro, at s\u00e5 l\u00e6nge timeout ikke er passeret, er der ikke behov for at migrere denne proces. Hvis processen udf\u00f8rer noget, vil den ikke blive migreret, den vil roligt forts\u00e6tte p\u00e5 den CPU, der er tildelt. Og resultatet bliver fremragende. <\/p>\n
<\/p>\n
Det andet punkt er autogroup. Der er en god id\u00e9 til specifikke arbejdsbelastninger, der ikke har noget at g\u00f8re med moderne databaser \u2013 at gruppere processer efter den virtuelle terminal, de er startet fra. Det er praktisk til visse opgaver. I praksis er PostgreSQL et multiprocessing-system med prefork, der starter fra \u00e9t terminalvindue. Du har lock writer, checkpoint, og alle dine klientforesp\u00f8rgsler vil blive grupperet p\u00e5 \u00e9n scheduler, p\u00e5 \u00e9n CPU. Og de vil alle vente sammen p\u00e5, at den bliver ledig, hvilket g\u00f8r, at de forstyrrer hinanden og optager ressourcen l\u00e6ngere. Denne situation er slet ikke n\u00f8dvendig ved s\u00e5dan en belastning, og derfor skal det slukkes.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Min kollega Aleksej Lesovskij har lavet tests med et enkelt pgbench, hvor han for\u00f8gede migration_cost med en orden og slukkede autogroup. Forskellen p\u00e5 d\u00e5rlig hardware var n\u00e6sten 10 %<\/strong>. Der er en diskussion i PostgreSQL-listen, hvor folk pr\u00e6senterer resultater om, hvordan s\u00e5danne \u00e6ndringer p\u00e5 foresp\u00f8rgsels hastigheden p\u00e5virkede 50 %<\/strong>. Der er mange s\u00e5danne historier.<\/p>\n<\/p>\n
<\/p>\n
Og til sidst om str\u00f8mbesparende politik. Det er godt, at Linux nu kan bruges p\u00e5 en b\u00e6rbar computer. Og den skulle angiveligt have et godt batteriforbrug. Men pludselig viser det sig, at det samme ogs\u00e5 kan v\u00e6re tilf\u00e6ldet p\u00e5 servere. <\/p>\n
<\/p>\n
Desuden, hvis du lejer servere fra en eller anden host, s\u00e5 s\u00f8rger de \"venlige\" hoster<\/a> ikke for, at du har en bedre ydeevne. Deres m\u00e5l er at maksimere udnyttelsen af deres hardware. Derfor kan de som standard have aktiveret b\u00e6rbar energisparetilstand p\u00e5 operativsystemet.<\/p>\n<\/p>\n
Hvis du bruger dette p\u00e5 en server med en database under intensiv belastning, er dit valg \u2013 acpi_cpufreq + performance. Selv med ondemand vil der allerede v\u00e6re problemer.<\/strong> <\/p>\n<\/p>\n
Intel_pstate er allerede en lidt anden driver. Og nu gives der pr\u00e6ference til denne, da den er nyere og fungerer bedre.<\/p>\n
<\/p>\n
Derfor b\u00f8r governor v\u00e6re performance. Ondemand, powersave og alt det andet \u2013 det er ikke for dig. <\/p>\n
<\/p>\n
Resultaterne fra explain analyze i PostgreSQL kan variere med flere ordrer, hvis du aktiverer powersave, fordi CPU'en under databasen vil blive planlagt p\u00e5 en helt uforudsigelig m\u00e5de.<\/p>\n
<\/p>\n
Disse indstillinger kan v\u00e6re aktiveret som standard. Tjek om de er aktiveret som standard. Det kan v\u00e6re en virkelig stor udfordring. <\/p>\n
<\/p>\n
<\/p>\n
Og til sidst vil jeg gerne sige tak til gutterne fra vores DBA-team PosgreSQL-Consulting, s\u00e6rligt Maks Boguk og Alexey Lesovsky, som hver dag arbejder h\u00e5rdt p\u00e5 dette omr\u00e5de. Vi fors\u00f8ger at g\u00f8re det s\u00e5 godt som muligt for vores kunder, s\u00e5 deres systemer fungerer optimalt. Det er lidt ligesom med instrukser for luftfartssikkerhed. Her st\u00e5r alt skrevet med blod. Hver eneste skrue er blevet opdaget under forskellige problemer. Jeg deler dem gladeligt med jer.<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l:<\/p>\n
<\/p>\n
Tak! Hvis en virksomhed for eksempel \u00f8nsker at spare penge og placere databasen og logs for applikationen p\u00e5 \u00e9n server, eller hvis virksomheden f\u00f8lger den moderne tendens med mikrotjenestearkitekturer, hvor PostgreSQL k\u00f8rer i en container. Hvad er tricket? Sysctl p\u00e5virker globalt hele kernen. Jeg har ikke h\u00f8rt, at sysctl bliver virtualiseret, s\u00e5 de fungerer separat i containeren. Der er kun cgroup, og der er kun kontrol p\u00e5 dele. Hvordan kan man leve med det? Eller hvis du \u00f8nsker ydeevne, s\u00e5 k\u00f8r PostgreSQL p\u00e5 en dedikeret server og optim\u00e9r den?<\/em><\/p>\n<\/p>\n
Vi har svaret p\u00e5 dit sp\u00f8rgsm\u00e5l p\u00e5 cirka tre m\u00e5der. Hvis det ikke handler om en dedikeret server, der kan optimeres osv., s\u00e5 slap af, det vil fungere fint uden de indstillinger. Hvis du oplever en belastning, der kr\u00e6ver disse indstillinger, s\u00e5 vil du komme til den dedikerede server, f\u00f8r du beh\u00f8ver disse indstillinger.<\/p>\n
<\/p>\n
Hvad er problemet? Hvis det er en virtuel maskine, vil du sandsynligvis have mange problemer, f.eks. med, at latency p\u00e5 de fleste virtuelle maskiner er ret inkonsistent. Selv hvis diskens b\u00e5ndbredde er god, kan en enkelt mislykket I\/O-transaktion, der ikke p\u00e5virker den gennemsnitlige b\u00e5ndbredde n\u00e6vnev\u00e6rdigt, ske under et checkpoint eller under skrivning til WAL, hvilket kan medf\u00f8re store problemer for databasen. Og du vil l\u00e6gge m\u00e6rke til det, f\u00f8r du st\u00f8der ind i disse problemer. <\/p>\n
<\/p>\n
Hvis du har NGINX p\u00e5 den samme server, vil du ogs\u00e5 have det samme problem. Den vil k\u00e6mpe om delt hukommelse. Og du vil ikke n\u00e5 de problemer, der er beskrevet her.<\/p>\n
<\/p>\n
Men p\u00e5 den anden side vil nogle af disse parametre stadig v\u00e6re relevante for dig. For eksempel at s\u00e6tte dirty_ratio med sysctl, s\u00e5 det ikke bliver s\u00e5 ekstremt \u2013 det vil hj\u00e6lpe uanset hvad. P\u00e5 en eller anden m\u00e5de vil du have interaktion med disken. Og det vil ske efter en forkert skema. Det er generelt standard de parametre, jeg viste. Og i hvert fald er det bedre at \u00e6ndre dem. <\/p>\n
<\/p>\n
Der kan v\u00e6re problemer med NUMA. VmWare fungerer for eksempel godt med NUMA med helt modsatte indstillinger. Og her skal man v\u00e6lge \u2013 er det en fysisk server eller ikke. <\/p>\n
<\/p>\n
Jeg har et sp\u00f8rgsm\u00e5l relateret til Amazon AWS. De har forudkonfigurerede billeder. Et af dem hedder Amazon RDS. Er der nogle tilpassede indstillinger for deres operativsystem?<\/em><\/p>\n<\/p>\n
Der findes indstillinger, men det er andre indstillinger. Her konfigurerer vi operativsystemet fra perspektivet af, hvordan databasen vil bruge dette. Og der er parametre, der bestemmer, hvor vi skal g\u00e5 nu, s\u00e5dan en shaping. Alts\u00e5, vi har brug for s\u00e5 mange ressourcer, og vi vil forbruge dem nu. Efter dette tilslutter Amazon RDS disse ressourcer, og derefter falder ydeevnen. Der er s\u00e6rskilte historier om, hvordan folk begynder at eksperimentere med dette. Nogle gange med ret stor succes. Men det har ikke noget at g\u00f8re med OS-indstillingerne. Det er som en slags hacking af skyen. Det er en anden historie.<\/p>\n
<\/p>\n
Hvorfor giver Transparent huge pages ikke effekt sammenlignet med Huge TLB?<\/em><\/p>\n<\/p>\n
De giver ikke. Dette kan forklares p\u00e5 mange m\u00e5der. Men i virkeligheden giver de slet ikke effekten. Hvad er historien om PostgreSQL? Det allokerer en stor del delt hukommelse ved opstart. Om de er transparente eller ikke \u2013 det er fuldst\u00e6ndig irrelevant. Det faktum, at de allokeres ved opstart, forklarer alt. Og hvis der er meget hukommelse og det er n\u00f8dvendigt at omkonfigurere shared_memory segmentet, s\u00e5 vil Transparent huge pages v\u00e6re relevant. Hos PostgreSQL er det simpelthen afsat en enorm del ved opstart, og der sker ikke noget s\u00e6rlig derefter. Man kan selvf\u00f8lgelig bruge dem, men der er en risiko for at f\u00e5 beskadiget shared_memory, n\u00e5r den skal genallokeres. PostgreSQL ved jo ikke noget om det.<\/p>\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Linux](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n