Im Anschluss an Tuning Linux for low PostgreSQL Latency vom letzten Monat wurde nun ein riesiger Haufen Tests an zwei Dateisystemen, drei Patches und zwei Sätzen von ausgeführten Kernel-Tuning-Parametern durchgeführt. Das bisherige Ergebnis sind einige interessante neue Daten und eine weitere engagierte Verbesserung in diesem Bereich, die jetzt in PostgreSQL 9.1 enthalten sind (insgesamt drei, die anderen beiden sind Überwachungspatches). Ich werde nächsten Monat während eines meiner Vorträge auf der PostgreSQL East über empfohlene Vorgehensweisen sprechen, und ich habe auch etwas in diesem Bereich für die PGCon im Mai eingereicht. Hier werde ich auch ein bisschen mehr über die Sackgassen sprechen, solange diese Erinnerungen noch frisch sind.
Das grundsätzliche Problem hierbei ist, dass durch die Art und Weise, wie PostgreSQL beim Schreiben den Cache des Betriebssystems verwendet, große Datenmengen anfallen können. Wenn Datenbankprüfpunkte beendet werden, kann es zu langen Verzögerungen beim Warten auf das Schreiben dieser Daten kommen. Es stellt sich heraus, dass das mit PostgreSQL gelieferte pgbench-Programm wirklich gut darin ist, dieses Problem zu erzeugen, also habe ich es für alle Tests verwendet. Die mittleren Fragen, die ich beantworten wollte, waren:
- Zeigt der Wechsel vom alten ext3-Dateisystem wirklich eine Leistungsverbesserung bei Datenbankaufgaben? Ich habe letztes Jahr etwas über die Rückkehr von XFS unter Linux geschrieben, das eine schöne Verbesserung gegenüber einfachen Benchmarks zeigte. Das führt jedoch nicht immer zu Datenbankverbesserungen.
- Verbessern die aktuellen Linux-Tunings dirty_bytes und dirty_background_bytes wirklich die Worst-Case-Latenz?
- Welche der Datenbankänderungen, die hier zur Verbesserung des Verhaltens vorgeschlagen wurden, funktionieren tatsächlich?
Sie können alle Testergebnisse sehen, wenn Sie sich die Rohdaten ansehen möchten. Was für jede Testreihe geändert wurde, wird dokumentiert, und wenn Sie einen einzelnen Test aufschlüsseln, können Sie die verwendeten Datenbankparameter und einige andere grundlegende Informationen zum Betriebssystem sehen. Diese Webseite ist das Ergebnis meines Pgbench-Tools-Testprogramms, falls Sie so etwas selbst ausprobieren möchten.
Die Ergebnisse waren nicht sehr überraschend, aber sie waren interessant. Alle Tests hier wurden mit zwei Datenbankgrößen durchgeführt. Bei einer kleineren Datenbankgröße (scale=500, etwa eine 8-GB-Datenbank, die problemlos in die 16 GB RAM des Servers passt) verwaltete ext3 690 Transaktionen/Sekunde, während es bei der doppelten Größe (scale=1000, etwa eine 16-GB-Datenbank) viel war mehr suchen gebunden und nur 349 TPS verwaltet. XFS erhöhte diese beiden Zahlen auf 1757 TPS und 417 TPS – ein Zuwachs von 255 % bzw. 19 %. Noch besser, die Worst-Case-Latenz für eine einzelne Transaktion sank von 34 bis 56 Sekunden (!) auf 2 bis 5 Sekunden. Während selbst 5 Sekunden nicht großartig sind, ist dies eine synthetische Arbeitsbelastung, die dieses Problem wirklich schlimm machen soll. Die ext3-Nummern sind so schrecklich, dass Sie hier wahrscheinlich immer noch auf ein böses Problem stoßen werden, obwohl ich tatsächlich ein besseres Verhalten auf diesem Dateisystem als in früheren Kerneln gesehen habe (dies wurde mit 2.6.32 gemacht).
Runde 1: XFS gewinnt mit einem Erdrutschsieg. Ich kann ext3 nicht als brauchbares Dateisystem auf Linux-Systemen mit viel Speicher empfehlen, wenn Sie vorhaben, viel zu schreiben; es funktioniert einfach nicht in diesem Zusammenhang. Dieser Server hatte nur 16 GB RAM, Sie können sich also vorstellen, wie schlimm dieses Problem auf einem seriösen Produktionsserver hier im Jahr 2011 ist.
Als nächstes kommen die Tunables dirty_bytes und dirty_background_bytes. Diese beiden verbesserten die Latenz auf ext3 erheblich, auf Kosten einiger Verlangsamungen. Das Schlimmste davon, die verlangsamte Wartungszeit beim Ausführen von VACUUM, sehen Sie nicht in den Testergebnissen selbst; Ich habe das bereits in meinem früheren Blogeintrag besprochen. Unter XFS ist das Absenken dieser Parameter eine Leistungskatastrophe. Bei der kleineren Datenbankgröße sinkt die TPS-Leistung um 46 %, und obendrein verschlechtert sich die Latenz tatsächlich.
Runde 2:Erwarten Sie keine Wunder von dirty_bytes oder dirty_background_bytes. Sie scheinen unter bestimmten Umständen einen positiven Effekt zu haben, aber die potenzielle Kehrseite ist auch groß. Stellen Sie sicher, dass Sie sorgfältig testen und VACUUM in Ihren Test einbeziehen, bevor Sie diese beiden nach unten anpassen.
Als nächstes habe ich im Rahmen dieses letzten CommitFests drei Patch-Ideen für PostgreSQL bewertet:
- Spread checkpoint sync to disk (fsync) Aufrufe im Laufe der Zeit. Wir hatten damit einige Erfolge auf einem ausgelasteten Client-Server in Kombination mit einer verbesserten Handhabung, wie andere Synchronisierungsvorgänge von der Datenbank zwischengespeichert wurden
- Kompakte fsync-Anfragen. Diese Idee hat sich aus der ersten entwickelt und wurde zu einem Patch, der von Robert Haas geschrieben wurde. Die Idee ist, dass Clients, die versuchen, Daten auf die Festplatte zu synchronisieren, mit dem Checkpoint-Schreiben konkurrieren könnten. Was der Patch bewirkt ist, dass Clients die Warteschlange von fsync-Anfragen bereinigen können, wenn sie jemals voll ist.
- Checkpoint-Schreibvorgänge sortieren. Das Konzept ist, dass das Betriebssystem möglicherweise effizienter schreibt, wenn Sie die Dinge in der Reihenfolge schreiben, in der die Datenbank glaubt, dass die Dinge auf der Festplatte gespeichert sind. Dieser Patch tauchte vor einigen Jahren mit einigen Benchmark-Ergebnissen auf, die darauf hindeuteten, dass er funktionierte, aber zu der Zeit war niemand in der Lage, die Verbesserungen zu replizieren. Die Idee passte so gut in den Rest der Arbeit, dass ich sie erneut evaluierte.
Runde 3: Nachdem all dies wochenlang ausprobiert wurde, war der einzige Ansatz aus diesem Set, der die Verbesserung bei fast allen Workload-Größen zeigte, die fsync-Komprimierung. Der ursprüngliche Spread-Checkpoint-Sync-Code hat in diesem Bereich etwas geholfen, aber die spezifische Implementierung, die jetzt für 9.1 festgeschrieben ist, hat noch besser funktioniert. Bei den meisten schreibintensiven Tests, die ich durchführte, war dies ein fast durchgängiger Gewinn von 10 %. Das ist eine große Verbesserung für PostgreSQL 9.1 und sollte ein Problem vollständig beseitigen, das unserer Erfahrung nach eine viel größere Verlangsamung der Produktionssysteme hier verursacht hat.
Der Rest der Ideen hier wurde nicht so positiv bewertet Benchmarking, also gehen diese vorerst zurück ins Regal. Ich werde hier weiterhin Daten sammeln – einige ext4-Tests sind die nächste logische Sache, die ich ausprobieren sollte – und dann wieder zur Entwicklung zurückkehren. Bei einigen schwierigen Workloads einen Gewinn von 10 % zu erzielen, ist sicherlich schön, aber es gibt hier immer noch viel zu viele Worst-Case-Verhaltensweisen, um Probleme mit der Checkpoint-Synchronisierung als abgeschlossenes Thema zu betrachten.
