D\u00e4rf\u00f6r \u00e4r r\u00e4tt tillv\u00e4gag\u00e5ngss\u00e4tt att helt st\u00e4nga av NUMA<\/strong>, till exempel vid omstart. I de flesta fall \u00e4r vinsterna s\u00e5 stora att fr\u00e5gan hur man ska g\u00f6ra det b\u00e4ttre \u00f6verhuvudtaget inte uppst\u00e5r. <\/p>\n<\/p>\n
Det finns ett annat alternativ. Vi anv\u00e4nder det oftare \u00e4n det f\u00f6rsta, eftersom n\u00e4r en kund kommer till oss f\u00f6r support, s\u00e5 \u00e4r en serveromstart en stor sak f\u00f6r dem. De har sin verksamhet ig\u00e5ng. Och de upplever problem med NUMA. D\u00e4rf\u00f6r f\u00f6rs\u00f6ker vi st\u00e4nga av det p\u00e5 mindre p\u00e5tr\u00e4ngande s\u00e4tt \u00e4n genom omstart, men h\u00e4r m\u00e5ste ni vara f\u00f6rsiktiga och kontrollera att det verkligen har st\u00e4ngts av. F\u00f6r som erfarenheten visar, det som vi st\u00e4nger av i f\u00f6r\u00e4lderprocessen PostgreSQL NUMA fungerar bra, men det \u00e4r inte n\u00f6dv\u00e4ndigtvis s\u00e5 att det alltid funkar. Det \u00e4r viktigt att kontrollera och se till att det verkligen har st\u00e4ngts av. <\/p>\n
<\/p>\n
Det finns ett bra inl\u00e4gg av Robert Haas. Han \u00e4r en av committerna f\u00f6r PostgreSQL. En av huvudutvecklarna av all l\u00e5g niv\u00e5 teknik. Och om man f\u00f6ljer l\u00e4nkarna i detta inl\u00e4gg, s\u00e5 beskrivs det n\u00e5gra f\u00e4rgstarka historier om hur NUMA har komplicerat livet f\u00f6r folk. Ta en titt, g\u00e5 igenom checklisten f\u00f6r systemadministrat\u00f6rer, vad som beh\u00f6ver konfigureras p\u00e5 servern s\u00e5 att v\u00e5r databas fungerar bra. Dessa inst\u00e4llningar m\u00e5ste noteras och kontrolleras, f\u00f6r annars blir det inte s\u00e5 bra. <\/p>\n
<\/p>\n
Jag p\u00e5pekar att detta g\u00e4ller alla inst\u00e4llningar som jag kommer att prata om. Men vanligtvis samlar databaser ihop i master-slave f\u00f6r redundans. Gl\u00f6m inte att g\u00f6ra dessa inst\u00e4llningar p\u00e5 slaven, f\u00f6r vid n\u00e5got tillf\u00e4lle kommer ni att f\u00e5 en krasch, och ni kommer att v\u00e4xla till slaven, och den kommer att bli master. <\/p>\n
<\/p>\n
I en n\u00f6dsituation, n\u00e4r allt \u00e4r mycket illa, ringer telefonen st\u00e4ndigt och chefen springer in med en stor k\u00e4pp, d\u00e5 kommer ni inte att ha tid att t\u00e4nka p\u00e5 att kontrollera. Och resultaten kan bli sorgliga.<\/p>\n
<\/p>\n
<\/p>\n
Den n\u00e4sta punkten \u00e4r huge pages. Huge pages \u00e4r sv\u00e5ra att testa separat, och det finns inte mycket mening med det, \u00e4ven om det finns benchmarker som kan g\u00f6ra det. De \u00e4r l\u00e4tta att googla. <\/p>\n
<\/p>\n
Vad \u00e4r meningen? Ni har en inte s\u00e4rskilt dyr server med mycket RAM, exempelvis mer \u00e4n 30 GB. Ni anv\u00e4nder inte huge pages. Detta betyder att ni definitivt har overhead n\u00e4r det g\u00e4ller minnesanv\u00e4ndning. Och den overheaden \u00e4r l\u00e5ngt ifr\u00e5n trevlig. <\/p>\n
<\/p>\n
<\/p>\n
Varf\u00f6r \u00e4r det s\u00e5? Och vad h\u00e4nder? Operativsystemet delar upp minnet i sm\u00e5 bitar. Det \u00e4r praktiskt s\u00e5, och det har alltid varit s\u00e5. G\u00e5r man in p\u00e5 detaljer, s\u00e5 m\u00e5ste operativsystemet \u00f6vers\u00e4tta virtuella adresser till fysiska. Och det \u00e4r en ganska komplicerad process, d\u00e4rf\u00f6r lagrar operativsystemet resultatet av denna operation i Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Och eftersom TLB \u00e4r en cache, uppst\u00e5r alla de problem som \u00e4r f\u00f6rknippade med cachen i denna situation. F\u00f6r det f\u00f6rsta, om du har v\u00e4ldigt mycket RAM och det \u00e4r helt uppdelat i sm\u00e5 bitar, s\u00e5 blir denna buffer mycket stor. Och om cachen \u00e4r stor, tar det l\u00e4ngre tid att s\u00f6ka i den. Det finns en stor overhead som i sig upptar utrymme, vilket inneb\u00e4r att RAM f\u00f6rbrukar n\u00e5got ol\u00e4mpligt. Det \u00e4r punkt ett. <\/p>\n
<\/p>\n
F\u00f6r det andra \u2013 ju mer cachen v\u00e4xer i denna situation, desto st\u00f6rre \u00e4r risken att du f\u00e5r cache misses. Effektiviteten hos denna cache sjunker kraftigt med \u00f6kad storlek. D\u00e4rf\u00f6r har man i operativsystemen utvecklat en enkel l\u00f6sning. I Linux har det anv\u00e4nts l\u00e4nge. I FreeBSD har det nyligen inf\u00f6rts. Men vi pratar om Linux. Det handlar om huge pages.<\/p>\n
<\/p>\n
Det b\u00f6r noteras att huge pages, som id\u00e9, ursprungligen f\u00f6respr\u00e5kades av samh\u00e4llen som inkluderade Oracle och IBM, det vill s\u00e4ga, databasproducenter t\u00e4nkte verkligen att detta skulle vara anv\u00e4ndbart, \u00e4ven f\u00f6r databaser. <\/p>\n
<\/p>\n
<\/p>\n
Och hur kan man integrera detta med PostgreSQL? F\u00f6r det f\u00f6rsta m\u00e5ste huge pages vara aktiverade i Linux-k\u00e4rnan.<\/p>\n
<\/p>\n
F\u00f6r det andra m\u00e5ste de anges tydligt som en sysctl-parameter \u2013 hur m\u00e5nga av dem. Dessa siffror kommer fr\u00e5n en gammal server. Du kan ber\u00e4kna hur m\u00e5nga shared buffers du ungef\u00e4r har, s\u00e5 att huge pages f\u00e5r plats d\u00e4r. <\/p>\n
<\/p>\n
Och om hela servern \u00e4r till\u00e4gnad PostgreSQL, d\u00e5 \u00e4r en bra utg\u00e5ngspunkt att antingen ge 25 % av RAM till shared buffers, eller 75 %, om du \u00e4r s\u00e4ker p\u00e5 att din databas f\u00e5r plats i dessa 75 %. Det f\u00f6rsta utg\u00e5ngsv\u00e4rdet. Och r\u00e4kna, om du har 256 GB RAM, s\u00e5 f\u00e5r du allts\u00e5 64 GB som shared buffers. R\u00e4kna ungef\u00e4r med ett visst \u00f6verskott \u2013 vilket v\u00e4rde detta ska st\u00e4llas in p\u00e5.<\/p>\n
<\/p>\n
F\u00f6re version 9.2 (om jag minns r\u00e4tt, fr\u00e5n version 8.2) var det m\u00f6jligt att anv\u00e4nda ett tredjepartsbibliotek f\u00f6r att ansluta PostgreSQL med huge pages. Och det \u00e4r alltid n\u00f6dv\u00e4ndigt att g\u00f6ra. F\u00f6r det f\u00f6rsta beh\u00f6ver du att k\u00e4rnan kan allokera huge pages p\u00e5 r\u00e4tt s\u00e4tt. F\u00f6r det andra m\u00e5ste applikationen som arbetar med dem kunna anv\u00e4nda dem. Den kan inte bara anv\u00e4nda dem utan vidare. Eftersom PostgreSQL allokerade minne med system 5-stilen, kunde detta g\u00f6ras med hj\u00e4lp av libhugetlbfs \u2013 det fullst\u00e4ndiga namnet p\u00e5 biblioteket.<\/p>\n
<\/p>\n
I 9.3 f\u00f6rb\u00e4ttrades PostgreSQL:s prestanda n\u00e4r det g\u00e4llde minneshantering och de \u00f6vergav system 5-metoden f\u00f6r minnesallokering. Alla blev mycket glada, f\u00f6r annars f\u00f6rs\u00f6ker du starta tv\u00e5 PostgreSQL-instanser p\u00e5 en maskin, och den s\u00e4ger att den har brist p\u00e5 delat minne. Och den s\u00e4ger att du m\u00e5ste justera sysctl. Och d\u00e4r \u00e4r sysctl s\u00e5 att du ocks\u00e5 m\u00e5ste starta om och s\u00e5 vidare. Sammanfattningsvis blev alla glada. Men minnesallokeringen med mmap br\u00f6t anv\u00e4ndningen av huge pages. De flesta av v\u00e5ra kunder anv\u00e4nder stora delade buffrar. Och vi rekommenderade starkt att inte uppgradera till 9.3, eftersom overheadet b\u00f6rjade r\u00e4kna i goda procent.<\/p>\n
<\/p>\n
Men gemenskapen uppm\u00e4rksammade detta problem, och i 9.4 f\u00f6rb\u00e4ttrades detta avsev\u00e4rt. I 9.4 kom en parameter i postgresql.conf, d\u00e4r man kan aktivera try, on eller off.<\/p>\n
<\/p>\n
Try \u00e4r den s\u00e4kraste parametern. N\u00e4r PostgreSQL startar och allokerar delat minne, f\u00f6rs\u00f6ker den ta minnet fr\u00e5n huge pages. Om det inte lyckas, faller den tillbaka p\u00e5 vanlig allokering. Om du har FreeBSD eller Solaris kan du s\u00e4tta try, det \u00e4r alltid s\u00e4kert. <\/p>\n
<\/p>\n
Om on \u00e4r aktivt startar den helt enkelt inte om den inte kan allokera fr\u00e5n huge pages. H\u00e4r handlar det verkligen om vad som passar b\u00e4st f\u00f6r er. Men om du har try, kontrollera att det verkligen har allokerats det som beh\u00f6vs, f\u00f6r det finns mycket utrymme f\u00f6r fel. F\u00f6r tillf\u00e4llet fungerar denna funktionalitet endast p\u00e5 Linux.<\/p>\n
<\/p>\n
Ett litet ytterligare p\u00e5pekande innan vi g\u00e5r vidare. Transparent huge pages handlar inte om PostgreSQL just nu. Den kan inte dra nytta av dem p\u00e5 ett bra s\u00e4tt. N\u00e4r det kommer till transparent huge pages f\u00f6r s\u00e5dana arbetsbelastningar d\u00e4r en stor del av det delade minnet kr\u00e4vs, s\u00e5 b\u00f6rjar f\u00f6rdelarna upptr\u00e4da f\u00f6rst vid mycket stora m\u00e4ngder. Om ni har terabyte av minne kan det spela roll. Om vi pratar om mer vardagliga till\u00e4mpningar, d\u00e4r ni har 32, 64, 128 eller 256 GB minne p\u00e5 maskinen, s\u00e5 \u00e4r vanliga huge pages okej, medan transparent bara st\u00e4ngs av. <\/p>\n
<\/p>\n
<\/p>\n
Och den sista punkten kring minne, som inte \u00e4r direkt kopplad till genomstr\u00f6mningen, kan verkligen f\u00f6rst\u00f6ra livet. Hela bandbredden lider kraftigt av att servern st\u00e4ndigt v\u00e4xlar. <\/p>\n
<\/p>\n
Och detta kommer att vara v\u00e4ldigt obehagligt i m\u00e5nga situationer. Den st\u00f6rsta besv\u00e4ret ligger i att beteendet hos moderna k\u00e4rnor avviker lite fr\u00e5n \u00e4ldre Linux-k\u00e4rnor. Och detta \u00e4r n\u00e5got man helst vill undvika, f\u00f6r n\u00e4r vi pratar om att arbeta med swap s\u00e5 slutar det inte med en snabb Ankomst av OOM-killer. Och OOM-killer som inte kom i tid och st\u00e4ngde ner PostgreSQL \u00e4r obehagligt. Detta kommer alla att m\u00e4rka, det vill s\u00e4ga \u00e4nda till den sista anv\u00e4ndaren. <\/p>\n
<\/p>\n
<\/p>\n
Vad h\u00e4nder? Ni har en stor m\u00e4ngd RAM, allt fungerar bra. Men av n\u00e5gon anledning h\u00e4nger servern i swap och f\u00f6rdr\u00f6jer p\u00e5 grund av detta. Det kan tyckas som om ni har mycket minne, men \u00e4nd\u00e5 h\u00e4nder det. <\/p>\n
<\/p>\n
<\/p>\n
Tidigare rekommenderade vi att s\u00e4tta vm.swappiness till noll, det vill s\u00e4ga st\u00e4nga av swap. Det verkade tidigare som om 32 GB RAM och motsvarande delade buffrar var en enorm m\u00e4ngd. Huvudsyftet med swap \u00e4r att ha en plats att l\u00e4gga en k\u00e4rna p\u00e5, om vi skulle falla. Och det fyller inte riktigt sin funktion l\u00e4ngre. Och vad ska man g\u00f6ra med den k\u00e4rnan sedan? Det \u00e4r en s\u00e5dan uppgift d\u00e4r det inte \u00e4r s\u00e5 tydligt varf\u00f6r swap beh\u00f6vs, s\u00e4rskilt i s\u00e5 stora m\u00e4ngder. <\/p>\n
<\/p>\n
Men i de mer moderna, dvs. i tredje versionerna av k\u00e4rnan, har beteendet f\u00f6r\u00e4ndrats. Och om du s\u00e4tter swap till noll, dvs. st\u00e4nger av det, s\u00e5 kommer OOM-killer att dyka upp f\u00f6rr eller senare, \u00e4ven med en viss m\u00e4ngd ledigt arbetsminne, f\u00f6r att d\u00f6da de mest resurskr\u00e4vande processerna. Det f\u00f6r att den kommer att anta att vi har lite kvar och att vi kan \u00f6verbelasta, dvs. att den inte kommer att d\u00f6da systemprocessen, utan n\u00e5got mindre viktigt. Denna mindre viktiga process kan vara en intensiv konsument av delat minne, n\u00e4mligen postmaster. Och efter det \u00e4r det bra om databasen inte beh\u00f6ver \u00e5terst\u00e4llas. <\/p>\n
<\/p>\n
D\u00e4rf\u00f6r rekommenderar jag att de flesta distributioner nu som standard \u00e4r n\u00e5gonstans runt 6, dvs. vid vilken punkt man b\u00f6r b\u00f6rja anv\u00e4nda swap beroende p\u00e5 hur mycket minne som \u00e4r kvar. Vi r\u00e5der nu att s\u00e4tta vm.swappiness = 1, eftersom detta praktiskt taget st\u00e4nger av det, men inte ger s\u00e5dana effekter som med den ov\u00e4ntat anl\u00e4ndande OOM-killern som d\u00f6dar allt det h\u00e4r.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Vad h\u00e4nder h\u00e4rn\u00e4st? N\u00e4r vi pratar om databasprestanda och gradvis n\u00e4rmar oss diskar, s\u00e5 b\u00f6rjar alla att bli stressade. F\u00f6r sanningen \u00e4r att diskar \u00e4r l\u00e5ngsamma och minnet \u00e4r snabbt, detta \u00e4r n\u00e5got som alla k\u00e4nner till. Och alla vet att det kommer att uppst\u00e5 problem med diskprestanda i databasen.<\/p>\n
<\/p>\n
Huvudproblemet med PostgreSQL:s prestanda, kopplat till checkpoints spikes, uppst\u00e5r inte f\u00f6r att disken \u00e4r l\u00e5ngsam. Det handlar snarare om att kapaciteten hos minnet och disken inte \u00e4r balanserad. De kan vara obalanserade p\u00e5 olika s\u00e4tt. PostgreSQL \u00e4r inte konfigurerat, operativsystemet \u00e4r inte konfigurerat, h\u00e5rdvaran \u00e4r inte r\u00e4tt inst\u00e4lld. Och detta problem uppst\u00e5r inte om allt fungerar som det ska, dvs. antingen finns det ingen belastning, eller s\u00e5 \u00e4r inst\u00e4llningarna och h\u00e5rdvaran v\u00e4l avpassade. <\/p>\n
<\/p>\n
<\/p>\n
Vad \u00e4r det och hur ser det ut? Vanligtvis har personer som arbetar med PostgreSQL st\u00f6tt p\u00e5 detta problem flera g\u00e5nger. Jag ska f\u00f6rklara. Som jag n\u00e4mnde g\u00f6r PostgreSQL periodiskt checkpoints f\u00f6r att dumpa smutsiga sidor fr\u00e5n delat minne till disken. Om vi har ett stort antal sidor i det delade minnet b\u00f6rjar checkpointen att belasta disken intensivt, eftersom den dumpas med fsync. Den g\u00e5r till kernel-buffer och skrivs till diskarna med hj\u00e4lp av fsync. Och om volymen av detta \u00e4r stor kan vi observera en otrevlig effekt, n\u00e4mligen en mycket h\u00f6g diskutilization.<\/p>\n
<\/p>\n
H\u00e4r har jag tv\u00e5 bilder. Jag ska nu f\u00f6rklara vad detta \u00e4r. Det \u00e4r tv\u00e5 tidskorrelerade diagram. Det f\u00f6rsta diagrammet \u2013 det som visar diskutilization. H\u00e4r n\u00e5r den n\u00e4stan upp till 90 % vid denna tidpunkt. Om du upplever databasen mot fysiska diskar, med RAID-kontroller, och diskutilization ligger omkring 90 %, \u00e4r det d\u00e5liga nyheter. Det betyder att om det forts\u00e4tter s\u00e5 h\u00e4r, n\u00e4rmar vi oss 100 och in- och utstr\u00f6mmen kommer att stanna. <\/p>\n
<\/p>\n
Om du har en diskarray, \u00e4r historien lite annorlunda. Det beror p\u00e5 hur den \u00e4r konfigurerad, vilken typ av array det handlar om, osv. <\/p>\n
<\/p>\n
Samtidigt \u00e4r h\u00e4r konfigurerad en graf fr\u00e5n en intern PostgreSQL-vy, som visar hur checkpointen fungerar. Och med gr\u00f6n f\u00e4rg visas antalet buffrar, de smutsiga sidorna som kommit in i denna checkpoint f\u00f6r synkronisering. Detta \u00e4r det viktigaste att k\u00e4nna till h\u00e4r. Vi ser att m\u00e5nga sidor har kommit in och vid en viss tidpunkt har vi k\u00f6rt fast, dvs. vi har skrivit och skrivit, och diskens system \u00e4r uppenbarligen mycket belastat. V\u00e5r checkpoint p\u00e5verkar disken kraftigt. I ett idealiskt fall borde situationen se ut s\u00e5 h\u00e4r, dvs. att vi hade skrivit mindre. Och vi kan justera inst\u00e4llningarna f\u00f6r att se till att det forts\u00e4tter s\u00e5. Dvs. liten utnyttjande, men vi skriver \u00e4nd\u00e5 n\u00e5got h\u00e4r. <\/p>\n
<\/p>\n
Vad beh\u00f6ver g\u00f6ras f\u00f6r att l\u00f6sa detta problem? Om IO har stannat upp under databasen, betyder det att alla anv\u00e4ndare som kommit f\u00f6r att utf\u00f6ra sina f\u00f6rfr\u00e5gningar kommer att f\u00e5 v\u00e4nta. <\/p>\n
<\/p>\n
<\/p>\n
Om man ser p\u00e5 det ur ett Linux-perspektiv, om man har bra h\u00e5rdvara, har konfigurerat den korrekt och normala inst\u00e4llningar f\u00f6r PostgreSQL f\u00f6r att minska antalet checkpoints och sprida ut dem \u00f6ver tid, s\u00e5 hamnar man i standardinst\u00e4llningarna f\u00f6r Debian. F\u00f6r de flesta Linux-distributioner ser bilden ut s\u00e5 h\u00e4r: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Vad betyder detta? Fr\u00e5n k\u00e4rnan 2.6 har en demon f\u00f6r flushing introducerats. Pdglush, beroende p\u00e5 vilken man anv\u00e4nder, ansvarar f\u00f6r bakgrundsvisning av smutsiga sidor fr\u00e5n kernel buffer och f\u00f6r att frig\u00f6ra dessa sidor n\u00e4r det \u00e4r absolut n\u00f6dv\u00e4ndigt, \u00e4ven n\u00e4r bakgrundsfrisl\u00e4ppandet inte r\u00e4cker till. <\/p>\n
<\/p>\n
N\u00e4r intr\u00e4ffar bakgrunden? N\u00e4r 10 % av allt RAM-minne p\u00e5 servern anv\u00e4nds av smutsiga sidor i kernel buffer, aktiveras en s\u00e4rskild funktion f\u00f6r bakgrundsvisning. Varf\u00f6r \u00e4r den bakgrunds? Den tar emot som parameter hur m\u00e5nga sidor som ska frig\u00f6ras. Om den till exempel frig\u00f6r N sidor. Och under en tid g\u00e5r den i vilol\u00e4ge. Sedan kommer den tillbaka och frig\u00f6r ytterligare ett visst antal sidor. <\/p>\n
<\/p>\n
Detta \u00e4r en mycket enkel historia. Det \u00e4r som med en bass\u00e4ng, n\u00e4r det rinner ut genom en slang och fylls upp genom en annan. Vi har en checkpoint och om den har skickat f\u00e5 smutsiga sidor f\u00f6r visning, s\u00e5 kommer pgflush att gradvis l\u00f6sa upp allt detta f\u00f6rsiktigt fr\u00e5n kernel buffer. <\/p>\n
<\/p>\n
Om dessa smutsiga sidor forts\u00e4tter att ackumuleras, n\u00e5r de 20 %, och d\u00e4refter prioriterar OS att frig\u00f6ra dem till disken f\u00f6r att undvika dataf\u00f6rlust vid str\u00f6mavbrott, vilket kan leda till att vi f\u00f6rlorar dessa data. <\/p>\n
<\/p>\n
Vad \u00e4r tricket? Tricket \u00e4r att dessa parametrar, 20 och 10 % av allt RAM-minne i maskinen, \u00e4r helt oacceptabla med avseende p\u00e5 prestanda f\u00f6r vilket disk system som helst.<\/strong> <\/p>\n<\/p>\n
T\u00e4nk dig att du har 128 GB RAM. 12,8 GB n\u00e5r ditt disksystem. Och vilket cacheminne eller array du \u00e4n har d\u00e4r, de kommer inte att klara av s\u00e5 mycket. <\/p>\n
<\/p>\n
<\/p>\n
D\u00e4rf\u00f6r rekommenderar vi att justera dessa siffror baserat p\u00e5 ditt RAID-kontrollers kapabiliteter.<\/strong> H\u00e4r \u00e4r en rekommendation f\u00f6r en kontroller med 512 MB cache. <\/p>\n<\/p>\n
Det anses vara ganska enkelt. Man kan st\u00e4lla in vm.dirty_background i byte. Och dessa inst\u00e4llningar avbryter de tidigare tv\u00e5. Antingen ratio som standard, eller om de som anv\u00e4nder byte \u00e4r aktiverade, kommer de att fungera. Men eftersom jag \u00e4r en DBA-konsult och arbetar med olika kunder f\u00f6rs\u00f6ker jag varna f\u00f6r eventuella problem, s\u00e5 om det \u00e4r i byte, s\u00e5 \u00e4r det i byte. Ingen har gett n\u00e5gon garanti f\u00f6r att en god administrat\u00f6r inte sl\u00e4nger in mer minne till servern, eller startar om den, medan siffran f\u00f6rblir densamma. Ber\u00e4kna bara dessa siffror f\u00f6r att s\u00e4kerst\u00e4lla att allt f\u00e5r plats. <\/p>\n
<\/p>\n
Vad h\u00e4nder om du inte f\u00e5r plats? Jag har skrivit att alla flushing effektivt stoppas, men det \u00e4r egentligen en talfigur. Operativsystemet har ett stort problem \u2013 det finns m\u00e5nga smutsiga sidor, s\u00e5 effektivt stoppas den IO som skapas av dina klienter, det vill s\u00e4ga n\u00e4r en applikation skickar en SQL-fr\u00e5ga till databasen, den v\u00e4ntar. All IO till den har l\u00e4gsta prioritet, eftersom databasen \u00e4r upptagen med checkpoint. Och n\u00e4r den avslutar det \u00e4r helt oklart. Och n\u00e4r du n\u00e5r ett inte bakgrunds- eller inte bakgrundsflushing, betyder det att all din IO \u00e4r upptagen med detta. Och s\u00e5 l\u00e4nge det inte \u00e4r klart, kan du inte g\u00f6ra n\u00e5got. <\/p>\n
<\/p>\n
Det finns ytterligare tv\u00e5 viktiga punkter som ligger utanf\u00f6r denna rapport. Dessa inst\u00e4llningar b\u00f6r matcha inst\u00e4llningarna i postgresql.conf, det vill s\u00e4ga inst\u00e4llningarna f\u00f6r checkpoints. Och ditt lagringssystem m\u00e5ste vara korrekt konfigurerat. Om du har en cache p\u00e5 RAID, m\u00e5ste det finnas ett batteri p\u00e5 den.<\/strong> Folk k\u00f6per RAID med bra cache utan batteri. Om du har SSD i RAID, s\u00e5 m\u00e5ste de vara serverklassade, d\u00e4r m\u00e5ste det finnas kondensatorer.<\/strong> H\u00e4r \u00e4r en utf\u00f6rlig checklista. Genom den h\u00e4r l\u00e4nken finns min presentation om hur man konfigurerar diskprestanda i PostgreSQL. D\u00e4r finns alla dessa checklistor. <\/p>\n<\/p>\n
<\/p>\n
Vad kan dessutom komplicera livet avsev\u00e4rt? Det \u00e4r tv\u00e5 parametrar. De \u00e4r relativt nya. De kan som standard vara aktiverade i olika applikationer. Och de kan f\u00f6rsv\u00e5ra livet inte mindre om de aktiveras felaktigt. <\/p>\n
<\/p>\n
<\/p>\n
Det finns tv\u00e5 relativt nya funktioner. De har redan dykt upp i tredje k\u00e4rnor. Det handlar om sched_migration_cost i nanosekunder och sched_autogroup_enabled, som som standard \u00e4r aktiv. <\/p>\n
<\/p>\n
Och hur f\u00f6rst\u00f6r de livet? Vad \u00e4r sched_migration_cost? I Linux kan schemal\u00e4ggaren migrera en process fr\u00e5n en CPU till en annan. F\u00f6r PostgreSQL, som utf\u00f6r f\u00f6rfr\u00e5gningar, \u00e4r det helt oklart varf\u00f6r migration till en annan CPU skulle beh\u00f6vas. Ur ett operativsystemsperspektiv, n\u00e4r du v\u00e4xlar f\u00f6nster mellan OpenOffice och terminalen, kan detta vara bra, men f\u00f6r databasen \u2013 detta \u00e4r mycket d\u00e5ligt.<\/strong> D\u00e4rf\u00f6r \u00e4r en rimlig policy att s\u00e4tta migration_cost till n\u00e5got stort v\u00e4rde, \u00e5tminstone flera tusen nanosekunder.<\/strong> <\/p>\n<\/p>\n
Vad kommer detta att inneb\u00e4ra f\u00f6r schemal\u00e4ggaren? Den kommer att tro att processen fortfarande \u00e4r \"het\" under denna tid. Det vill s\u00e4ga, om du har en l\u00e5ng transaktion som sysslar med n\u00e5got, kommer schemal\u00e4ggaren att f\u00f6rst\u00e5 detta. Den kommer att anse att s\u00e5 l\u00e4nge denna timeout inte har passerat, beh\u00f6ver inte migration av denna process ske. Om processen g\u00f6r n\u00e5got kommer den inte att migreras, utan avsluta sitt arbete p\u00e5 den CPU som den tilldelats. Resultatet blir utm\u00e4rkt. <\/p>\n
<\/p>\n
En annan aspekt \u00e4r autogroup. Det finns en bra id\u00e9 f\u00f6r specifika arbetsbelastningar som inte har n\u00e5got att g\u00f6ra med moderna databaser \u2013 att gruppera processer efter den virtuella terminal som de k\u00f6rs ifr\u00e5n. Detta \u00e4r praktiskt f\u00f6r vissa uppgifter. I praktiken \u00e4r PostgreSQL ett multiprocessystem med prefork, som startas fr\u00e5n en terminal. Du har lock writer, checkpoint och alla dina klientf\u00f6rfr\u00e5gningar kommer att grupperas p\u00e5 en schemal\u00e4ggare, p\u00e5 en CPU. De kommer att v\u00e4nta d\u00e4r tillsammans tills den blir ledig, f\u00f6r att inte st\u00f6ra varandra och ta l\u00e4ngre tid av den. Denna situation \u00e4r helt on\u00f6dig under s\u00e5dana belastningar och d\u00e4rf\u00f6r beh\u00f6ver den st\u00e4ngas av.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Min kollega Alexey Lesovsky genomf\u00f6rde tester med en enkel pgbench d\u00e4r han \u00f6kade migration_cost med en ordning och st\u00e4ngde av autogroup. Resultatet p\u00e5 d\u00e5lig h\u00e5rdvara var n\u00e4stan 10 %.<\/strong>Det finns en diskussion i PostgreSQL:s mailinglista d\u00e4r folk visar resultat p\u00e5 hur s\u00e5dana f\u00f6r\u00e4ndringar p\u00e5verkat fr\u00e5gehastigheten med 50 %.<\/strong>Det finns m\u00e5nga s\u00e5dana exempel.<\/p>\n<\/p>\n
<\/p>\n
Och slutligen, om str\u00f6msparande policy. Det \u00e4r bra att Linux nu kan anv\u00e4ndas p\u00e5 b\u00e4rbara datorer. Och det kommer att p\u00e5st\u00e5s vara bra f\u00f6r batterif\u00f6rbrukningen. Men pl\u00f6tsligt visar det sig att detta ocks\u00e5 kan h\u00e4nda p\u00e5 servrar. <\/p>\n
<\/p>\n
Mer \u00e4n s\u00e5, om du hyr servrar fr\u00e5n en hostingleverant\u00f6r kan \"sn\u00e4lla\" hostingtj\u00e4nster<\/a> de oro ingen har n\u00e5got fokus p\u00e5 att f\u00f6rb\u00e4ttra din prestanda. Deras uppgift \u00e4r att se till att deras h\u00e5rdvara utnyttjas s\u00e5 effektivt som m\u00f6jligt. D\u00e4rf\u00f6r kan de som standard aktivera energibesparande l\u00e4ge p\u00e5 operativsystemet.<\/p>\n<\/p>\n
Om du anv\u00e4nder en server med en databas under intensiv belastning, \u00e4r ditt val acpi_cpufreq + performance. \u00c4ven med ondemand kommer det att uppst\u00e5 problem.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u00e4r en n\u00e5got annan drivrutin. Nu f\u00f6redras denna, eftersom den \u00e4r nyare och fungerar b\u00e4ttre.<\/p>\n
<\/p>\n
Och d\u00e4rf\u00f6r \u00e4r guvern\u00f6ren endast performance. Ondemand, powersave och allt annat \u00e4r inte f\u00f6r dig. <\/p>\n
<\/p>\n
Resultaten fr\u00e5n explain analyze PostgreSQL kan skilja sig \u00e5t med flera ordningar om du aktiverar powersave, eftersom CPU:n kommer att schemal\u00e4ggas p\u00e5 ett helt of\u00f6ruts\u00e4gbart s\u00e4tt under databasen.<\/p>\n
<\/p>\n
Dessa inst\u00e4llningar kan vara aktiverade som standard. Titta noga f\u00f6r att se om de \u00e4r aktiverade. Detta kan verkligen vara ett stort problem. <\/p>\n
<\/p>\n
<\/p>\n
Och till sist vill jag tacka killarna i v\u00e5rt DBA-team PosgreSQL-Consulting, s\u00e4rskilt Max Boguk och Alexey Lesovsky, som varje dag st\u00f6ter p\u00e5 problemen. Vi f\u00f6rs\u00f6ker g\u00f6ra v\u00e5rt b\u00e4sta f\u00f6r v\u00e5ra kunder s\u00e5 att allt fungerar bra. H\u00e4r \u00e4r det som med flygplanss\u00e4kerhetsinstruktioner. Allt h\u00e4r \u00e4r skrivet med blod. Varje skruv uppt\u00e4cktes n\u00e4r ett problem uppstod. Jag delar g\u00e4rna med mig av dem till er.<\/p>\n
<\/p>\n
Fr\u00e5gor:<\/p>\n
<\/p>\n
Tack! Om ett f\u00f6retag till exempel vill spara pengar och k\u00f6ra en databas och applikationslogik p\u00e5 samma server, eller om f\u00f6retaget f\u00f6ljer den trendiga riktningen av mikrotj\u00e4nstarkitekturer d\u00e4r PostgreSQL k\u00f6rs i en container. Vad \u00e4r grejen? Sysctl p\u00e5verkar globalt hela k\u00e4rnan. Jag har inte h\u00f6rt talas om att sysctl p\u00e5 n\u00e5got s\u00e4tt virtualiseras s\u00e5 att de fungerar separat i containern. Det finns bara cgroup och d\u00e4r finns kontrollen bara f\u00f6r en del. Hur kan man leva med det? Eller om du vill ha prestanda, k\u00f6r PostgreSQL p\u00e5 en separat fysisk server och optimera den?<\/em><\/p>\n<\/p>\n
Vi har svarat p\u00e5 din fr\u00e5ga p\u00e5 ungef\u00e4r tre s\u00e4tt. Om det inte handlar om en dedikerad server som du kan optimera och s\u00e5 vidare, kan du slappna av \u2013 det kommer att fungera bra utan dessa inst\u00e4llningar. Om du har en s\u00e5dan belastning att du beh\u00f6ver g\u00f6ra dessa inst\u00e4llningar kommer du att beh\u00f6va en dedikerad server tidigare \u00e4n du n\u00e5r dessa inst\u00e4llningar.<\/p>\n
<\/p>\n
Vad \u00e4r problemet? Om det \u00e4r en virtuell maskin kommer du troligen att ha m\u00e5nga problem, till exempel att det \u00e4r mycket inkonsekvent latens p\u00e5 diskarna i de flesta virtuella maskiner. \u00c4ven om diskarna har bra bandbredd kan en misslyckad I\/O-transaktion, som inte p\u00e5verkar den genomsnittliga bandbredden mycket, h\u00e4nda under en checkpoint eller vid skrivning till WAL, och databasen kommer att lida av det. Och du kommer att m\u00e4rka det tidigare \u00e4n du hamnar i dessa problem. <\/p>\n
<\/p>\n
Om du har NGINX p\u00e5 samma server kommer du att ha samma problem. Den kommer att sl\u00e5ss om det delade minnet. Och du kommer inte att n\u00e5 de problem som beskrivs h\u00e4r.<\/p>\n
<\/p>\n
Men \u00e5 andra sidan kommer vissa av dessa parametrar fortfarande att vara relevanta f\u00f6r dig. Till exempel, med sysctl kan du st\u00e4lla in dirty_ratio s\u00e5 att den inte \u00e4r s\u00e5 galen \u2013 det kommer att hj\u00e4lpa p\u00e5 n\u00e5got s\u00e4tt. Hur som helst kommer du att ha interaktion med disken. Och det kommer att vara felaktigt. Det \u00e4r faktiskt standarden f\u00f6r de parametrar som jag visade. Och det \u00e4r b\u00e4ttre att \u00e4ndra dem oavsett. <\/p>\n
<\/p>\n
Det kan finnas problem med NUMA. VmWare fungerar till exempel bra med NUMA med helt motsatt inst\u00e4llning. H\u00e4r m\u00e5ste du v\u00e4lja \u2013 dedikerad server eller inte. <\/p>\n
<\/p>\n
Jag har en fr\u00e5ga relaterad till Amazon AWS. De har f\u00f6rinst\u00e4llda bilder. En av dem kallas Amazon RDS. Finns det n\u00e5gra anpassade inst\u00e4llningar f\u00f6r deras operativsystem?<\/em><\/p>\n<\/p>\n
Det finns inst\u00e4llningar, men det \u00e4r andra inst\u00e4llningar. H\u00e4r konfigurerar vi operativsystemet utifr\u00e5n hur databasen kommer att anv\u00e4nda det. Och d\u00e4r finns det parametrar som best\u00e4mmer vart vi ska g\u00e5 nu, s\u00e5 mycket shaping. Det vill s\u00e4ga, vi beh\u00f6ver s\u00e5 mycket resurser, och vi kommer att utnyttja dem nu. Efter det kopplar Amazon RDS dessa resurser, och prestandan faller. Det finns separata ber\u00e4ttelser om hur folk b\u00f6rjar experimentera med detta. Ibland ganska framg\u00e5ngsrikt. Men det har inget att g\u00f6ra med operativsystemets inst\u00e4llningar. Det handlar mer om att hacka molnet. Det \u00e4r en annan historia.<\/p>\n
<\/p>\n
Varf\u00f6r ger Transparent huge pages ingen effekt j\u00e4mf\u00f6rt med Huge TLB?<\/em><\/p>\n<\/p>\n
Det g\u00f6r de inte. Detta kan f\u00f6rklaras p\u00e5 m\u00e5nga s\u00e4tt. Men faktum \u00e4r att de helt enkelt inte bidrar. Vad \u00e4r historien med PostgreSQL? Vid start reserverar den en stor del av det delade minnet. Oavsett om de \u00e4r transparenta eller inte \u2014 det spelar ingen roll. Faktumet att de allokeras vid start f\u00f6rklarar allt. Om det finns mycket minne och det beh\u00f6ver omstruktureras, d\u00e5 blir Transparent huge pages aktuellt. I PostgreSQL allokeras det helt enkelt en stor del fr\u00e5n b\u00f6rjan och sedan h\u00e4nder det inget s\u00e4rskilt l\u00e4ngre. Man kan sj\u00e4lvklart anv\u00e4nda det, men det finns en risk att f\u00e5 korrupt delat minne n\u00e4r det omallokerar n\u00e5got. PostgreSQL vet ju inte om detta.<\/p>\n
K\u00e4lla: 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-justering](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n