Efter at have fulgt op på sidste måneds Tuning Linux for lav PostgreSQL Latency, er der nu blevet udført en gigantisk bunke af tests på to filsystemer, tre patches og to sæt kernejusteringsparametre kørt. Resultatet indtil videre er nogle interessante nye data, og en mere engageret forbedring på dette område, som er i PostgreSQL 9.1 nu (hvilket gør tre i alt, de to andre er overvågningsrettelser). Jeg vil tale om anbefalet praksis i næste måned under en af mine foredrag på PostgreSQL East, og jeg har også indsendt noget på dette område til majs PGCon. Her vil jeg også tale lidt mere om blindgyderne, mens disse minder stadig er friske.
Det grundlæggende problem her er, at måden PostgreSQL bruger operativsystemets cache, når de skriver, tillader store mængder data at akkumulere. Resultatet, når databasekontrolpunkter afsluttes, kan være lange forsinkelser, mens man venter på, at dataene bliver skrevet. Det viser sig, at pgbench-programmet, der følger med PostgreSQL, er rigtig godt til at skabe dette problem, så det er det, jeg brugte til alle testene. De midler, jeg satte mig for at besvare, var:
- Viser ændring fra det gamle ext3-filsystem virkelig en ydeevneforbedring på databaseopgaver? Jeg skrev noget om Return of XFS på Linux sidste år, der viste en pæn forbedring af simple benchmarks. Det betyder dog ikke altid databaseforbedringer.
- Forbedrer de seneste Linux dirty_bytes og dirty_background_bytes tunables virkelig worst case latency?
- Hvilke af de databaseændringer, der er foreslået for at forbedre adfærd her, virker faktisk?
Du kan se alle testresultaterne, hvis du vil tjekke de rå data ud. Hvad der blev ændret for hvert testsæt, er dokumenteret, og hvis du borer ned i en individuel test, kan du se de anvendte databaseparametre og nogle andre grundlæggende OS-oplysninger. Den webside er det, der kommer ud af mit pgbench-tools testprogram, hvis du selv vil prøve denne slags ting.
Resultaterne var ikke særlig overraskende, men de var interessante. Alle testene her blev udført med to databasestørrelser. Ved en mindre databasestørrelse (skala=500, ca. en 8GB database, der nemt passer ind i serverens 16GB RAM), klarede ext3 690 transaktioner/sekund, mens det ved dobbelt så stor størrelse (skala=1000, ca. en 16GB database) var meget mere søge bundet og kun forvaltede 349 TPS. XFS øgede disse to tal til 1757 TPS og 417 TPS – en stigning på henholdsvis 255 % og 19 %. Endnu bedre, den værste forsinkelse for en enkelt transaktion faldt fra intervallet 34 til 56 sekunder (!) til 2 til 5 sekunders. Selvom selv 5 sekunder ikke er fantastisk, er dette en syntetisk arbejdsbyrde designet til at gøre dette problem virkelig slemt. Ext3-numrene er så forfærdelige, at det stadig er sandsynligt, at du løber ind i et grimt problem her, selvom jeg faktisk så en bedre opførsel på det filsystem, end jeg har set i tidligere kerner (dette blev gjort med 2.6.32).
Runde 1:XFS vinder i et jordskredsløb. Jeg kan ikke anbefale ext3 som et levedygtigt filsystem på Linux-systemer med masser af hukommelse, hvis du planlægger at skrive meget; det virker bare ikke i den sammenhæng. Denne server havde kun 16 GB RAM, så du kan forestille dig, hvor slemt dette problem er på en seriøs produktionsserver her i 2011.
Næste op, dirty_bytes og dirty_background_bytes tunables. Disse to forbedrede latensen en del på ext3 på bekostning af nogle opbremsninger. Det værste af dem, langsommere vedligeholdelsestid med VACUUM, kan du ikke se i selve testresultaterne; Det har jeg allerede diskuteret i mit tidligere blogindlæg. På XFS er nedjustering af disse parametre en ydeevnekatastrofe. I den mindre databaseskala falder TPS-ydeevnen 46 %, og oven i købet bliver latenstiden faktisk værre.
Runde 2: Forvent ikke mirakler fra dirty_bytes eller dirty_background_bytes. De ser ud til at have en positiv effekt under nogle omstændigheder, men den potentielle ulempe er også stor. Sørg for at teste omhyggeligt, og inkludere VACUUM i din test, før du justerer disse to nedad.
Dernæst endte jeg med at evaluere tre patch-ideer til PostgreSQL som en del af denne sidste CommitFest:
- Spred checkpoint-synkronisering til disk (fsync) kalder ud over tid. Vi havde set en vis succes med det på en travl klientserver kombineret med en forbedret håndtering af, hvordan andre synkroniseringsoperationer blev cachelagret af databasen
- Kompakte fsync-anmodninger. Denne idé udsprang af den første og blev til et plaster skrevet af Robert Haas. Ideen er, at klienter, der forsøger at synkronisere data til disk, kan konkurrere med checkpoint-skrivningen. Hvad patchen gør, er at tillade klienter at rydde op i køen af fsync-anmodninger, hvis de nogensinde finder den fuld.
- Sorter checkpoint skriver. Konceptet er, at hvis du skriver ting ud i den rækkefølge, databasen mener, at tingene er gemt på disken, kan operativsystemet skrive mere effektivt. Denne patch dukkede op for et par år siden med nogle benchmark-resultater, der tyder på, at den virkede, men på det tidspunkt var ingen i stand til at replikere forbedringerne. Idéen passede godt nok ind i resten af arbejdet til, at jeg evaluerede den igen.
Runde 3: Efter ugers afprøvning af alt dette, var den eneste tilgang i dette sæt, der viste forbedringen ved næsten alle arbejdsbelastningsstørrelser, fsync-komprimering. Den originale spread checkpoint-synkroniseringskode hjalp noget på dette område, men den specifikke implementering, der nu er forpligtet til 9.1, fungerede endnu bedre. Det var en næsten overordnet gevinst på 10 % på de fleste af de skrivetunge test, jeg kørte. Det er en stor forbedring for PostgreSQL 9.1, og det burde fuldstændig eliminere et problem, som vi har set forårsage en meget større opbremsning af produktionssystemerne her.
Resten af ideerne her fik ikke så positiv en evaluering efter tunge benchmarking, så for nu går de tilbage på hylden. Jeg fortsætter med at samle data her – nogle ext4-tests er den næste logiske ting at prøve – og så vende tilbage til udvikling igen. At få en gevinst på 10 % på nogle vanskelige arbejdsbelastninger er bestemt rart, men der er stadig alt for mange worst-case-adfærd her til at betragte checkpoint-synkroniseringsproblemer som et lukket emne.