Ich betreue eine Reihe von Projekten, deren Zweck es ist, das Testen von Teilen von PostgreSQL einfacher zu machen. All dies hat letzte Woche ein anständiges Upgrade erhalten.
Stream-Scaling testet, wie sich die Speichergeschwindigkeit auf Servern erhöht, wenn mehr Kerne ins Spiel gebracht werden. Es sind faszinierende Daten, genug davon, um einige echte Trends zu erkennen. Es funktioniert jetzt korrekt auf Systemen mit großen Mengen an CPU-Cache, da sie viele Kerne haben. Früher war es möglich, die Testmenge so aggressiv zu dimensionieren, um Cache-Auswirkungen zu vermeiden, dass mehr Speicher verbraucht wurde, als mit dem aktuellen Design des Stream-Codes zugewiesen werden konnte. Das wurde zurückgefahren. Wenn Sie einen 48-Core-Server oder größer haben, könnte ich diesen neuen Code noch etwas mehr testen, um zu sehen, ob die neue Art und Weise, wie ich damit umgehe, sinnvoll ist.
peg ist ein Skript, das ich geschrieben habe, um es einfacher zu machen, PostgreSQL aus dem Quellcode zu erstellen, typischerweise für Entwicklerarbeit oder um vorübergehend eine neuere Version auf einem Produktionssystem auszuprobieren. Früher war es sehr leicht, mit dem Wechsel zwischen Projekten und den zugehörigen Git-Zweigen durcheinander zu kommen; die Dokumentation in diesem Bereich wurde stark verbessert.
pgbench-tools ist mein Arbeitshaus für Leistungstests, das es Ihnen ermöglicht, Benchmark-Marken im Wert von Tagen in die Warteschlange zu stellen und dann genügend Analysetools zur Verfügung zu haben, um daraus einen Sinn zu machen. Das Programm verfolgt jetzt den kürzlich eingeführten Parameter pg_stat_bgwriter.buffers_backend_fsync, wenn Sie eine Version haben, die ihn unterstützt (derzeit nur ein neuerer Soure-Build – was uns wieder darauf zurückbringt, warum Peg nützlich ist). Sie können es auch anweisen, jeden Test für eine festgelegte Zeitspanne auszuführen, was das Testen bei stark variierenden Client-/Größenwerten viel einfacher macht.
Was Sie mit pgbench-tools machen können … ab heute teile ich jetzt die Benchmarking-Tests, die ich mit PostgreSQL 9.1 auf dem leistungsstärksten Server durchführe, den ich unbegrenzt nutzen kann. 8 Kerne, 16 GB RAM, 3 Festplatten-RAID-0-Datenbanklaufwerke, 1 Festplatten-WAL-Volume, batteriegepufferter Areca-Cache. Sie können die Ergebnisse sehen. Läufe sind in Testsets organisiert, von denen jedes eine Art Änderung an der Konfiguration darstellt. Beispielsweise führt Nr. 1 in diesen Daten nur SELECT aus, Nr. 2 führt TPC-B-ähnlich aus, jedoch mit 8 GB RAM und früherem Code, während das heiße Zeug Nr. 3 ist und TPC-B mit 16 GB RAM und Code ausführt verfolgt buffers_backend_fsyncs.
Es gibt mehrere Patches in der PostgreSQL 9.1-Warteschlange, die sich auf die Leistung in den durch diese Ergebnisse hervorgehobenen Bereichen beziehen – dass Linux im schlimmsten Fall eine extrem hohe Latenz bei schreibintensiven Datenbanklasten haben kann. Ein gutes durchschnittliches Beispiel ist Test 215:Skala von 1000, 32 Clients, 365 TPS. Aber die Latenz im schlimmsten Fall beträgt 43 Sekunden, und Sie können die toten Punkte im TPS-Diagramm sehen. Das ist einfach schrecklich, und es gibt ein paar Konzepte, wie man genau das tun kann.
Wenn jemand, der dies liest, einen leistungsstarken Server für ein paar Wochen zur Verfügung hat, um Tests wie diesen durchzuführen, helfe ich Ihnen gerne, diese Umgebung zu replizieren und zu sehen, welche Art von Ergebnissen Sie sehen. Die einzige Magie, die ich habe, ist etwas Übung darin, die Skalierung und die Clientlasten einzustellen, damit Sie nicht viel Zeit durch unproduktive Tests verlieren. Der Rest meines Prozesses ist kostenlos und dokumentiert.
