In den vorangegangenen PostgreSQL-Beiträgen haben wir über die Erweiterung „pg_profile“ und das Tool „pgBadger“ gesprochen. Beides sind ausgesprochen „wertvolle“ Tools, um der Performance einer Datenbank auf den Grund zu gehen, bzw. um Probleme zu analysieren. Heute schauen wir uns die von Percona entwickelte Extension „pg_stat_monitor“ an. Der Ansatz, dieser von Percona entwickelten und gepflegten Erweiterung ist es, einen ganzheitlichen Überblick bei der Bewertung von SQL-Queries zu geben. Dies geschieht mittels einer einzigen View („pg_stat_monitor“). Die Funktionalität ist auf den ersten Blick ähnlich der vielfach bekannten Extension „pg_stat_statements“. Im Detail gibt es jedoch einige Unterschiede und / oder Verbesserungen. Wir wollen die Erweiterung an dieser Stelle kurz mit ihren wesentlichen Eigenschaften vorstellen.

Die Installation, das kleine 1 x 1

Die Installation der Extension ist nicht kompliziert. Zunächst binden wir das Percona Software Repository auf unserem Testserver ein, um das entsprechende Paket mit der Erweiterung installieren zu können:

Jetzt können wir gezielt die benötigte Extension installieren und in den Cluster (Postgres-Server) einbinden.

apt install percona-pg-stat-monitor14


Die Extension wird, wie bei PostgreSQL üblich, installiert. Die Konfiguration des Servers muss zusätzlich für die Verwendung dieses Tools angepasst werden, damit die entsprechende Library der Extension mit dem Start des Clusters geladen wird (Parameter "shared_preload_libraries"):

Nach dem Reboot des PostgreSQL-Clusters steht uns nun die Erweiterung zur Verfügung:

Der Zahlenraum 

Nach der Installation stehen uns zwei Tabellen (Views) zur Verfügung. In der Tabelle „pg_stat_monitor“ werden die Ergebnisse der Query-Aktivität des Clusters festgehalten. Die Tabelle „pg_stat_monitor_settings“ definiert, wie und welche Daten protokolliert werden. Wichtig ist zu verstehen, dass die Ergebnisse, bzw. Metriken der einzelnen Queries, nicht permanent fortgeschrieben werden (die entsprechenden Metriken steigen nicht permanent monoton an). Dies ist beispielsweise bei der Erweiterung „pg_stat_statements“ der Fall und unterscheidet damit beide Lösungen signifikant. Vielmehr stellt uns „pg_stat_monitor“ per Default 10 sogenannte „Buckets“ (Eimer) zur Verfügung, die „ab Werk“ jeweils 60 Sekunden aufnehmen. Der Beobachtungszeitraum besteht somit aus 10 x 60 Sekunden (10 Minuten).

Im Folgenden sehen wir uns die Daten für ein immer wiederkehrendes SELECT mit der ID 'BB08F6556B678B54' an, um diese Struktur von „Buckets“ zu verstehen. Die Query wurde von der bekannten Benchmark-Suite „pgbench“ erzeugt, welche in einer Schleife wieder und wieder über einen längeren Zeitraum gegen unseren Testserver-Cluster gelaufen ist.

Wir sehen die zyklische Beschreibung unserer „Buckets“ (0 - 9) und erkennen auch das oben beschriebene zeitliche Intervall von 10 Minuten (10:07:00 - 10:16:59; Achtung: Die Spalte „bucket_start_time“ beschreibt den Startzeitpunkt, ab dem begonnen (!) wurde das „Bucket“ zu beschreiben).

Zusätzlich haben wir der Auswertung einige wenige, exemplarische Metriken hinzugefügt („total_exec_time“ 🠖 summierte Gesamtlaufzeit der Statements; „mean_exec_time“ 🠖 durchschnittliche Laufzeit eines Statements).

Natürlich sind viele weitere interessante Metriken über diese „View“ verfügbar.

Welche Metriken zur Verfügung stehen (es sind übrigens deutlich mehr als bei der Extension „pg_stat_statements“), kann der untenstehenden Tabellenstruktur entnommen werden:

Inhaltliche Erklärungen der Attribute können der aktuellen Dokumentation entnommen werden:

https://github.com/percona/pg_stat_monitor/blob/main/docs/REFERENCE.md

Beschreibende Statistik 

Eine besondere Bedeutung hat die Spalte „resp_calls“, welche ein Histogramm der Query, für den Zeitraum eines „Buckets“ enthält. Wir schauen uns das Laufzeitverhalten des oben bereits genutzten SELECTs nun detaillierter an.

Um die Darstellung der Histogramme etwas ansprechender zu gestalten, wird die Funktion „histogram“ mitgeliefert. Diese stellt die Ausführungszeiten als Balkendiagramm dar. Die einzelnen Balken repräsentieren dabei die unterschiedlichen Zeiten in Millisekunden-Klassen („range“). In unserem Beispiel wurde die Query in diesem Zeitfenster meistens (10x) innerhalb der Klasse von 0 bis 3 Millisekunden ausgeführt. Nur in wenigen Fällen (2x) hat die Ausführung etwas länger gedauert (3 – 10 Millisekunden).

Immer schön dem Plan folgen? 

Für den Fall, dass schwankende Ausführungszeiten beobachtet werden (Verteilung des Statements auf unterschiedliche Histogramm-Klassen), kann dies verschiedene Ursachen haben. Beispielsweise könnte dieses Verhalten an unterschiedlichen Ausführungsplänen liegen, die zur Ausführung der Query genutzt wurden. Auch diese Pläne können im Bedarfsfall zusätzlich durch die „Extension“ protokolliert werden.

Dazu muss die Konfiguration angepasst und der Cluster neu gestartet werden:

Ab diesem Moment werden pro Ausführung einer Query, die Pläne ebenfalls gespeichert, können abgerufen und im Bedarfsfall auch über die „Buckets“ (und damit das Zeitfenster unseres Beobachtungszeitraumes) verglichen werden.

Im unten stehenden Beispiel haben wir, aus Gründen der Übersichtlichkeit, den Ausführungsplan aus lediglich einem Bucket dargestellt. 

Fazit 

„pg_stat_monitor“ ist eine weitere sinnvolle Extension, um Performance-Problemen auf den Grund zu gehen. Wer sich bereits mit „pg_stat_statements“ beschäftigt hat, sollte auf jeden Fall einen „Blick riskieren“ und die beiden Erweiterungen gegenüberstellen und vergleichen. Gerade das „Werkzeug“ der Histogramme ist eine nützliche Ergänzung und kann im Bedarfsfall extrem nützlich sein.

Seminarempfehlung