Linux-inställning för att förbättra PostgreSQL-prestanda. Ilya Kosmodemyansky

Transkription av 2015 års rapport av Ilya Kosmodemyansky "Linux-inställning för att förbättra PostgreSQL-prestanda"

Disclaimer: Jag noterar att denna rapport är daterad november 2015 - mer än 4 år har gått och mycket tid har gått. Den version 9.4 som diskuteras i rapporten stöds inte längre. Under de senaste fyra åren har 4 nya versioner av PostgreSQL släppts och 5 versioner av Linux-kärnan har släppts. Om du skriver om dessa avsnitt kommer du att få en annan rapport. Men här överväger vi grundläggande Linux-inställning för PostgreSQL, vilket fortfarande är relevant idag.

Mitt namn är Ilya Kosmodemyansky. Jag arbetar på PostgreSQL-Consulting. Och nu ska jag prata lite om vad man ska göra med Linux i förhållande till databaser i allmänhet och PostgreSQL i synnerhet, eftersom principerna är ganska lika.

Vad ska vi prata om? Om du kommunicerar med PostgreSQL måste du till viss del vara UNIX-administratör. Vad betyder det? Om vi ​​jämför Oracle och PostgreSQL, måste du i Oracle vara 80 % DBA-databasadministratör och 20 % Linux-admin.

Med PostgreSQL är det lite mer komplicerat. Med PostgreSQL behöver du ha en mycket bättre förståelse för hur Linux fungerar. Och samtidigt springa lite efter loket, för på sistone har allt uppdaterats ganska snyggt. Och nya kärnor släpps, och ny funktionalitet dyker upp, prestanda förbättras, etc.

Varför pratar vi om Linux? Inte alls för att vi är på Linuxkonferensen Peter, utan för att i moderna förhållanden är ett av de mest motiverade operativsystemen för att använda databaser i allmänhet och PostgreSQL i synnerhet Linux. Eftersom FreeBSD, tyvärr, utvecklas i någon mycket konstig riktning. Och det blir problem både med prestanda och med mycket annat. Prestandan för PostgreSQL på Windows är generellt sett ett separat allvarligt problem, baserat på det faktum att Windows inte har samma delade minne som UNIX, medan PostgreSQL är kopplat till detta, eftersom det är ett multiprocesssystem.

Och jag tror att alla är mindre intresserade av exotiska saker som Solaris, så låt oss gå.

En modern Linux-distribution har över 1 000 syctl-alternativ, beroende på hur du bygger kärnan. Samtidigt, om vi tittar på de olika muttrarna, kan vi justera något på många sätt. Det finns filsystemparametrar för hur man monterar dem. Om du har frågor om hur du startar det: vad du ska aktivera i BIOS, hur du konfigurerar hårdvaran, etc.

Det här är en mycket stor volym som kan diskuteras över flera dagar, och inte i en kort rapport, men nu ska jag fokusera på viktiga saker, hur man undviker de rakes som garanterat hindrar dig från att använda din databas bra på Linux om du korrigera dem inte. Och samtidigt är en viktig poäng att många standardparametrar inte ingår i de inställningar som är korrekta för databasen. Det vill säga, som standard kommer det att fungera dåligt eller inte alls.

Vilka traditionella inställningsmål finns det i Linux? Jag tror att eftersom ni alla har att göra med Linux-administration finns det inget särskilt behov av att förklara vad mål är.

Du kan ställa in:

• CPU.
• Minne.
• Lagring.
• Övrig. Vi pratar om detta i slutet för ett mellanmål. Även till exempel parametrar som energisparpolitik kan påverka prestandan på ett mycket oförutsägbart och inte det mest trevliga sättet.

Vilka är detaljerna för PostgreSQL och databasen i allmänhet? Problemet är att du inte kan justera någon enskild mutter och se att vår prestanda har förbättrats avsevärt.

Ja, det finns sådana prylar, men en databas är en komplex sak. Den interagerar med alla resurser som servern har och föredrar att interagera till fullo. Om du tittar på Oracles nuvarande rekommendationer om hur man använder ett värdoperativsystem, kommer det att vara som skämtet om den mongoliska kosmonauten - mata hunden och inte röra någonting. Låt oss ge databasen alla resurser, själva databasen kommer att reda ut allt.

I princip är situationen i viss mån exakt densamma med PostgreSQL. Skillnaden är att databasen ännu inte kan ta alla resurser för sig själv, d.v.s. någonstans på Linux-nivå behöver du reda ut det hela själv.

Huvudidén är inte att välja ett enda mål och börja ställa in det, till exempel minne, CPU eller något liknande, utan att analysera arbetsbelastningen och försöka förbättra genomströmningen så mycket som möjligt så att belastningen som bra programmerare skapade den för oss, inklusive våra användare.

Här är en bild för att förklara vad det är. Det finns en Linux OS-buffert och det finns delat minne och det finns PostgreSQL delade buffertar. PostgreSQL, till skillnad från Oracle, fungerar bara direkt genom kärnbufferten, det vill säga för att en sida från disken ska komma in i dess delade minne måste den gå igenom kärnbufferten och tillbaka, exakt samma situation.

Diskar lever under detta system. Jag ritade detta som diskar. Faktum är att det kan finnas en RAID-kontroller, etc.

Och denna input-output sker på ett eller annat sätt genom denna fråga.

PostgreSQL är en klassisk databas. Det finns en sida inuti. Och all in- och utmatning sker med hjälp av sidor. Vi lyfter upp block i minnet med sidor. Och om inget hände, läser vi dem bara, sedan försvinner de gradvis från denna cache, från de delade buffertarna och hamnar tillbaka på disken.

Om vi ​​byter ut något någonstans markeras hela sidan som smutsig. Jag markerade dem här i blått. Och det betyder att den här sidan måste synkroniseras med blocklagring. Det vill säga när vi gjorde det smutsigt gjorde vi ett inlägg i WAL. Och vid något underbart ögonblick i tiden kom ett fenomen som kallas checkpoint. Och information antecknades i denna logg om att han hade anlänt. Och detta betyder att alla smutsiga sidor som fanns här vid det ögonblicket i dessa delade buffertar synkroniserades med lagringsdisken med hjälp av fsync genom kärnbufferten.

Varför görs detta? Om vi ​​tappade spänningen så fick vi inte situationen att all data gick förlorad. Persistent minne, som alla berättade om, finns hittills i databasteorin - det här är en ljus framtid, som vi naturligtvis strävar efter och vi gillar det, men för närvarande lever de om minus 20 år. Och naturligtvis måste allt detta övervakas.

Och uppgiften att maximera genomströmningen är att finjustera i alla dessa stadier så att det hela rör sig snabbt fram och tillbaka. Delat minne är i grunden en sidcache. I PostgreSQL skickade vi en urvalsfråga eller något, den hämtade denna data från disken. De hamnade i delade buffertar. Följaktligen måste det finnas mycket minne för att detta ska fungera bättre.

För att allt detta ska fungera bra och snabbt måste du konfigurera operativsystemet korrekt i alla skeden. Och välj balanserad hårdvara, för om du har en obalans på något ställe, då kan du göra mycket minne, men det kommer inte att servas i tillräcklig hastighet.

Och låt oss gå igenom var och en av dessa punkter.

För att få dessa sidor att resa fram och tillbaka snabbare måste du uppnå följande:

• För det första måste du arbeta mer effektivt med minnet.
• För det andra bör denna övergång när sidor från minnet går till disken vara mer effektiv.
• Och för det tredje måste det finnas bra diskar.

Om du har 512 GB RAM i servern och allt hamnar på en SATA-hårddisk utan någon cache, så förvandlas hela databasservern till inte bara en pumpa, utan en pumpa med ett SATA-gränssnitt. Du kommer att stöta på det direkt. Och ingenting kommer att rädda dig.

Angående den första punkten med minnet så finns det tre saker som kan göra livet väldigt svårt.

Den första av dem är NUMA. NUMA är en sak som är gjord för att förbättra prestandan. Beroende på arbetsbelastningen kan olika saker optimeras. Och i sin nya nuvarande form är det inte särskilt bra för applikationer som databaser som intensivt använder sidcache-delade buffertar.

I ett nötskal. Hur kan du se om något är fel med NUMA? Du har någon form av obehaglig knackning, plötsligt är någon CPU överbelastad. Samtidigt analyserar du frågor i PostgreSQL och ser att det inte finns något liknande där. Dessa frågor bör inte vara så CPU-intensiva. Du kan fånga detta länge. Det är lättare att använda rätt rekommendation redan från början om hur man konfigurerar NUMA för PostgreSQL.

Vad är det som händer egentligen? NUMA står för Non-Uniform Memory Access. Vad är poängen? Du har en CPU, bredvid den finns dess lokala minne. Och dessa minnesanslutningar kan dra upp minne från andra processorer.

Om du springer numactl --hardware, då får du ett så stort ark. Det kommer bland annat att finnas ett distansfält. Det blir siffror - 10-20, något sånt. Dessa siffror är inget annat än antalet hopp för att plocka upp det här fjärrminnet och använda det lokalt. I princip en bra idé. Detta snabbar upp prestanda bra under en rad arbetsbelastningar.

Föreställ dig nu att du har en CPU som först försöker använda sitt lokala minne och sedan försöker dra upp ett annat minne via sammankoppling för något. Och den här processorn får hela din PostgreSQL-sidcache - det är det, några gigabyte. Du får alltid det värsta fallet, för på CPU:n finns det oftast lite minne i själva modulen. Och allt minne som betjänas går genom dessa sammankopplingar. Det blir långsamt och trist. Och din processor som servar denna nod är ständigt överbelastad. Och åtkomsttiden för detta minne är dålig, långsam. Det här är situationen du inte vill ha om du använder den för en databas.

Därför är ett mer korrekt alternativ för databasen att operativsystemet Linux inte alls vet vad som händer där. Så att den kommer åt minnet som den gör.

Varför är det så? Det verkar som att det borde vara tvärtom. Detta händer av en enkel anledning: vi behöver mycket minne för sidcachen - tiotals, hundratals gigabyte.

Och om vi allokerade allt detta och cachade vår data där, så kommer vinsten från att använda cachen att vara betydligt större än vinsten från en så knepig åtkomst till minnet. Och vi kommer därmed att gynnas ojämförligt jämfört med det faktum att vi kommer åt minnet mer effektivt med NUMA.

Därför finns det två tillvägagångssätt här för tillfället, tills den ljusa framtiden har anlänt, och databasen själv inte kan lista ut vilka CPU:er den körs på och var den behöver hämta något ifrån.

Därför är det korrekta tillvägagångssättet att inaktivera NUMA helt och hållet, till exempel vid omstart. I de flesta fall är vinsterna av sådan storleksordning att frågan om vilket som är bäst inte alls uppstår.

Det finns ett annat alternativ. Vi använder den oftare än den första, för när en klient kommer till oss för att få support är det en stor sak för honom att starta om servern. Han har ett företag där. Och de upplever problem på grund av NUMA. Därför försöker vi inaktivera den på mindre invasiva sätt än att starta om, men var noga med att kontrollera att den är inaktiverad. För, som erfarenheten visar, är det bra att vi inaktiverar NUMA på den överordnade PostgreSQL-processen, men det är inte alls nödvändigt att det fungerar. Vi måste kolla och se att hon verkligen stängt av.

Det finns ett bra inlägg av Robert Haas. Detta är en av PostgreSQL-kommittarna. En av de viktigaste utvecklarna av alla lågnivågiblets. Och om du följer länkarna från det här inlägget beskriver de flera färgstarka berättelser om hur NUMA gjorde livet svårt för människor. Titta, studera systemadministratörens checklista över vad som behöver konfigureras på servern för att vår databas ska fungera bra. Dessa inställningar måste skrivas ner och kontrolleras, för annars blir det inte särskilt bra.

Observera att detta gäller alla inställningar som jag kommer att prata om. Men vanligtvis samlas databaser in i master-slave-läge för feltolerans. Glöm inte att göra dessa inställningar på slaven för en dag kommer du att råka ut för en olycka och du kommer att byta till slaven och den kommer att bli master.

I en nödsituation, när allt är väldigt dåligt, din telefon hela tiden ringer och din chef kommer springande med en stor pinne, har du ingen tid att tänka på att kolla. Och resultaten kan bli ganska katastrofala.

Nästa punkt är stora sidor. Enorma sidor är svåra att testa separat, och det är ingen idé att göra det, även om det finns riktmärken som kan göra detta. De är lätta att Google.

Vad är poängen? Du har en inte särskilt dyr server med mycket RAM, till exempel mer än 30 GB. Du använder inte stora sidor. Detta innebär att du definitivt har overhead när det gäller minnesanvändning. Och denna overhead är långt ifrån den mest trevliga.

Varför är det så? Så vad händer? Operativsystemet allokerar minne i små bitar. Det är så bekvämt, det är så det hände historiskt. Och om vi går in på detaljer måste operativsystemet översätta virtuella adresser till fysiska. Och denna process är inte den enklaste, så operativsystemet cachar resultatet av denna operation i Translation Lookaside Buffer (TLB).

Och eftersom TLB är en cache, uppstår alla problem som är inneboende i en cache i denna situation. För det första, om du har mycket RAM och allt är allokerat i små bitar, så blir denna buffert väldigt stor. Och om cachen är stor går det långsammare att söka igenom det. Overhead är hälsosamt och det tar i sig utrymme, d.v.s. RAM-minnet förbrukas av något felaktigt. Den här gången.

Två - ju mer cachen växer i en sådan situation, desto mer sannolikt är det att du får cachemissar. Och effektiviteten för denna cache minskar snabbt när dess storlek ökar. Därför kom operativsystemen med ett enkelt tillvägagångssätt. Det har använts i Linux under lång tid. Det dök upp i FreeBSD för inte så länge sedan. Men vi pratar om Linux. Det här är enorma sidor.

Och här bör det noteras att enorma sidor, som en idé, från början drevs av gemenskaper som inkluderade Oracle och IBM, det vill säga databastillverkare trodde starkt att detta skulle vara användbart för databaser också.

Och hur kan detta bli vän med PostgreSQL? För det första måste stora sidor vara aktiverade i Linux-kärnan.

För det andra måste de explicit specificeras av sysctl-parametern - hur många det finns. Siffrorna här är från någon gammal server. Du kan räkna ut hur många delade buffertar du har så att enorma sidor får plats där.

Och om hela din server är dedikerad till PostgreSQL, så är en bra utgångspunkt att allokera antingen 25% av RAM-minnet till delade buffertar, eller 75% om du är säker på att din databas definitivt kommer att passa i dessa 75%. Utgångspunkt ett. Och tänk på att om du har 256 GB RAM-minne, kommer du följaktligen att ha 64 GB stora buffertar. Räkna ungefär med viss marginal - vad denna siffra ska sättas till.

Före version 9.2 (om jag inte har fel, sedan version 8.2) var det möjligt att koppla PostgreSQL med enorma sidor med hjälp av ett tredjepartsbibliotek. Och detta bör alltid göras. Först behöver du kärnan för att kunna allokera enorma sidor korrekt. Och för det andra så att applikationen som fungerar med dem kan använda dem. Det kommer inte bara att användas på det sättet. Eftersom PostgreSQL allokerade minne i system 5-stilen kunde detta göras med libhugetlbfs - detta är bibliotekets fullständiga namn.

I 9.3 förbättrades PostgreSQL-prestanda när man arbetade med minne och system 5-minnestilldelningsmetoden övergavs. Alla var väldigt glada, för annars försöker man köra två PostgreSQL-instanser på en maskin, och han säger att jag inte har tillräckligt med delat minne. Och han säger att sysctl måste korrigeras. Och det finns en sådan sysctl att du fortfarande behöver starta om, etc. I allmänhet var alla nöjda. Men tilldelning av mmap-minne bröt användningen av enorma sidor. De flesta av våra kunder använder stora delade buffertar. Och vi rekommenderade starkt att inte byta till 9.3, för där började omkostnaderna beräknas i bra procentsatser.

Men samhället uppmärksammade detta problem och i 9.4 omarbetade de denna händelse mycket bra. Och i 9.4 dök en parameter upp i postgresql.conf där du kan aktivera försök, på eller av.

Prova är det säkraste alternativet. När PostgreSQL startar, när den allokerar delat minne, försöker den ta detta minne från de enorma sidorna. Och om det inte fungerar, rullar det tillbaka till det normala valet. Och om du har FreeBSD eller Solaris, då kan du prova, det är alltid säkert.

Om den är på startar den helt enkelt inte om den inte kunde välja från de enorma sidorna. Här handlar det redan om vem och vad som är snyggast. Men om du har försökt, kontrollera då att du verkligen har det du behöver markerat, för det finns mycket utrymme för fel. För närvarande fungerar den här funktionen bara på Linux.

En liten anteckning till innan vi går vidare. Transparenta enorma sidor handlar inte om PostgreSQL än. Han kan inte använda dem normalt. Och med Transparenta enorma sidor för en sådan arbetsbelastning, när en stor bit delat minne behövs, kommer fördelarna bara med mycket stora volymer. Om du har terabyte minne kan detta spela in. Om vi ​​pratar om mer vardagliga applikationer, när du har 32, 64, 128, 256 GB minne på din maskin, då är de vanliga enorma sidorna Ok, och vi inaktiverar helt enkelt Transparent.

Och det sista med minnet är inte direkt relaterat till fruitut, det kan verkligen förstöra ditt liv. All genomströmning kommer att påverkas kraftigt av att servern ständigt byter.

Och detta kommer att vara väldigt obehagligt på flera sätt. Och huvudproblemet är att moderna kärnor beter sig något annorlunda än äldre Linux-kärnor. Och den här saken är ganska obehaglig att trampa på, för när vi pratar om något slags arbete med swap, slutar det med att OOM-mördaren kommer i tid. Och OOM-mördaren, som inte kom fram i tid och släppte PostgreSQL, är obehaglig. Alla kommer att veta om detta, det vill säga tills den sista användaren.

Vad händer? Du har en stor mängd RAM där, allt fungerar bra. Men av någon anledning hänger servern i swap och saktar ner på grund av detta. Det verkar som att det finns mycket minne, men detta händer.

Tidigare rekommenderade vi att ställa in vm.swappiness till noll, det vill säga att inaktivera swap. Tidigare verkade det som att 32 GB RAM och motsvarande delade buffertar var en enorm mängd. Huvudsyftet med bytet är att ha en plats att kasta skorpan om vi ramlar av. Och det var inte längre särskilt uppfyllt. Och vad ska du göra med den här skorpan? Detta är en uppgift där det inte är särskilt tydligt varför swap behövs, särskilt av en sådan storlek.

Men i mer moderna, d.v.s. tredje versioner av kärnan, har beteendet förändrats. Och om du ställer in swap på noll, det vill säga stänger av det, kommer förr eller senare, även om det finns lite RAM kvar, en OOM-mördare att komma till dig för att döda de mest intensiva konsumenterna. För han kommer att anse att med en sådan arbetsbelastning har vi fortfarande en liten bit kvar och vi kommer att hoppa ut, det vill säga inte för att spika systemprocessen, utan för att spika något mindre viktigt. Denne mindre viktiga kommer att vara den intensiva konsumenten av delat minne, nämligen postmästaren. Och efter det kommer det att vara bra om basen inte behöver återställas.

Därför är nu standard, såvitt jag minns, de flesta distributioner är någonstans runt 6, dvs vid vilken tidpunkt ska du börja använda swap beroende på hur mycket minne som finns kvar. Vi rekommenderar nu att ställa in vm.swappiness = 1, eftersom detta praktiskt taget stänger av det, men ger inte samma effekter som med en OOM-mördare som oväntat anlände och dödade det hela.

Vad kommer härnäst? När vi pratar om databasers prestanda och gradvis rör oss mot diskar, börjar alla ta tag i huvudet. För sanningen att skivan är långsam och minnet är snabbt är bekant för alla från barndomen. Och alla vet att databasen kommer att ha problem med diskprestanda.

Det huvudsakliga PostgreSQL-prestandaproblemet som är associerat med kontrollpunkters toppar uppstår inte eftersom disken är långsam. Detta beror med största sannolikhet på att minnet och diskbandbredden inte är balanserade. De kanske inte är balanserade på olika ställen. PostgreSQL är inte konfigurerat, operativsystemet är inte konfigurerat, hårdvaran är inte konfigurerad och hårdvaran är felaktig. Och det här problemet uppstår inte bara om allt händer som det ska, det vill säga antingen det inte är någon belastning eller så är inställningarna och hårdvaran väl valda.

Vad är det och hur ser det ut? Vanligtvis har personer som arbetar med PostgreSQL gått in i denna fråga mer än en gång. Jag ska förklara. Som jag sa, PostgreSQL gör periodvis kontrollpunkter för att dumpa smutsiga sidor i delat minne till disk. Om vi ​​har en stor mängd delat minne, börjar checkpoint ha en intensiv inverkan på disken, eftersom den dumpar dessa sidor med fsync. Den anländer till kärnbufferten och skrivs till diskar med fsync. Och om volymen av denna verksamhet är stor, kan vi observera en obehaglig effekt, nämligen en mycket stor användning av diskar.

Här har jag två bilder. Jag ska nu förklara vad det är. Dessa är två tidskorrelerade grafer. Den första grafen är diskutnyttjande. Här når den nästan 90 % vid denna tidpunkt. Om du har ett databasfel med fysiska diskar, med en RAID-kontrolleranvändning på 90 %, så är detta dåliga nyheter. Det betyder att lite mer och det kommer att nå 100 och I/O kommer att stanna.

Om du har en diskarray är det en lite annorlunda historia. Det beror på hur det är konfigurerat, vilken typ av array det är osv.

Och parallellt konfigureras här en graf från den interna postgres-vyn, som berättar hur kontrollpunkten uppstår. Och den gröna färgen här visar hur många buffertar, dessa smutsiga sidor, som i det ögonblicket anlände till denna kontrollpunkt för synkronisering. Och detta är det viktigaste du behöver veta här. Vi ser att vi har många sidor här och någon gång slog vi till på brädan, det vill säga vi skrev och skrev, här är skivsystemet helt klart väldigt upptaget. Och vår checkpoint har en mycket stark inverkan på disken. Helst skulle situationen se ut mer så här, det vill säga vi hade mindre inspelning här. Och vi kan fixa det med inställningarna så att det fortsätter att vara så här. Det vill säga återvinningen är liten, men någonstans skriver vi något här.

Vad behöver göras för att övervinna detta problem? Om du har stoppat IO under databasen betyder det att alla användare som kom för att uppfylla sina önskemål väntar.

Om du ser ur Linux synvinkel, om du tog bra hårdvara, konfigurerade den korrekt, konfigurerade PostgreSQL normalt så att den gör dessa kontrollpunkter mer sällan, sprider dem över tid mellan varandra, så går du in i Debians standardparametrar. För de flesta Linux-distributioner är detta bilden: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Vad betyder det? En spolningsdemon dök upp från kärnan 2.6. Pdglush, beroende på vem som använder vilken, som är engagerad i bakgrundskastning av smutsiga sidor från kärnbufferten och kassering när det är nödvändigt att kassera smutsiga sidor oavsett vad, när kassering i bakgrunden inte hjälper.

När kommer bakgrunden? När 10 % av det totala RAM-minnet som är tillgängligt på servern är upptaget av smutsiga sidor i kärnbufferten, anropas en speciell avskrivningsfunktion i bakgrunden. Varför är det bakgrund? Som parameter tar den hänsyn till hur många sidor som ska skrivas av. Och låt oss säga, han skriver av N sidor. Och för en stund somnar den här saken. Och så kommer hon igen och kopierar några sidor till.

Det här är en extremt enkel historia. Problemet här är som med en simbassäng, när det häller i ett rör rinner det ut i ett annat. Vår kontrollpunkt anlände och om den skickade några smutsiga sidor för att kastas, så kommer det hela gradvis att lösas snyggt från kärnbufferten pgflush.

Om dessa smutsiga sidor fortsätter att ackumuleras ackumuleras de upp till 20%, varefter OS-prioriteten är att skriva av det hela till disken, eftersom strömmen kommer att gå sönder och allt blir dåligt för oss. Vi kommer till exempel att förlora denna data.

Vad är tricket? Tricket är att dessa parametrar i den moderna världen är 20 och 10% av det totala RAM-minnet som finns på maskinen, de är helt monstruösa när det gäller genomströmningen av alla disksystem du har.

Föreställ dig att du har 128 GB RAM. 12,8 GB kommer till ditt disksystem. Och oavsett vilken cache du har där, oavsett vilken array du har där, kommer de inte att hålla så länge.

Därför rekommenderar vi att du omedelbart justerar dessa siffror baserat på kapaciteten hos din RAID-kontroller. Jag gav direkt en rekommendation här för en kontroller som har 512 MB cache.

Allt anses vara väldigt enkelt. Du kan lägga vm.dirty_background i byte. Och dessa inställningar avbryter de två föregående. Antingen är förhållandet som standard, eller så är de med byte aktiverade, då fungerar de med byte. Men eftersom jag är DBA-konsult och jobbar med olika kunder försöker jag dra strån och därför, om i byte, så i byte. Ingen gav någon garanti för att en bra administratör inte skulle lägga till mer minne till servern, starta om den och siffran skulle förbli densamma. Räkna bara ut dessa siffror så att allt får plats där med garanti.

Vad händer om du inte passar in? Jag har skrivit att all spolning effektivt stoppas, men i själva verket är detta ett tal. Operativsystemet har ett stort problem - det har många smutsiga sidor, så den IO som dina klienter genererar stoppas effektivt, dvs applikationen har kommit för att skicka en sql-fråga till databasen, den väntar. Alla in-/utdata till den har lägst prioritet, eftersom databasen är upptagen av en kontrollpunkt. Och när hon blir klar är helt oklart. Och när du har uppnått icke-bakgrundsspolning, betyder det att all din IO är upptagen av den. Och tills det tar slut kommer du inte att göra något.

Det finns ytterligare två viktiga punkter här som ligger utanför ramen för denna rapport. Dessa inställningar bör matcha inställningarna i postgresql.conf, det vill säga kontrollpunktersinställningar. Och ditt disksystem måste vara tillräckligt konfigurerat. Om du har en cache på en RAID måste den ha ett batteri. Folk köper RAID med bra cache utan batteri. Har du SSD:er i RAID så måste de vara server, det måste finnas kondensatorer där. Här är en detaljerad checklista. Den här länken innehåller min rapport om hur man konfigurerar en prestandadisk i PostgreSQL. Det finns alla dessa checklistor där.

Vad mer kan göra livet mycket svårt? Detta är två parametrar. De är relativt nya. Som standard kan de inkluderas i olika applikationer. Och de kan göra livet lika svårt om de sätts på fel.

Det är två relativt nya saker. De har redan dykt upp i de tredje kärnorna. Detta är sched_migration_cost i nanosekunder och sched_autogroup_enabled, vilket är en som standard.

Och hur förstör de ditt liv? Vad är sched_migration_cost? På Linux kan schemaläggaren migrera en process från en CPU till en annan. Och för PostgreSQL, som kör frågor, är det helt oklart att migrera till en annan CPU. Ur operativsystemsynpunkt, när du byter fönster mellan openoffice och terminal, kan det här vara bra, men för en databas är detta mycket dåligt. Därför är en rimlig policy att sätta migration_cost till något stort värde, åtminstone flera tusen nanosekunder.

Vad kommer detta att betyda för schemaläggaren? Det kommer att övervägas att processen fortfarande är varm under denna tid. Det vill säga, om du har en långvarig transaktion som har gjort något under lång tid, kommer schemaläggaren att förstå detta. Han kommer att anta att det inte finns något behov av att migrera denna process någonstans tills denna timeout går. Om samtidigt processen gör något, kommer den inte att migreras någonstans, den kommer tyst att fungera på CPU:n som tilldelades den. Och resultatet är utmärkt.

Den andra punkten är autogrupp. Det finns en bra idé för specifika arbetsbelastningar som inte är relaterade till moderna databaser - det här är att gruppera processer efter den virtuella terminalen från vilken de startas. Detta är praktiskt för vissa uppgifter. I praktiken är PostgreSQL ett multiprocesssystem med en förgaffel som körs från en enda terminal. Du har en låsskrivare, kontrollpunkt och alla dina klientförfrågningar kommer att grupperas i en schemaläggare per CPU. Och de kommer att vänta där unisont på att han ska bli fri, för att störa varandra och hålla honom sysselsatt längre. Det här är en historia som är helt onödig vid en sådan belastning och därför måste den stängas av.

Min kollega Alexey Lesovsky gjorde tester med en enkel pgbench, där han ökade migration_cost med en storleksordning och stängde av autogrupp. Skillnaden på dålig hårdvara var nästan 10 %. Det pågår en diskussion på postgres e-postlista där människor ger resultat av liknande förändringar av frågehastighet påverkade 50%. Det finns ganska många sådana historier.

Och slutligen, om energisparpolitik. Det som är bra är att Linux nu kan användas på en bärbar dator. Och det kommer förmodligen att använda upp batteriet bra. Men plötsligt visar det sig att detta även kan hända på servern.

Dessutom, om du hyr servrar från någon värd, så bryr sig inte de "bra" värdarna om att du har bättre prestanda. Deras uppgift är att se till att deras järn utnyttjas så effektivt som möjligt. Därför kan de som standard aktivera strömsparläge för bärbar dator på operativsystemet.

Om du använder det här på en server med en databas under hög belastning, då är ditt val acpi_cpufreq + permormance. Även med on-demand kommer det att finnas problem.

Intel_pstate är en lite annorlunda drivrutin. Och nu ges företräde åt denna, eftersom den är senare och fungerar bättre.

Och följaktligen är guvernör bara prestation. Ondemand, energispar och allt annat handlar inte om dig.

Resultaten av den förklarade analysen PostgreSQL kan skilja sig åt i flera storleksordningar om du aktiverar energisparläge, eftersom praktiskt taget CPU:n under din databas kommer att köras på ett helt oförutsägbart sätt.

Dessa objekt kan inkluderas som standard. Titta noga för att se om de har aktiverat det som standard. Detta kan vara ett riktigt stort problem.

Och till sist ville jag säga tack till killarna från vårt PosgreSQL-Consulting DBA-team, nämligen Max Boguk och Alexey Lesovsky, som gör framsteg i denna fråga varje dag. Och vi försöker göra det bästa vi kan för våra kunder så att allt fungerar för dem. Det är som med flygsäkerhetsinstruktioner. Allt här är skrivet i blod. Var och en av dessa nötter finns i processen med något slags problem. Jag delar dem gärna med dig.

Frågor:

Tack! Om till exempel ett företag vill spara pengar och placera databasen och applikationslogiken på en server, eller om företaget följer den fashionabla trenden med mikrotjänstarkitekturer, där PostgreSQL körs i en container. Vad är tricket? Sysctl kommer att påverka hela kärnan globalt. Jag har inte hört talas om att sysctls på något sätt virtualiseras så att de fungerar separat på en container. Det finns bara en cgroup och det finns bara en del av kontrollen där. Hur kan du leva med detta? Eller om du vill ha prestanda, kör PostgreSQL på en separat hårdvaruserver och ställ in den?

Vi besvarade din fråga på ungefär tre sätt. Om vi ​​inte pratar om en hårdvaruserver som kan ställas in, etc., slappna av, allt kommer att fungera bra utan dessa inställningar. Om du har en sådan belastning att du behöver göra dessa inställningar, så kommer du till järnservern tidigare än till dessa inställningar.

Vad är problemet? Om detta är en virtuell maskin, kommer du troligen att ha många problem, till exempel med det faktum att på de flesta virtuella maskiner är diskens latens ganska inkonsekvent. Även om diskgenomströmningen är bra, då en misslyckad I/O-transaktion som inte i hög grad påverkar den genomsnittliga genomströmningen som skedde vid tidpunkten för kontrollpunkten eller i skrivande stund till WAL, då kommer databasen att lida mycket av detta. Och du kommer att märka detta innan du stöter på dessa problem.

Om du har NGINX på samma server kommer du också att ha samma problem. Han kommer att kämpa för delat minne. Och du kommer inte till problemen som beskrivs här.

Men å andra sidan kommer vissa av dessa parametrar fortfarande att vara relevanta för dig. Till exempel, ställ in dirty_ratio med sysctl så att det inte är så tokigt - i alla fall kommer detta att hjälpa. På ett eller annat sätt kommer du att ha interaktion med disken. Och det blir enligt fel mönster. Detta är i allmänhet en standard för parametrarna som jag visade. Och i alla fall är det bättre att ändra dem.

Men det kan finnas problem med NUMA. VmWare, till exempel, fungerar bra med NUMA med exakt motsatta inställningar. Och här måste du välja - en järnserver eller en icke-järnserver.

Jag har en fråga relaterad till Amazon AWS. De har bilder förkonfigurerade. En av dem heter Amazon RDS. Finns det några anpassade inställningar för deras operativsystem?

Det finns inställningar där, men det är olika inställningar. Här konfigurerar vi operativsystemet i termer av hur databasen kommer att använda denna sak. Och det finns parametrar som avgör vart vi ska gå nu, som att forma. Det vill säga, vi behöver så mycket resurser, vi kommer nu att äta upp dem. Efter detta drar Amazon RDS åt dessa resurser, och prestandan sjunker där. Det finns individuella historier om hur folk börjar bråka med den här saken. Ibland till och med ganska framgångsrikt. Men detta har inget med OS-inställningar att göra. Det är som att hacka molnet. Det är en annan historia.

Varför har Transparenta enorma sidor ingen effekt jämfört med Huge TLB?

Ge inte. Detta kan förklaras på många sätt. Men i själva verket ger de det helt enkelt inte. Vad är historien om PostgreSQL? Vid start allokerar den en stor bit delat minne. Om de är genomskinliga eller inte är helt irrelevant. Att de sticker ut i början förklarar allt. Och om det finns mycket minne och du behöver bygga om segmentet shared_memory, kommer Transparenta enorma sidor att vara relevanta. I PostgreSQL är det helt enkelt allokerat i en stor bit i början och det är det, och sedan händer inget speciellt där. Du kan naturligtvis använda det, men det finns en chans att få en korruption av shared_memory när den omfördelar något. PostgreSQL känner inte till detta.

Källa: will.com