Leistungsprüfung von Produktions-Workloads für Ingres und Vector

Eines der Hauptanliegen von Ingres- und Vector-Kunden, deren Systeme einer bedeutenden Veränderung unterzogen werden müssen, wie z. B. größeren Versions-Upgrades, Betriebssystem-Migrationen, größeren Software-Releases, erhöhtem Nutzungsvolumen usw., ist die Frage, wie die Datenbank unter realistischen Bedingungen in einer Testumgebung richtig getestet werden kann.

Einige Kunden haben bei Nutzer von dem von Actian Professional Services entwickelten Anfrage, Aufnahme- und Wiedergabewerkzeug (QRP) gehört. Das Tool zielt darauf ab, die Ingres- oder Vector-Datenbank unter produktionsnahen Bedingungen zu testen, indem ein Workload in einer Testumgebung aufgezeichnet und anschließend wiedergegeben wird. Der Rest dieses Beitrags beschreibt das Tool und seine Verwendung im Detail.

Anfrage Aufnahme

Der QRP-Teil " Anfrage Recording" verwendet den Tracepoint "SC930", der eine Aufzeichnung aller Abfragen erstellt, die während der Zeit, in der der Tracepoint eingeschaltet war, gegen die Datenbank ausgeführt wurden. Die Ausgabe von SC930 ist im Wesentlichen eine Reihe von Textdateien, die die Abfragen, Parameter, Datentypen, Daten usw. enthalten. - d.h. die Last, gegen die wir testen wollen. Die Verwendung des Tracepoints und die Einzelheiten des Ausgabeformats, das er erzeugt, werden hier näher beschrieben:

https://github.com/ActianCorp/Dynamic_Playback/wiki/Ingres-DBMS-Server-Query-Tracing

https://github.com/ActianCorp/Dynamic_Playback/wiki/SC930-Output-Page

Dieser Tracepoint - normalerweise eine undokumentierte Möglichkeit, das Verhalten von Ingres und Vector zu ändern - wird jetzt offiziell unterstützt und ist in den Produkthandbüchern dokumentiert. In den letzten Versionen wurde sogar eine zusätzliche Syntax hinzugefügt, um die Arbeit damit noch einfacher zu machen (suchen Sie in den Handbüchern nach "SET SERVER_TRACE"), so dass Sie ihn selbst für Anfrage verwenden können. Zum Beispiel können Sie jetzt die Anfrage nur für bestimmte Benutzer aktivieren, die Abfragen gegen eine bestimmte Datenbank ausführen, die länger als eine bestimmte Zeitspanne dauern, was die Verwendung für die Diagnose sehr erleichtert - siehe hier für weitere Details für Actian X und hier für Vector v5.

Die Verwendung des SC930-Trace-Punkts bedeutet, dass die Aufzeichnung der Anfrage auch mit älteren Versionen von Ingres und Vector funktioniert, die server_trace noch nicht unterstützen.

Anfrage Playback

Playback ist ein separates Set von Tools, das ursprünglich vom Professional Services Team bei Actian geschrieben wurde undhier im Actian Github Lager beschrieben wird (Binärversionen werden auch auf Github veröffentlicht, aber der Hauptquellcode wird hier im SVN gepflegt). Es wurde entwickelt, um jede Anfrage gegen Ihr Testsystem in der gleichen Reihenfolge und mit dem gleichen relativen Timing abzuspielen, in der sie aufgezeichnet wurde.

"Anfrage" bedeutet in diesem Zusammenhang jede SQL-Anweisung, die gegen die Ingres- oder Vector-Datenbank ausgeführt werden kann. Selbst wenn es sich bei der "Anfrage" um eine ungültige SQL-Anweisung handelt, versucht Playback, sie wiederzugeben, und wenn sie ungültig ist, schlägt sie genauso fehl, wie sie es bei der Aufzeichnung getan hätte.

Die Wiedergabe besteht im Wesentlichen aus 2 Kernstücken.

• Vorverarbeiten:
  • Preprocess formatiert die SC930-Ausgabedateien so um, dass sie in einzelne Sitzungen aufgeteilt sind und jede Sitzung, Verbindung und Anfrage nach einem Zeitstempel geordnet ist. Damit soll sichergestellt werden, dass jede Sitzung als separater Thread zum richtigen Zeitpunkt wiedergegeben werden kann, unabhängig davon, was in anderen Threads geschieht.
  • Preprocess ist in C# geschrieben und kann in MONO- oder .Net-Umgebungen ausgeführt werden.
  • Dieser Vorgang muss nur einmal pro Aufzeichnung durchgeführt werden.
  • Die Ausgabedateien können auf einem Server ausgeführt und an anderer Stelle wiedergegeben werden.
• Wiedergabe:
  • Ein einfacher Wiedergabeauftrag öffnet einzelne Dateien, die durch die Vorverarbeitung erzeugt wurden, und sendet für jede Sitzung einen eigenen Thread in derselben Reihenfolge und zum selben Zeitpunkt. Die Threads sollten dann alle Abfragen in dieser Datei in der gleichen Reihenfolge und zum gleichen Zeitpunkt ausführen.
  • Die Wiedergabe ist in C geschrieben und ruft standardmäßige Ingres eingebettet SQL-Bibliotheksfunktionen auf, was wohl der schnellste Weg ist, eine Anfrage an eine Ingres- oder Vector-Datenbank entweder lokal oder über ein Netzwerk zu übermitteln.
  • Dieser Vorgang kann beliebig oft wiederholt werden.

Die Wiedergabe kann helfen, die Folgen einer zusätzlichen Belastung des Systems, von Änderungen an der Hardware (z. B. Verringerung der Kerne oder des Arbeitsspeichers), einer Erhöhung des Datenvolumens oder der Anzahl der Benutzer zu testen, und es können auch Leistungs-Baselines ermittelt werden, um dann Upgrades oder Patches zu testen. So können wir beispielsweise die Wiedergabe mit doppelter Geschwindigkeit durchführen, um die Auswirkungen einer stärkeren Beanspruchung der Systemressourcen zu testen. Eine höhere Belastung kann Probleme mit dem System, der Anwendung, der Datenbankkonfiguration usw. aufdecken, so dass diese vor der Umstellung behoben werden können.

Überlegungen zur Wiedergabe

Ich habe vorhin gesagt, dass das Tool "produktionsnahe Bedingungen" nachbilden kann, da dies nie perfekt sein wird. Erstens können Hardware-Inkonsistenzen selbst auf Servern mit scheinbar identischen Spezifikationen zu Unterschieden führen. Außerdem kann auf die Datenbank auf verschiedene Weise und mit verschiedenen Sprachen zugegriffen werden, die jeweils ihre eigenen Macken haben. Es gibt auch einige interessante Aspekte in Bezug auf den Zeitpunkt der Übermittlung von Anfrage in einem umstrittenen Umfeld. Außerdem befindet sich die Anwendung oft auf einem oder mehreren separaten Servern oder Client-Rechnern, die auf verschiedene Weise über das Netz erreichbar sind.

Aus diesem Grund ist ein formales Benchmarking, das konsistent wiederholbare Ergebnisse liefert, nicht ganz einfach. Wir haben die Erfahrung gemacht, dass man beim mehrfachen Abspielen derselben Datendateien unterschiedliche Laufzeitergebnisse erhalten kann. Jede Sitzung sollte in der gleichen Reihenfolge wie die ursprüngliche Sitzung und im gleichen Abstand von der Gesamtstartzeit beginnen, und jede Anfrage sollte in der gleichen Reihenfolge wie die ursprüngliche Anfrage erfolgen und unter sonst gleichen Bedingungen im gleichen Abstand (zur Startzeit) beginnen.

Nach vielen Stunden Arbeit mit dem Tool sind wir der Meinung, dass selbst sehr kleine Änderungen, die oft außerhalb unserer Kontrolle liegen, einen erheblichen Einfluss auf die Gesamtlaufzeit haben können. Bereiche wie eine "langsame" oder fehlerhafte Festplatte, gemeinsam genutzte Ressourcen in einer VM-Umgebung, geringfügige Unterschiede bei den Speicher-/Kerngeschwindigkeiten usw. sind alles Faktoren. Denken Sie daran, dass die Wiedergabeabfragen bereits in 1/10 und 1/100 einer Sekunde auf leistungsstarken Rechnern laufen und manchmal 100+ Threads gleichzeitig ausgeführt werden können. Wenn eine Anfrage jemals nicht mit anderen Threads synchronisiert wird, kann dies zu unvorhersehbaren Ergebnissen führen, wie z. B. Abfragen, die auf leere Tabellen wirken (da die Anfrage ausgeführt wurde, bevor die Daten geladen wurden), oder lang laufende Abfragen, bei denen die Anfrage gestartet wurde, bevor die Optimierer-Statistiken generiert wurden. Actian empfiehlt, bei Leistungstests 3-4 Durchläufe durchzuführen und einen Durchschnitt zu ermitteln.

Die Wiedergabe verfügt auch über Funktionen zur Messung der Leistung einzelner Anfrage , der Zeilenzahl, der Sitzungen und der Anzahl der Abfragen. Die Leistungsstatistiken für Anfrage können natürlich dabei helfen, lang laufende Abfragen zu identifizieren, obwohl Sie sich aufgrund des vorherigen Absatzes nur auf Bereiche konzentrieren sollten, die über mehrere Sitzungen oder Wiederholungen hinweg immer wieder auftreten. Jeder Abspielauftrag erzeugt eine Reihe von CSV-Dateien, die in eine Tabellenkalkulation geladen werden können, um diese Informationen weiter aufzuschlüsseln.

Das Serviceteam von Actian hat das Tool bei einer ganzen Reihe von Kundenprojekten eingesetzt und damit sehr gute Ergebnisse erzielt. Ein aktuelles Beispiel ist der Einsatz bei einem Kunden, der ein Plattformmigrationsprojekt durchführte, um auf einen neuen und größeren Server umzusteigen. Hier konnten wir das QRP-Tool nutzen, um den neuen Server so zu konfigurieren, dass er die tatsächliche Workload besser unterstützt und somit eine viel reibungslosere Inbetriebnahme für die Benutzer ermöglicht, als es sonst möglich gewesen wäre, und eine bessere Erfahrung als bei früheren Upgrade-Projekten.

Zusammenfassend lässt sich sagen, dass QRP wirklich nützlich und recht einfach zu benutzen ist. Allerdings ist es ein von der Community geführtes Projekt und kein lizenziertes Produkt, so dass einige praktische Arbeit erforderlich ist (z. B. um es aus dem neuesten Quellcode zu erstellen), so dass Sie während der Einrichtung jemanden mit Entwicklungskenntnissen zur Hand haben sollten. Auf den Seiten der ActianCommunity gibt es einige gute Informationen dazu, z. B. zu den Voraussetzungen und der Verfügbarkeit der Plattform, die ich Ihnen empfehle, zu lesen, bevor Sie es versuchen.

Ausführliche Informationen zur Einrichtung und Verwendung von Playback finden Sie hier:

https://github.com/ActianCorp/Dynamic_Playback/wiki/Dynamic-Playback-set-up-and-usage-page

Natürlich sind neue Funktionen und Beiträge zur Fehlerbehebung aus unserer Community sehr willkommen! Viele Verbesserungen wären möglich, wie z.B. der Aufbau einer Nutzer zur Überwachung des Fortschritts - und ich bin mir sicher, dass sich andere Funktionen von selbst ergeben, wenn Sie sie nutzen.

Wenn Sie ausführliche Hilfe benötigen, wenden Sie sich an mich oder an einen Mitarbeiter von services@actian.com. Wir würden uns freuen, Sie beim Einstieg in das Tool oder bei der Durchführung eines Upgrade-Projekts mit dem Tool und damit bei der Erzielung eines reibungslosen und vorhersehbaren Ergebnisses unterstützen zu können.

Über Sean Paton

Sean Paton ist Delivery Manager für das britische Professional Services Team, wo er seit mehreren Jahren zahlreiche Plattformmigrationen und Upgrades betreut. Er hat über 20 Jahre Erfahrung in der Arbeit mit Ingres.