Funktionsweise von Performance Snapshot Reports
Performance Snapshot Reports sind ein integriertes AlloyDB Omni-Tool, mit dem Leistungsdaten erfasst und analysiert werden, um die Ursache von Leistungsproblemen zu ermitteln.
In Performance Snapshot Reports werden Datenbankmesswerte zwischen zwei Zeitstempeln in einem einzigen Bericht angezeigt. Anhand der Informationen im Performance Snapshot Report können Sie Leistungsprobleme mit Ihrer Performance Snapshot Report-Instanz ermitteln, z. B. eine verringerte Datenbankleistung zu bestimmten Tageszeiten oder eine verringerte Leistung über einen bestimmten Zeitraum.
Mithilfe des Performance Snapshot Reports vergleichen Sie die Messwerte mit einer Leistungs-Baseline, um Einblicke in die Leistungsmesswerte der Arbeitslast zu erhalten. Diese können Sie dann zur Optimierung oder Fehlerbehebung der Datenbankleistung verwenden. Eine Baseline ist eine benutzerdefinierte Gruppe von Datenbank-Snapshots, mit denen die Standardleistung und das Standardverhalten einer Datenbank für eine bestimmte Konfiguration und Arbeitslast gemessen werden.
Informationen zu Warteereignissen im Performance Snapshot Report finden Sie in der Referenz für den Datenbank-Performance Snapshot Report.
Erforderliche Rollen
Achten Sie darauf, dass Sie die pg_monitor Rolle haben.
Diese Rolle wird Superusern gewährt, die sie dann pg_monitor anderen Nutzern gewähren können.
postgres ist beispielsweise standardmäßig der Superuser. Sie können
GRANT pg_monitor TO my_user als postgres ausführen, damit my_user das Performance Snapshot-Tool wie in diesem Dokument beschrieben verwenden kann.
Performance Snapshot Report 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 Performance Snapshot Report zu installieren.
Wenn Sie die perfsnap-APIs verwenden möchten, stellen Sie eine Verbindung zu einer beliebigen Datenbank her, in der Nutzer die Erweiterung installieren möchten, und erstellen Sie die Erweiterung g_stats mit dem folgenden Befehl:
CREATE EXTENSION IF NOT EXISTS g_stats;
Snapshot von Systemmesswerten erstellen
Erstellen Sie einen Snapshot am Anfang und am Ende der Arbeitslast, die Sie untersuchen möchten. Das Zeitintervall zwischen den beiden Snapshots ist lang genug, damit die Arbeitslast fortschreiten kann und das System Messwerte erfassen kann, die die Arbeitslast widerspiegeln. Nachdem Sie Messwerte aus dem resultierenden Performance Snapshot Report erhalten haben, können Sie eine weitere Gruppe von Snapshots erstellen und den Vorgang wiederholen.
- Verbinden Sie einen
psqlClient 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)
Snapshot mit Statistiken zur SQL-Ausführung erstellen
Standardmäßig verwendet AlloyDB Omni die Erweiterung pg_stat_statements, um SQL-Anweisungen zu verfolgen. Wenn Sie detaillierte Statistiken zur SQL-Ausführung in Ihren Leistungsbericht aufnehmen möchten, müssen Sie zuerst die Erweiterung pg_stat_statements in Ihrer postgres-Datenbank erstellen. Beachten Sie, dass die Erfassung dieser Statistiken durch das Flag pg_stat_statements.track aktiviert wird, nicht durch die Erstellung der Erweiterung selbst.
So erstellen Sie einen Snapshot, der auch Statistiken zur SQL-Ausführung enthält:
Erstellen Sie die Erweiterung
pg_stat_statementsin derpostgres-Datenbank.postgres=# CREATE EXTENSION pg_stat_statements;Wenn Sie jetzt einen Snapshot erstellen, werden automatisch die SQL-Statistiken aus
pg_stat_statementsaufgenommen.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Liste der Snapshots ansehen
- Verbinden Sie einen
psqlClient mit einer AlloyDB-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 Report generieren
Wenn Sie einen Bericht generieren möchten, in dem der Unterschied zwischen Snapshot 1
und Snapshot 2 erfasst wird, führen Sie beispielsweise SELECT perfsnap.report(1,2) aus.
Der zweite Snapshot in einem Differenzvorgang muss nicht direkt auf den ersten Snapshot folgen. Achten Sie jedoch darauf, dass Sie den zweiten Snapshot im Differenzvorgang nach dem ersten Snapshot erstellen.
Der generierte Performance Snapshot Report sieht ungefähr so aus:
Beispiel für einen Performance Snapshot Report
psql -d postgres -U alloydbsuperuser
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
----------------------------------------------------
(rows)
Informationen zu den Berichtsfeldern und Empfehlungen zur Leistungsoptimierung, siehe Empfehlungen zur Optimierung der Datenbankleistung. Weitere Informationen zu Warteereignissen in Performance Snapshot Reports finden Sie in der Referenz für den Datenbank-Performance Snapshot Report.
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 Leistungs-Baseline markieren
Wenn Sie beispielsweise alle Snapshots mit IDs zwischen 1 und 3 als System
leistungs-Baseline markieren möchten, führen Sie SELECT perfsnap.make_baseline(1, 3) aus.
Leistungs-Baselines löschen
Wenn Sie beispielsweise alle Baselines mit IDs zwischen 1 und 3 löschen möchten, führen Sie SELECT perfsnap.clear_baseline(1, 3) aus.
Datenbankleistung mithilfe von Snapshot Report-Ergebnissen optimieren
So optimieren Sie die Leistung von AlloyDB-Datenbanken:
- Erstellen Sie Baseline-Snapshots, wenn Ihre Datenbank im Leerlauf ist oder eine durchschnittliche Last 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 Gruppe von Snapshots. Wir empfehlen, für beide Berichte dasselbe Intervall zu verwenden.
- Vergleichen Sie die Berichte, die Sie mit beiden Gruppen von Snapshots erstellt haben, und ermitteln Sie Änderungen, die die Leistung verbessern könnten. 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 Performance Snapshot Reports und empfohlene Verbesserungen für die einzelnen Abschnitte aufgeführt. Weitere Informationen zu den Abschnitten des Performance Snapshot Reports und zu Warteereignissen finden Sie in der Referenz für den Datenbank-Performance Snapshot Report.
| Abschnitt | Feld im Bericht | Beschreibung des Berichtsfelds | Optimierungsempfehlungen |
|---|---|---|---|
| Snapshot-Details | Snapshot-Details | Enthält den Host, die mit PostgreSQL kompatible Releaseversion und die Zeit, zu der der Computer in Betrieb genommen wurde. | – |
| Snapshot-ID | Listet die ID und den Zeitpunkt der Snapshots auf, die zum Erstellen dieses Berichts verwendet wurden. | – | |
| Systemstatistiken | Host-CPU | Details zur Host-CPU-Auslastung. | Wenn die CPU-Auslastung über 80 % liegt, empfehlen wir, zu einem System mit mehr vCPUs zu wechseln. |
| Hostarbeitsspeicher | Details zur Hostarbeitsspeicherauslastung. | Wenn der kostenlose Arbeitsspeicher weniger als 15 % beträgt, empfehlen wir, auf die nächstgrößere verfügbare Größe zu skalieren. | |
| Lastprofil | Listet Zähler auf, mit denen Sie Ihre Arbeitslast in Bezug auf generiertes Write-Ahead-Logging (WAL), E/A-Anforderungen und Verbindungsverwaltung charakterisieren können. | Wenn die Anzahl der physischen Lesevorgänge höher ist als die Anzahl der logischen Lesevorgänge, sollten Sie auf die nächstgrößere verfügbare Größe skalieren, um ein größeres Caching von Daten zu ermöglichen. | |
| Aufschlüsselung der Antwortzeit und der Warteklasse | Aufschlüsselung der Zeit, die von Postgres-Prozessen während der Ausführung der Arbeitslast verbracht wurde. | Konzentrieren Sie sich auf die Verkürzung der E/A-Wartezeit, wenn sich die Prozesse hauptsächlich im Wartezustand befinden. | |
| Informationen zur Datenbankarbeitslast | Informationen zur Arbeitslast pro Datenbank | Wichtige Messwerte für jede Datenbank, einschließlich Commits, Rollbacks, Trefferrate und Informationen zu temporären Tabellen und Sortiervorgängen. | Wenn die Anzahl der Rollbacks hoch ist, sollten Sie Ihre App diagnostizieren. |
| DML- und DQL-Informationen pro Datenbank | Zähler für Abfragevorgänge. | Qualifizieren Sie Ihre Arbeitslast als lese- oder schreiblastig. | |
| Informationen zu Datenbankkonflikten | Zähler für häufige Anwendungs- und Datenbankprobleme. | Suchen Sie nach Problemen in Ihrer Anwendung, wenn ein Deadlock auftritt. | |
| Informationen zur Größe der Datenbank |
Zeigt, um wie viel die Datenbank im Intervall zwischen zwei Snapshots gewachsen ist. In diesem Feld wird auch angezeigt, ob für die Datenbank Verbindungslimits festgelegt wurden. | Suchen Sie nach Problemen in Ihrer Anwendung, wenn das Wachstum der Datenbank zu groß ist. | |
| Informationen zur Bereinigung | Informationen zur Bereinigung | Details zu E/A und Zähler für Bereinigungsvorgänge. | Standardmäßig führt AlloyDB eine adaptive Bereinigung durch. Sie können einige der Bereinigungseinstellungen an Ihre Arbeitslast anpassen. Reduzieren Sie beispielsweise die Anzahl der Bereinigungsvorgänge, wenn zu viel E/A für diese Anfragen aufgewendet wird. |
| Informationen zur Bereinigung pro Datenbank | Enthält die folgenden Informationen:
|
Wenn das Alter des Felds „Frozen XID“ zu hoch ist oder der Prozentsatz der verwendeten Transaktionen nahe 90 % liegt, sollten Sie eine Bereinigung durchführen. Wenn der aggregierte Bereinigungsabstand abnimmt, wird eine Bereinigung von Postgres erzwungen, um einen Wraparound zu verhindern. | |
| Details zu Wartezeiten von Datenbankprozessen | Detaillierte Informationen zu Back-End- und & Hintergrundprozessen |
Details zu allen Wartezeiten nach Back-End- und Hintergrundprozessen im Berichtsintervall. Die Informationen umfassen die kumulative Wartezeit, die CPU-Zeit und die durchschnittliche Zeit pro Wartezeitentyp. | Um beispielsweise die Wartezeit für WALWrite zu verringern, erhöhen Sie die Anzahl der wal_buffers, die der Datenbank zur Verfügung stehen. |
| Detailliertes Histogramm der Warteereignisse für Back-End- und Hintergrundprozesse | Dieses Histogramm ist standardmäßig im Performance Snapshot Report enthalten. Die Liste enthält das Histogramm der Warteereignisse für Back-End- und Hintergrundprozesse, die in 32 Buckets unterteilt sind, von 1 Mikrosekunde bis über 16 Sekunden. | Suchen Sie nach den Warteereignissen und prüfen Sie, ob es zu viele Warteereignisse im Bucket mit der längeren Wartezeit gibt. Möglicherweise gibt es ein Problem mit zu vielen Warteereignissen oder mit der jeweils verbrauchten Wartezeit. | |
| Sonstige Statistiken | Write-Ahead-Log-Statistiken (WAL) | Zusammenfassung der WAL-Statistiken. | Wenn die Synchronisierungszeit zu lang ist, passen Sie die entsprechenden Datenbank-Flags (GUC) an, um die Leistung Ihrer Arbeitslast zu verbessern. GUC ist das PostgreSQL-Subsystem, das die Serverkonfiguration verwaltet. |
| Zusammenfassende Statistiken (für alle Datenbanken) | Zusammenfassung aller Datenbankvorgänge, die während des Snapshot-Intervalls auftreten. | – | |
| 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 unerwartet oder nicht empfehlenswert sind. |
| Statistiken zur SQL-Ausführung | Informationen pro Abfrage (Top 50) nach verstrichener Gesamtzeit | Listet die 50 wichtigsten Abfragen auf, bei denen zwischen den beiden Snapshots die meiste Zeit verstrichen ist, sowie die Gesamtzahl der Ausführungen, aufgeschlüsselt nach Nutzer und Datenbank, in der die Abfrage ausgegeben wurde.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
In diesem Abschnitt können Sie die Abfrage mit der höchsten Last ermitteln, die die meiste Systemzeit in Anspruch nimmt. |
| Informationen pro Abfrage (Top 50) nach E/A-Lesevorgängen | Listet die 50 wichtigsten Abfragen auf, bei denen zwischen den beiden Snapshots die meiste Zeit für E/A-Lesevorgänge aufgewendet wurde, sowie die Anzahl der Ausführungen, die Anzahl der Puffer-Treffer und die Anzahl der Blocklesevorgänge, sowohl insgesamt als auch im Durchschnitt.ReadIO = blk_read_time + temp_blk_read_time (kumuliert während der beiden Snapshots)Buffer Hits = shared_blks_hit + local_blks_hit (kumuliert während der beiden Snapshots)Buffer Reads = shared_blks_read + local_blks_read (kumuliert während der beiden Snapshots)Diese Felder werden standardmäßig von AlloyDB Cloud erfasst, da track_io_timing festgelegt ist. |
In diesem Abschnitt können Sie E/A-intensive Abfragen ermitteln, insbesondere wenn sie häufig von Laufwerken lesen müssen. | |
| Informationen pro Abfrage (Top 50) nach Standardabweichung der verstrichenen Zeit | Listet die 50 wichtigsten Abfragen mit der höchsten Standardabweichung der verstrichenen Zeit auf und enthält die Standardabweichungen, die sowohl zum Zeitpunkt des Beginns als auch zum Zeitpunkt des Endes des Snapshots berechnet wurden. Hier bezieht sich der Wert auf stddev_exec_time aus pg_stat_statements |
Bei einer Abfrage mit einer hohen Standardabweichung variiert die Ausführungszeit der Abfrage stark. Es ist möglicherweise an der Zeit, sich die E/A anzusehen. |
Beschränkungen
Um eine zu starke Zunahme des Speicherplatzes zu vermeiden, können Sie manuell maximal 2.500 Snapshots auf einer Instanz erstellen. Space bloat sorgt dafür, 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. Um das Snapshot-Limit nicht zu überschreiten, müssen Sie unnötige Snapshots löschen, bevor Sie einen neuen erstellen.
AlloyDB Omni löscht regelmäßig manuelle Snapshots, die älter als 90 Tage sind.
Nächste Schritte
- Informationen zu Warteereignissen in Performance Snapshot Reports