In diesem Dokument wird beschrieben, wie Sie Leistungsprobleme der AlloyDB Omni-Datenbank mithilfe eines Berichts identifizieren und beheben können, in dem Snapshots von Systemmesswerten zwischen zwei verschiedenen Zeitpunkten verglichen werden. Zu den in jedem Snapshot erfassten Systemmesswerten gehören die Nutzung der virtuellen CPU (vCPU), die Arbeitsspeichernutzung, die Laufwerk-I/O, die Transaktionsanzahl und Warteereignisse.
Funktionsweise von Berichten zu Leistungs-Snapshots
Leistungs-Snapshot-Berichte sind ein integriertes AlloyDB Omni-Tool, mit dem Leistungsdaten erfasst und analysiert werden, um die Ursache von Leistungsproblemen zu ermitteln. Dieses Tool ergänzt andere AlloyDB Omni-Funktionen zur Observabilität wie Systemstatistiken, Abfragestatistiken und den Messwert-Explorer, die Echtzeitmesswerte zu Ihrer Instanz liefern.
In Leistungs-Snapshot-Berichten werden Datenbankmesswerte zwischen zwei Zeitstempeln in einem einzigen Bericht angezeigt. Anhand der Informationen im Bericht zum Leistungs-Snapshot können Sie Leistungsprobleme mit Ihrer Instanz des Berichts zum Leistungs-Snapshot ermitteln, z. B. eine verringerte Datenbankleistung zu bestimmten Tageszeiten oder eine verringerte Leistung über einen bestimmten Zeitraum.
Im Bericht „Leistungsübersicht“ können Sie die Messwerte mit einer Leistungsgrundlage vergleichen, um Informationen zu den Leistungsmesswerten der Arbeitslast zu erhalten. Diese können Sie dann zur Optimierung oder Fehlerbehebung der Datenbankleistung verwenden. Eine Baseline ist ein benutzerdefinierter Satz von Datenbank-Snapshots, mit denen die Standardleistung und das Standardverhalten einer Datenbank für eine bestimmte Konfiguration und Arbeitslast gemessen werden.
Informationen zu Wartevorgängen im Bericht zum Leistungs-Snapshot finden Sie im Hilfeartikel Referenz zum Bericht zum Datenbankleistungs-Snapshot.
Erforderliche Rollen
Sie benötigen die Rolle alloydbsuperuser.
Standardmäßig gewährt AlloyDB alloydbsuperuser die Rolle pg_monitor. Weitere Informationen finden Sie unter Vordefinierte PostgreSQL-Rollen.
Wenn Sie lieber Ihre anderen selbst definierten Rollen verwenden möchten, führen Sie GRANT pg_monitor TO my_user zuerst als alloydbsuperuser aus. Weitere Informationen finden Sie unter IAM-Konto (Identity and Access Management) mit der entsprechenden Rolle aktualisieren.
Bericht „Leistungs-Snapshot“ installieren
perfsnap ist der Schemaname, der SQL-Funktionen enthält, mit denen Nutzer Snapshots erstellen oder Berichte generieren können. Dieses Schema ist Teil der AlloyDB Omni-Erweiterung g_stats. Verwenden Sie die Superuser-Rolle, um den Bericht „Leistungsübersicht“ zu installieren.
Wenn Sie die perfsnap APIs verwenden möchten, stellen Sie eine Verbindung zu einer Datenbank her, in der Nutzer die Erweiterung installieren möchten, und erstellen Sie die g_stats-Erweiterung mit dem folgenden Befehl:
CREATE EXTENSION IF NOT EXISTS g_stats;
Snapshot von Systemmesswerten erstellen
Erstellen Sie einen Snapshot zu Beginn und am Ende der gewünschten Arbeitslast. Das Zeitintervall zwischen den beiden Snapshots lässt der Arbeitslast genügend Zeit, um sich zu entwickeln, damit das System Messwerte erfassen kann, die die Arbeitslast widerspiegeln. Nachdem Sie die Messwerte aus dem Bericht zum Leistungs-Snapshot erhalten haben, können Sie weitere Snapshots erstellen und den Vorgang wiederholen.
- Verbinden Sie einen
psql-Client mit einer AlloyDB-Instanz. Führen Sie
SELECT perfsnap.snap()aus. Die Ausgabe sieht dann ungefähr so aus:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Liste der Snapshots aufrufen
- Verbinden Sie einen
psql-Client mit einer AlloyDB Omni-Instanz. Führen Sie
SELECT * FROM perfsnap.g$snapshotsaus. Die Ausgabe sieht dann ungefähr so aus:postgres=# select * from perfsnap.g$snapshots; snap_id | snap_time | instance_id | node_id | snap_description | snap_type | is_baseline ---------+-------------------------------+-------------+---------+------------------+-----------+------------- 1 | 2023-11-13 22:13:43.159237+00 | sr-primary | | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | sr-primary | | Automatic snapshot| Automatic | f (2 rows)
Snapshot-Bericht erstellen
Wenn Sie einen Bericht erstellen möchten, der den Unterschied zwischen Snapshot 1 und 2 erfasst, führen Sie beispielsweise SELECT perfsnap.report(1,2) aus.
Der zweite Snapshot in einem differenziellen Vorgang muss nicht unmittelbar auf den ersten Snapshot folgen. Achten Sie jedoch darauf, den zweiten Snapshot nach dem ersten Snapshot zu erstellen.
Der generierte Leistungs-Snapshot-Bericht sieht in etwa so aus:
Beispiel für einen Leistungs-Snapshot-Bericht
$ psql -d postgres -U alloydbsuperuser
postgres=> select perfsnap.report(22, 23);
report
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PGSNAP DB Report for:
Snapshot details
--------------------------------------
Host i841-sr-primary-2a34f46e-06bc
Release 14.12
Startup Time 2024-10-08 03:23:15+00
Snap Id Snap Time
------------ ---------- ------------------------
Begin Snap: 22 24.10.2024 04:33:56 (UTC) Automatic snapshot
End Snap: 23 25.10.2024 04:38:56 (UTC) Automatic snapshot
Elapsed: 1 day 00:04:59.979321
Database Cache sizes
~~~~~~~~~~~~~
Shared Buffers: 31 GB Block Size: 8192
Effective Cache Size: 25 GB WAL Buffers: 16384
Host CPU
~~~~~~~~~~
%User %Nice %System %Idle %WIO %IRQ %SIRQ %Steal %Guest
------- ------- ------- ------- ------- ------- ------- ------- -------
1.07 0.22 0.91 97.40 0.09 0.00 0.31 0.00 0.00
Host Memory
~~~~~~~~~~~~
Total Memory: 63 GB
Available Memory: 11 GB
Free Memory: 726 MB
Buffers Memory: 3706 MB
Load profile (in bytes)
~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
------------ ---------------
Redo size: 63083.64 4489.93
Logical reads: 1961.21 139.59
...
Response Time Profile (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPU time: 5399 ( 0.39%)
Wait time: 1386906 ( 99.61%)
Total time: 1392306
Backend Processes Wait Class Breakdown (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IO 119.300 ( 98.91%)
LWLock 1.305 ( 1.08%)
IPC .010 ( 0.01%)
Lock .000 ( 0.00%)
Backend Processes Wait Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits Time (us) Avg (us)
-------------------------------------- ------------- ------------- -------------- -------------
CPU 1995948632
WALInsert LWLock 1 6656 6656
Vacuum Information
~~~~~~~~~~~~~~~~~~~
Num Analyze operations: 1976
Num Vacuum operations: 3435
Per Database Information
~~~~~~~~~~~~~~~~~~~~~~~~~
Name Commits Rollbacks BlkRds Blkhits TempFiles TempBytes
------------------------- ------------- ------------- ------------- ------------- ------------- -------------
bench 27939 0 0 7823038 0 0 bytes
postgres 39792 0 7 11089243 0 0 bytes
Per Database DML & DQL Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Tuples returned Tuples fetched Tuples inserted Tuples updated Tuples deleted Index splits Index Only heap fetches HOT updates
------------------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ------------------------- ----------------
bench 16119481 4843262 0 0 0 0 16 0
postgres 25415473 6327188 0 10 0 0 0 8
Per Database Conflict Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Lock Timeout Old Snapshot Buffer Pins Deadlock
------------------------- ------------- ------------- ------------- -------------
bench 0 0 0 0
postgres 0 0 0 0
Per Database Vacuum Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Frozen XID % Consumed Aggregate Vacuum Gap
------------------------- ------------- ------------- --------------------
bench 179460916 9.00% 20539084
postgres 179339239 9.00% 20660761
Per Database Sizing Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Conn.
Name Collation Limit Tablespace DB Size Growth
-------------------- ------------- ------- -------------------- ---------- ----------
bench C.UTF-8 -1 pg_default 80 GB 0 bytes
postgres C.UTF-8 -1 pg_default 135 MB 0 bytes
Backend Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 1 0 0 0 0 0 0 0 0 0 0
Background Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 542 107 174 39 113 93 8 1 1 0 1
Write Ahead Log (WAL) Statistics
--------------------------------
Records Full Page Images Bytes Buffers Full Write Sync Write Time Sync Time
----------- ---------------- ----------- ------------ ----------- ----------- ----------- -----------
2936305 100 805989345 0 0 0 0 0
Summary Stats (across all databases)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Value
-------------------------------- ----------------------------------
Buffers evicted 0
Commits 1216693
...
Parameter Settings
~~~~~~~~~~~~~~~~~~~
Parameter Value
--------------------------------- --------------------------------------------------------------
DateStyle ISO, MDY
TimeZone UTC
autovacuum on
work_mem 4096
Columnar Engine available size Columnar Engine configured size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14959MB 19293MB
Columnar Engine Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name count
---------------------------------------------------------- ------------
CU Populations/Refreshes 13197
CU Auto Refreshes 10975
...
Columnar Engine Ultra-fast Cache Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ultra-fast Cache Size (MB): 19200
Ultra-fast Cache Used Size (MB): 0
Ultra-fast Cache Block Size (MB): 80
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
Informationen zu Berichtsfeldern und Empfehlungen zur Leistungsoptimierung finden Sie unter Empfehlungen zur Optimierung der Datenbankleistung. Weitere Informationen zu Wartevorgängen in Berichten zu Leistungs-Snapshots finden Sie im Hilfeartikel Referenzbericht zu Leistungs-Snapshots von Datenbanken.
Snapshot löschen
Bevor Sie Snapshots löschen können, die Teil einer vorhandenen Baseline sind, müssen Sie die Baseline löschen .
Führen Sie SELECT perfsnap.delete(n) aus, um einen Snapshot zu löschen. Gelöschte Snapshots können nicht wiederhergestellt werden.
Snapshot als Leistungsmesspunkt markieren
Wenn Sie beispielsweise alle Snapshots mit den IDs 1 bis 3 als Systemleistungsgrundlage kennzeichnen möchten, führen Sie SELECT perfsnap.make_baseline(1, 3) aus.
Leistungs-Baselines löschen
Wenn Sie beispielsweise alle Baselines mit den IDs 1 bis 3 löschen möchten, führen Sie SELECT perfsnap.clear_baseline(1, 3) aus.
Leistung der Datenbank anhand der Ergebnisse des Übersichtsberichts optimieren
So optimieren Sie die Leistung der AlloyDB-Datenbank:
- Erstellen Sie Baseline-Snapshots, wenn die Datenbank inaktiv ist oder eine durchschnittliche Auslastung aufweist.
- Starten Sie die Arbeitslast oder Abfrage, deren Leistung Sie verbessern möchten.
- Wenn die Arbeitslast oder Abfrage die maximale Ressourcennutzung erreicht, erstellen Sie eine weitere Reihe von Snapshots. Wir empfehlen, für beide Berichte dasselbe Intervall zu verwenden.
- Vergleichen Sie die Berichte, die Sie erstellt haben, mit beiden Snapshot-Sätzen und identifizieren Sie Änderungen, mit denen sich die Leistung verbessern lässt. Weitere Informationen zu Leistungsempfehlungen finden Sie unter Empfehlungen zur Optimierung der Datenbankleistung.
Empfehlungen zur Optimierung der Datenbankleistung
In der folgenden Tabelle sind die Abschnitte des Leistungsberichts und die empfohlenen Verbesserungen für die einzelnen Abschnitte aufgeführt. Weitere Informationen zu den Abschnitten und Wartevorgängen im Leistungs-Snapshot-Bericht finden Sie im Referenzhandbuch zum Bericht „Datenbankleistung – Snapshot“.
| Abschnitt | Berichtsfeld | Beschreibung des Berichtsfelds | Optimierungsempfehlungen |
|---|---|---|---|
| Snapshot-Details | Snapshot-Details | Gibt den Host, die mit PostgreSQL kompatible Releaseversion und die Zeit an, zu der der Computer in Betrieb ist. | – |
| Snapshot-ID | Die ID und der Zeitpunkt der Snapshots, die zum Erstellen dieses Berichts verwendet werden. | – | |
| Systemstatistiken | Host-CPU | Details zur CPU-Auslastung des Hosts. | Wenn die CPU-Auslastung mehr als 80 % beträgt, empfehlen wir Ihnen, zu einem System mit mehr vCPUs zu wechseln. |
| Hostspeicher | Details zur Hostspeicherauslastung. | Wenn der freie Arbeitsspeicher weniger als 15 % beträgt, empfehlen wir, die Größe auf die nächste verfügbare Größe zu erhöhen. | |
| Ladeprofil | Zeigt Zähler an, mit denen sich Ihre Arbeitslast in Bezug auf generierte WAL-Dateien (Write-Ahead Logging), E/A-Anforderungen und Verbindungsverwaltung charakterisieren lässt. | Wenn die Anzahl der physischen Lesevorgänge höher ist als die der logischen Lesevorgänge, sollten Sie die Größe auf die nächste verfügbare Größe hochskalieren, um ein größeres Caching von Daten zu ermöglichen. | |
| Aufschlüsselung nach Antwortzeit und Warteklasse | Aufschlüsselung der Zeit, die Postgres-Prozesse während der Ausführung der Arbeitslast benötigt haben. | Konzentrieren Sie sich bei der Optimierung darauf, die E/A-Wartezeit zu verkürzen, wenn sich die Prozesse beispielsweise hauptsächlich in einem Wartestatus befinden. | |
| Informationen zur Datenbankarbeitslast | Informationen zur Arbeitslast pro Datenbank | Wichtige Messwerte für jede Datenbank, einschließlich Commits, Rollbacks, Trefferquoten sowie Informationen zu temporären Tabellen und Sortiervorgängen. | Wenn viele Rollbacks auftreten, sollten Sie Ihre App untersuchen. |
| DML- und DQL-Informationen pro Datenbank | Zähler für Abfragevorgänge. | Beschreiben Sie Ihre Arbeitslast als leselastig oder schreiblastig. | |
| Informationen zu Datenbankkonflikten | Zähler für häufige Anwendungs- und Datenbankprobleme. | Suchen Sie nach Problemen in Ihrer Anwendung, wenn es zu einem Deadlock kommt. | |
| Datenbank Informationen zur Größe |
Gibt an, wie stark sich die Datenbank im Intervall zwischen zwei Snapshots vergrößert hat. In diesem Feld wird auch angezeigt, ob für die Datenbank Verbindungslimits festgelegt wurden. | Probleme in Ihrer Anwendung finden, wenn das Datenbankwachstum zu groß ist | |
| Informationen zum Vakuum | Informationen zum Vakuum | Details zu E/A und Zähler für Löschvorgänge. | Standardmäßig führt AlloyDB eine adaptive Datenbereinigung durch. Sie können einige der Einstellungen für die Datenbereinigung überschreiben, um sie an Ihre Arbeitslast anzupassen. So können Sie beispielsweise die Anzahl der Bereinigungsvorgänge reduzieren, wenn für diese Anfragen zu viele E/A-Vorgänge erforderlich sind. |
| Informationen zum Leeren der Datenbank | Hier finden Sie die folgenden Informationen:
|
Wenn das Feld „Frozen XID“ zu alt ist oder der Prozentsatz der verwendeten Transaktionen fast 90 % beträgt, sollten Sie eine Datenbereinigung durchführen. Wenn die Gesamtlücke für das Löschen kleiner wird, wird von Postgres ein Löschvorgang erzwungen, um einen Überlauf zu verhindern. | |
| Details zur Wartezeit von Datenbankprozessen | Ausführliche Informationen zum Backend und zu Hintergrundprozessen |
Details zu allen Wartezeiten nach Backend- und Hintergrundprozessen im Berichtszeitraum. Zu den Informationen gehören die kumulative Wartezeit, die CPU-Zeit und die durchschnittliche Zeit pro Wartetyp. | Wenn Sie die Wartezeit auf WALWrite verringern möchten, erhöhen Sie beispielsweise die Anzahl der für die Datenbank verfügbaren wal_buffers. |
| Detailliertes Histogramm für Backend- und Hintergrundwarteereignisse | Dieser ist standardmäßig im Bericht „Leistungs-Snapshot“ enthalten. Die Liste enthält das Histogramm für Warteereignisse für Back-End- und Hintergrundprozesse, die in 32 Buckets von 1 µs bis über 16 Sekunden unterteilt sind. | Suchen Sie die Warteereignisse und prüfen Sie, ob es zu viele Warteereignisse im größeren Wartezeitbereich gibt. Möglicherweise liegt ein Problem mit zu vielen Warteereignissen oder mit der jeweiligen Wartezeit vor. | |
| Sonstige Statistiken | Statistiken zum Write-Ahead-Log (WAL) | Zusammenfassung der WAL-Statistiken. | Wenn die Synchronisierung zu lange dauert, passen Sie die zugehörigen Datenbank-Flags (GUC) an, um die Arbeitslast zu verbessern. GUC ist das PostgreSQL-Subsystem, das die Serverkonfiguration verwaltet. |
| Zusammenfassungsstatistiken (für alle Datenbanken) | Zusammenfassung aller Datenbankvorgänge, die während des Snapshot-Intervalls stattfinden. | – | |
| Parametereinstellungen | Parametereinstellungen | Wichtige Postgres-Konfigurationsparameter zum Zeitpunkt des End-Snapshots. | Prüfen Sie die GUC-Parametereinstellungen (die Postgres-Datenbank-Flags), um festzustellen, ob die Werte nicht erwartet oder nicht empfohlen werden. |
Beschränkungen
Um eine Datenüberflutung zu vermeiden, können Sie manuell maximal 2.500 Snapshots auf einer Instanz erstellen. Mit Space Bloat wird dafür gesorgt, dass Snapshots nicht zu viel Speicherplatz in Ihrer Datenbank belegen.
Wenn die Anzahl der Snapshots das Snapshot-Limit überschreitet, löscht AlloyDB Omni alle manuellen Snapshots, die älter als 90 Tage sind. Damit Sie das Snapshot-Limit nicht überschreiten, müssen Sie unnötige Snapshots löschen, bevor Sie einen neuen erstellen.
In AlloyDB Omni werden regelmäßig manuelle Snapshots gelöscht, die älter als 90 Tage sind.