Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"
Disclaimer: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов PostgreSQL вышло и 15 версий ядра Linux. Если переписывать эти места, то получится в итоге другой доклад. Но здесь рассмотрен фундаментальный тюнинг Linux для PostgreSQL, который актуален и сейчас.
Меня зовут Илья Космодемьянский. Я работаю в компании PostgreSQL-Consulting. И сейчас буду рассказывать немножко про то, что делать с Linux применительно к базам данных вообще и к PostgreSQL в частности, потому что принципы довольно схожие.
О чем пойдет речь? Если вы общаетесь с PostgreSQL, то до какой-то степени нужно быть UNIX’овым админом. Что это значит? Если мы сравним Oracle и PostgreSQL, то в Oracle надо быть на 80 % DBA админом базы данных и на 20 % админом Linux.
С PostgreSQL немножко посложнее. С PostgreSQL надо сильно лучше представлять себе, как работает Linux. И при этом немножко бежать вслед за паровозом, потому что в последнее время довольно здорово все апдейтится. И новые ядра выходят, и новый функционал появляется, перфоманс улучшается и т. д.
Почему мы говорим про Linux? Совсем не по тому, что мы на конференции Linux Питер, а потому что в современных условиях одна из самых оправданных ОС для эксплуатации с базами данных вообще и с PostgreSQL в частности – это Linux. Потому что FreeBSD, к сожалению, развивается в каком-то очень странном направлении. И будут проблемы как с производительностью, так и с многими другими вещами. Производительность PostgreSQL на Windows – это вообще отдельная суровая тема, упирающая в то, что у Windows нет такой шаредной памяти как у UNIX, а у PostgreSQL все на это дело завязано, потому что многопроцессная система.
Och jag tror att alla är mindre intresserade av exotiska saker som Solaris, så låt oss gå.
У современного дистрибутива Linux более 1 000 параметров syctl, в зависимости от того, как собрать ядро. При этом, если мы посмотрим еще на разные гайки, то там можно еще многими способами что-нибудь поднастраивать. Есть параметры файловых систем, как монтировать. Если вопросы, как запустить: что в BIOS включить, как железки настроить и т. д.
Это очень большой объем, о котором можно рассказывать несколько дней, а не за один короткий доклад, но я сейчас остановлюсь на важных вещах, как избежать тех граблей, которые с гарантией не дадут вам хорошо эксплуатировать базу данных на Linux, если вы их не поправите. И при этом важный такой момент, что многие параметры по дефолту включены не в такие настройки, которые правильны для базы данных. Т. е. по умолчанию работать будет плохо или работать не будет вообще.
Какие традиционные tuning targets есть в Linux? Я думаю, что поскольку вы все имеете дело с администрированием Linux, то что такое targets объяснять особо не надо.
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.
В принципе, до некоторой степени с PostgreSQL точно такая же ситуация. Разница заключается в том, что база еще и не все ресурсы сама умеет себе забирать, т. е. где-то нужно на уровне Linux это все разруливать самостоятельно.
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.
Вот такая картинка для пояснения того, что это такое. Есть буфер ОС Linux и есть шаредная память и есть шаредные буфера PostgreSQL. PostgreSQL в отличие от Oracle работает непосредственно только через буфер ядра, т. е. чтобы страничка с диска попала в его шаредную память, она должна пройти через kernel buffer и обратно точно такая же ситуация.
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-minne server Och om allt detta hamnar på en SATA-hårddisk utan cache, förvandlas hela databasservern inte bara till en pumpa, utan en pumpa med ett SATA-gränssnitt. Du kommer att sitta fast där. 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.
Поэтому более правильный вариант для базы данных, чтобы операционная система Linux вообще не знала, что там происходит. Чтобы она обращалась к памяти как обращается.
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.
Два – чем больше разрастается кэш в такой ситуации, тем больше вероятность того, что у вас будет cache misses. И эффективность этого кэша стремительно падает с ростом его размера. Поэтому в операционных системах придумали простой подход. В Linux он давно уже используется. В FreeBSD не так давно появился. Но мы говорим о Linux. Это huge pages.
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.
Если on, то он просто не стартует, если не смог выделить из huge pages. Тут уже – кому и что более мило. Но если у вас стоит try, то проверяйте, что у вас действительно то, что нужно выделилось, потому что пространств для ошибки там много. Сейчас этот функционал работает только на 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.
И это будет очень неприятно в ряде моментов. И основная неприятность заключается в том, что в современных ядрах немножко разнится поведение с более старыми ядрами Linux. И эта вещь, на которую наступать довольно неприятно, потому что, когда мы говорим о какой-то работе с swap’ом, заканчивается это не своевременным приходом OOM-killer. И OOM-killer, который не своевременно пришел и скинул PostgreSQL, это неприятно. Об этом узнают все, т. е. до последнего пользователя.
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.
Если посмотреть с точки зрения Linux, если вы взяли хороший hardware, правильно его настроили, нормально настроили PostgreSQL, чтобы он пореже делал эти checkpoints, размазывал их по времени друг между другом, то вы наступаете в дефолтные параметры Debian. Для большинства дистрибутивов Linux вот такая картина: 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.
И как они портят жизнь? Что такое sched_migration_cost? У Linux scheduler может смигрировать процесс с одного CPU на другой. И для PostgreSQL, который выполняет запросы, миграция на другой CPU совершенно не понятна зачем. С точки зрения операционной системы, когда вы переключаете окна между openoffice и терминалом, то это, может быть, хорошо, но 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.
И напоследок про power saving policy. Хорошо, что теперь Linux можно использовать на ноутбуке. И он будет якобы хорошо расходовать батарейку. Но внезапно оказывается, что на сервере такое тоже может быть.
Dessutom, om du hyr servrar från någon webbhotellleverantör, så är det "bra" värdar De bryr sig inte om din prestanda. Deras jobb är att se till att deras hårdvara används så effektivt som möjligt. Det är därför de kan aktivera ett bärbar datorliknande energisparläge i operativsystemet som standard.
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
