Heute ist die Frist für den speziellen Zimmerpreis in dem Hotel, das diesen Monat die PostgreSQL Conference East 2010 veranstaltet
Mein Vortrag befasst sich mit Datenbankhardware-Benchmarking und ist für den späten Nachmittag des ersten Tages, Donnerstag, den 25. März, angesetzt. Diejenigen, die diesen Vortrag vielleicht schon einmal gesehen haben, entweder live auf der PGCon 2009 oder über den dort verfügbaren Videolink, fragen sich vielleicht, ob ich die gleichen Folien hervorziehe und noch einmal spreche. Nicht der Fall; Während die allgemeine Philosophie des Vortrags („Vertraue niemandem, führe deine eigenen Benchmarks durch“) dieselbe bleibt, wurden die vorgeschlagenen Beispiele und der Testmix aktualisiert, um ein weiteres Jahr Hardware-Fortschritte, PostgreSQL-Arbeit und meine eigene Forschung während dieser Zeit widerzuspiegeln Zeit. Insbesondere die Situation zwischen Intel und AMD hat sich ziemlich verändert, was eine neue Reihe von Speicher-Benchmarks erfordert, um wirklich zu verfolgen, was jetzt vor sich geht.
Und PostgreSQL 9.0 hat ein großes Problem behoben, das es aufgrund einer Kernel-Regression, die eine ohnehin schon viel zu häufige Situation noch verschlimmerte, daran hinderte, normalerweise genaue Ergebnisse unter Linux zu liefern:Ein einzelner pgbench-Client kann eher zum Engpass werden, wenn er ausgeführt wird als die Datenbank selbst. Die Überprüfung, die ich für pgbench mit mehreren Threads durchgeführt habe (was auf Systemen, die keine Threads unterstützen, auch pgbench mit mehreren Prozessen sein kann), deutete auf eine solide Beschleunigung von> 30 % hin, selbst auf Systemen, die nicht über die schlechte Kernel-Inkompatibilität verfügten. Nachfolgende Tests deuten darauf hin, dass es leicht 8 pgbench-Prozesse dauern kann, um den vollen Durchsatz selbst aus kostengünstigen modernen Prozessoren unter neueren Linux-Kerneln herauszuholen. Ich werde genau erläutern, wie sich das auf solchen Systemen auswirkt und wie diese neue Funktion es wieder möglich macht, pgbench als primäre Methode zum Messen der CPU-Leistung beim Ausführen der Datenbank zu verwenden.
Kürzlich habe ich auch das Git-Repo für pgbench-tools aktualisiert, das funktionierende Unterstützung für PostgreSQL 8.4 und grundlegende 9.0-Kompatibilität hinzufügt, und das nächste Update wird Unterstützung für die Multithread-Option enthalten, jetzt, wo ich herausgefunden habe, wie das geht muss arbeiten. Das alles führt irgendwo hin. Sobald wir genaue Messungen für die postgreSQL-Leistung haben, die auf der Serverseite CPU-begrenzt sind, was seit über zwei Jahren nicht mehr oft der Fall war, werden diese wieder zu einer nützlichen Methode, um Leistungsregressionen in der PostgreSQL-Codebasis zu überwachen. Die enthaltenen Tests müssen erweitert werden, um schließlich mehr abzudecken, aber jetzt haben wir einen Punkt erreicht, an dem pgbench verwendet werden kann, um Regressionen zu finden, die sich darauf auswirken, wie schnell einfache SELECT-Anweisungen ausgeführt werden. Ich weiß, dass das wie erwartet funktioniert, denn jedes Mal, wenn ich versehentlich PostgreSQL mit Behauptungen baue, wird das abgefangen, weil ich sehe, dass die durchschnittliche Verarbeitungsrate dramatisch abfällt.
Sobald ich hier ein paar Systeme eingerichtet habe, um auf solche Regressionen zu testen, stellt sich die Frage, wie ich das automatisieren kann, was ich tue, und dann das Gleiche mit einer breiteren Palette von Build-Checkouts zu tun. Im Idealfall könnten Sie jeden Tag ein Diagramm der durchschnittlichen SELECT-Leistung sehen, aufgeschlüsselt nach Version, so dass bei der Einführung eines Commit, das es reduziert, sofort ersichtlich wäre, wann die Leistung gesunken ist. Dies ist das Traumziel für den Aufbau einer Performance-Farm ähnlich der PostgreSQL-Buildfarm. Die Teile sind jetzt fast alle zusammen: meine Pgbench-Teile werden eingepackt, Erweiterungen der Buildfarm, damit sie direkt mit Git spricht, schreiten voran (keine Voraussetzung, aber niemand, der an diesem Projekt arbeitet, möchte CVS verwenden, wenn wir es vermeiden können). , und das Wichtigste, was an dieser Stelle fehlt, ist jemand, der sich die Zeit nimmt, das, was ich mache, in einen buildfarm-ähnlichen Client zu integrieren.
Und es sieht so aus, als hätten wir jetzt einen Unternehmenssponsor, der bereit ist, bei diesem Teil der Arbeit zu helfen, den ich anerkennen werde, wenn wir alle fertig sind, und das soll diesen Sommer geschehen. Ich gehe davon aus, dass die Entwicklung von PostgreSQL 9.1 und das Backpatching von 9.0 mit einer frühen Performance-Farm erfolgen werden, um Leistungsregressionen zu vermeiden. Wenn wir die neue Multithread-pgbench auf ältere PostgreSQL-Versionen zurückportieren können, werden wir sie möglicherweise ebenfalls in den Mix aufnehmen. Ich habe bereits eine Rückportierung der 8.3-pgbench, die viele Verbesserungen enthält, die ich nur zum Testen von 8.2-Systemen pflege. Mit pgbench als ziemlich eigenständiges Contrib-Modul ist es möglich, ein späteres Modul zu erstellen, das sich vom Rest des Systems unterscheidet, solange es nicht erwartet, dass auch neuere Datenbankfunktionen vorhanden sind.
Wenn Sie daran interessiert sind, wird mein Vortrag auf der Konferenz die Grundlagen skizzieren, auf denen ich erwarte, dass sie aufgebaut werden. Ich hoffe trotzdem, dass Sie es zur Konferenz schaffen und sich an der langen Liste der dort präsentierten Vorträge erfreuen können.
