In navolging van de Tuning Linux van vorige maand voor lage PostgreSQL-latentie, is er nu een gigantische stapel tests uitgevoerd op twee bestandssystemen, drie patches en twee sets kernelafstemmingsparameters. Het resultaat tot nu toe is een aantal interessante nieuwe gegevens en nog een toegewijde verbetering op dit gebied die nu in PostgreSQL 9.1 zit (waardoor er drie in totaal zijn, de andere twee zijn monitoring-patches). Ik zal het volgende maand hebben over aanbevolen praktijken tijdens een van mijn lezingen op PostgreSQL East, en ik heb ook iets op dit gebied ingediend voor de PGCon van mei. Hier zal ik ook wat meer vertellen over de doodlopende wegen, terwijl die herinneringen nog vers zijn.
Het fundamentele probleem hier is dat door de manier waarop PostgreSQL de cache van het besturingssysteem gebruikt bij het schrijven, grote hoeveelheden gegevens zich kunnen ophopen. Het resultaat wanneer databasecontrolepunten zijn voltooid, kan lange vertragingen zijn tijdens het wachten tot die gegevens zijn geschreven. Het blijkt dat het pgbench-programma dat bij PostgreSQL wordt geleverd, echt goed is in het creëren van dit probleem, dus dat heb ik voor alle tests gebruikt. De gemiddelde vragen die ik wilde beantwoorden waren:
- Laat het veranderen van het oude ext3-bestandssysteem echt een prestatieverbetering zien op databasetaken? Ik schreef vorig jaar iets over de Return of XFS op Linux dat een mooie verbetering liet zien op eenvoudige benchmarks. Dat vertaalt zich echter niet altijd in databaseverbeteringen.
- Verbeteren de recente Linux dirty_bytes en dirty_background_bytes tunables echt de latentie in het slechtste geval?
- Welke van de voorgestelde databasewijzigingen om het gedrag hier te verbeteren, werken echt?
U kunt alle testresultaten zien als u de onbewerkte gegevens wilt bekijken. Wat er voor elke testset is gewijzigd, is gedocumenteerd, en als u inzoomt op een individuele test, kunt u de gebruikte databaseparameters en enkele andere basisinformatie over het besturingssysteem zien. Die webpagina is wat er uit mijn pgbench-tools-testprogramma komt, als je dit soort dingen zelf wilt proberen.
De resultaten waren niet erg verrassend, maar ze waren interessant. Alle tests hier zijn gedaan met twee databasegroottes. Bij een kleinere databasegrootte (schaal=500, ongeveer een 8GB database die gemakkelijk in de 16GB RAM van de server past), beheerde ext3 690 transacties/seconde, terwijl het bij twee keer die grootte (schaal=1000, ongeveer 16GB database) veel was meer zoeken gebonden en slechts beheerd 349 TPS. XFS verhoogde die twee cijfers tot 1757 TPS en 417 TPS, een winst van respectievelijk 255% en 19%. Sterker nog, de latentie in het slechtste geval voor een enkele transactie daalde van het bereik van 34 tot 56 seconden (!) Naar het bereik van 2 tot 5 seconden. Hoewel zelfs 5 seconden niet geweldig is, is dit een synthetische werklast die is ontworpen om dit probleem echt erg te maken. De ext3-nummers zijn zo verschrikkelijk dat je nog steeds echt een vervelend probleem tegenkomt, ook al zag ik eigenlijk beter gedrag op dat bestandssysteem dan ik in eerdere kernels heb gezien (dit werd gedaan met 2.6.32).
Ronde 1: XFS wint in een aardverschuiving. Ik kan ext3 niet aanbevelen als een levensvatbaar bestandssysteem op Linux-systemen met veel geheugen als je van plan bent veel te schrijven; het werkt gewoon niet in die context. Deze server had slechts 16 GB RAM, dus je kunt je voorstellen hoe erg dit probleem is op een serieuze productieserver hier in 2011.
Vervolgens de tunables dirty_bytes en dirty_background_bytes. Deze twee verbeterden de latentie behoorlijk op ext3, ten koste van enkele vertragingen. Het ergste van die, vertraagde onderhoudstijd met VACUUM, zie je niet in de testresultaten zelf; Dat besprak ik al in mijn eerdere blogbericht. Op XFS is het verlagen van deze parameters een prestatieramp. Op de kleinere databaseschaal dalen de TPS-prestaties met 46%, en bovendien wordt de latentie zelfs erger.
Ronde 2:Verwacht geen wonderen van dirty_bytes of dirty_background_bytes. Ze lijken in sommige omstandigheden een positief effect te hebben, maar het potentiële nadeel is ook groot. Zorg ervoor dat u zorgvuldig test en VACUUMM in uw tests opneemt voordat u deze twee naar beneden bijstelt.
Vervolgens heb ik uiteindelijk drie patch-ideeën voor PostgreSQL geëvalueerd als onderdeel van deze laatste CommitFest:
- Verspreid checkpoint-synchronisatie naar schijf (fsync)-aanroepen in de loop van de tijd. We hadden daar enig succes mee gezien op een drukke clientserver in combinatie met een verbeterde afhandeling van hoe andere synchronisatiebewerkingen door de database in de cache werden opgeslagen
- Compacte fsync-verzoeken. Dit idee kwam voort uit het eerste en veranderde in een patch geschreven door Robert Haas. Het idee is dat clients die gegevens naar schijf proberen te synchroniseren, kunnen concurreren met het schrijven van checkpoints. Wat de patch doet, is dat klanten de wachtrij met fsync-verzoeken kunnen opschonen als ze deze ooit vol vinden.
- Sorteer schrijfacties voor checkpoints. Het concept is dat als je dingen uitschrijft in de volgorde waarin de database denkt dat ze op schijf zijn opgeslagen, het besturingssysteem efficiënter kan schrijven. Deze patch verscheen een paar jaar geleden met enkele benchmarkresultaten die suggereerden dat het werkte, maar op dat moment was niemand in staat om de verbeteringen te repliceren. Het idee paste goed genoeg bij de rest van het werk dat ik het opnieuw heb geëvalueerd.
Ronde 3: Na weken van dit alles uitgeprobeerd te hebben, was de enige benadering van deze set die de verbetering liet zien bij bijna alle werklastgroottes de fsync-verdichtingsmethode. De originele spread checkpoint sync-code hielp op dit gebied wat, maar de specifieke implementatie die nu is vastgelegd voor 9.1 werkte nog beter. Het was bijna over de hele linie 10% winst op de meeste schrijfzware tests die ik heb uitgevoerd. Dat is een grote verbetering voor PostgreSQL 9.1, en het zou een probleem volledig moeten elimineren waarvan we hebben gezien dat het een veel grotere vertraging van productiesystemen hier veroorzaakte.
De rest van de ideeën hier kregen niet zo'n positieve evaluatie na zware benchmarking, dus die gaan voorlopig weer op de plank. Ik zal hier doorgaan met het verzamelen van gegevens - sommige ext4-tests zijn de volgende logische stap om te proberen - en ga dan weer verder met ontwikkelen. 10% winst behalen op een aantal moeilijke workloads is zeker leuk, maar er zijn hier nog steeds veel te veel worstcasegedragingen om problemen met checkpointsynchronisatie als een gesloten onderwerp te beschouwen.