Efter uppföljningen av förra månadens Tuning Linux för låg PostgreSQL Latency, har det nu gjorts en gigantisk hög med tester på två filsystem, tre patchar och två uppsättningar av kärnavstämningsparametrar. Resultatet hittills är några intressanta nya data, och ytterligare en engagerad förbättring inom detta område som finns i PostgreSQL 9.1 nu (gör totalt tre, de andra två är övervakningspatchar). Jag kommer att prata om rekommenderad praxis nästa månad under ett av mina föredrag på PostgreSQL East, och jag har också skickat in något på detta område för majs PGCon. Här ska jag prata lite mer om återvändsgränderna också, medan dessa minnen fortfarande är färska.
Det grundläggande problemet här är att sättet som PostgreSQL använder operativsystemets cache när man skriver gör att stora mängder data kan ackumuleras. Resultatet när databaskontrollpunkter slutförs kan bli långa förseningar medan man väntar på att data ska skrivas. Det visar sig att pgbench-programmet som följer med PostgreSQL är riktigt bra på att skapa det här problemet, så det är vad jag använde för alla tester. Frågorna som jag försökte svara på var:
- Visar förändringar från det gamla ext3-filsystemet verkligen en prestandaförbättring för databasuppgifter? Jag skrev något om Return of XFS på Linux förra året som visade en fin förbättring av enkla riktmärken. Det leder dock inte alltid till databasförbättringar.
- Förbättrar de senaste Linux dirty_bytes och dirty_background_bytes tunables verkligen värsta tänkbara latens?
- Vilka av de databasändringar som föreslås för att förbättra beteendet här fungerar faktiskt?
Du kan se alla testresultat om du vill kolla in rådata. Vad som ändrades för varje testset dokumenteras, och om du borrar ner i ett individuellt test kan du se databasparametrarna som används och lite annan grundläggande OS-information. Den webbsidan är det som kommer ut ur mitt testprogram pgbench-tools, om du vill prova den här typen av saker själv.
Resultaten var inte särskilt överraskande, men de var intressanta. Alla tester här gjordes med två databasstorlekar. Vid en mindre databasstorlek (skala=500, ungefär en databas på 8 GB som enkelt fick plats i serverns 16 GB RAM) klarade ext3 690 transaktioner/sekund, medan det vid dubbelt så stor storlek (skala=1000, ungefär en 16 GB databas) var mycket fler söker bundna och klarade endast 349 TPS. XFS ökade dessa två siffror till 1757 TPS och 417 TPS – en ökning på 255 % respektive 19 %. Ännu bättre, den värsta latensen för en enskild transaktion sjönk från intervallet 34 till 56 sekunder (!) till intervallet 2 till 5 sekunder. Även om inte ens 5 sekunder är bra, är detta en syntetisk arbetsbelastning utformad för att göra det här problemet riktigt illa. Ext3-numren är så fruktansvärda att du fortfarande sannolikt stöter på ett otäckt problem här, även om jag faktiskt såg bättre beteende på det filsystemet än jag har sett i tidigare kärnor (detta gjordes med 2.6.32).
Omgång 1:XFS vinner i ett jordskred. Jag kan inte rekommendera ext3 som ett gångbart filsystem på Linux-system med mycket minne om du planerar att skriva mycket; det fungerar helt enkelt inte i det sammanhanget. Den här servern hade bara 16 GB RAM, så du kan föreställa dig hur illa det här problemet är på en seriös produktionsserver här 2011.
Nästa upp, dirty_bytes och dirty_background_bytes tunables. Dessa två förbättrade latensen ganska mycket på ext3, på bekostnad av vissa nedgångar. Det värsta av dem, långsam underhållstid med VACUUM, ser du inte i själva testresultaten; Jag har redan diskuterat det i mitt tidigare blogginlägg. På XFS är det en prestandakatastrof att justera ned dessa parametrar. I den mindre databasskalan sjunker TPS-prestanda med 46 %, och utöver det blir latensen faktiskt sämre.
Omgång 2: Förvänta dig inga mirakel från dirty_bytes eller dirty_background_bytes. De verkar ha en positiv effekt under vissa omständigheter, men den potentiella nackdelen är också stor. Se till att testa noggrant och inkludera VAKUUM i dina tester innan du justerar dessa två nedåt.
Därefter slutade jag med att utvärdera tre patchidéer till PostgreSQL som en del av den här senaste CommitFest:
- Sprid kontrollpunktsynk till disk (fsync) anrop över tiden. Vi hade sett en viss framgång med det på en upptagen klientserver i kombination med en förbättrad hantering av hur andra synkroniseringsoperationer cachades av databasen
- Kompakta fsync-förfrågningar. Den här idén spred sig från den första och förvandlades till en lapp skriven av Robert Haas. Tanken är att klienter som försöker synkronisera data till disk kan konkurrera med kontrollpunktsskrivningen. Vad patchen gör är att tillåta klienter att rensa upp i kön med fsync-förfrågningar om de någonsin finner den full.
- Sortera checkpoint skriver. Konceptet är att om du skriver ut saker i den ordning som databasen tror att sakerna är lagrade på disken, kan operativsystemet skriva mer effektivt. Den här patchen dök upp för några år sedan med några benchmarkresultat som tydde på att det fungerade, men vid den tidpunkten kunde ingen replikera förbättringarna. Idén passade in i resten av arbetet så pass bra att jag utvärderade det igen.
Omgång 3: Efter veckor av att ha provat allt detta, var det enda tillvägagångssättet ur denna uppsättning som visade förbättringen vid nästan alla arbetsbelastningsstorlekar fsync-komprimeringen. Den ursprungliga synkroniseringskoden för spridning av kontrollpunkter hjälpte en del på detta område, men den specifika implementeringen som nu är fastställd för 9.1 fungerade ännu bättre. Det var en vinst på nästan 10 % på de flesta av de skrivtunga testerna jag körde. Det är en stor förbättring för PostgreSQL 9.1, och det borde helt eliminera ett problem som vi har sett orsaka en mycket större nedgång i produktionssystemen här.
Resten av idéerna här fick inte en så positiv utvärdering efter tunga benchmarking, så för nu går de tillbaka på hyllan. Jag kommer att fortsätta att samla in data här – vissa ext4-tester är nästa logiska sak att försöka – och sedan återgå till utvecklingen igen. Att få en vinst på 10 % på vissa svåra arbetsbelastningar är verkligen trevligt, men det finns fortfarande alldeles för många värsta tänkbara beteenden här för att kunna betrakta problem med synkronisering av kontrollpunkter som ett slutet ämne.