In diesem Dokument wird beschrieben, wie Sie Leistungs-Snapshot-Berichte manuell erstellen, mit denen Sie Snapshots von Systemmesswerten zwischen zwei Zeitpunkten vergleichen können. Mit Performance Snapshot Reports können Sie Leistungsprobleme in AlloyDB for PostgreSQL-Datenbanken identifizieren und beheben. Die in jedem Snapshot erfassten Systemmesswerte umfassen die Nutzung der virtuellen CPU (vCPU), die Arbeitsspeichernutzung, die Festplatten-E/A, die Anzahl der Transaktionen und Warteereignisse.
Automatische und manuelle Snapshots
AlloyDB unterstützt die folgenden Snapshots:
Automatische Snapshots:Standardmäßig erstellt AlloyDB einmal täglich automatisch Snapshots und speichert sie sieben Tage lang. Automatische Snapshots helfen dabei, Berichte mit täglicher Arbeitslastgranularität zu erstellen. Sie können die Aufbewahrungsdauer eines automatischen Snapshots nicht ändern, aber die Häufigkeit konfigurieren.
Manuelle Snapshots:Sie können Snapshots manuell erfassen und Berichte erstellen.
Sie können automatische und manuelle Snapshots kombinieren, um Leistungsberichte zu erstellen. Sie können beispielsweise einen Leistungs-Snapshot-Bericht erstellen, in dem ein manuell generierter Snapshot mit einem automatischen Snapshot verglichen wird.
In diesem Dokument wird beschrieben, wie Sie Leistungs-Snapshot-Berichte manuell erstellen.
So funktionieren Performance Snapshot Reports
Performance Snapshot Reports sind ein integriertes AlloyDB-Tool, mit dem Leistungsdaten erfasst und analysiert werden, um die Ursache von Leistungsproblemen zu ermitteln. Dieses Tool ergänzt andere AlloyDB-Funktionen zur Beobachtbarkeit wie System Insights, Query Insights und den Metrics Explorer, die Echtzeitmesswerte zu Ihrer Instanz liefern.
In Performance Snapshot Reports werden Datenbankmesswerte zwischen zwei Zeitstempeln in einem einzigen Bericht dargestellt. Mithilfe der Informationen im Performance Snapshot Report können Sie Leistungsprobleme mit Ihrer Performance Snapshot Report-Instanz erkennen, z. B. eine verringerte Datenbankleistung zu bestimmten Tageszeiten oder eine verringerte Leistung über einen bestimmten Zeitraum hinweg.
Mithilfe des Performance Snapshot Report vergleichen Sie die Messwerte mit einer Leistungs-Baseline, um Einblicke in die Messwerte zur Workload-Leistung zu erhalten. Diese können Sie verwenden, um die Datenbankleistung zu optimieren oder Fehler zu beheben. 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 Warteereignissen im Performance Snapshot Report finden Sie unter Referenz für den Datenbank-Performance Snapshot Report.
Erforderliche Rollen
Prüfen Sie, ob Sie die Rolle alloydbsuperuser haben.
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 zuerst GRANT pg_monitor TO my_user als alloydbsuperuser aus. Weitere Informationen finden Sie unter IAM-Konto (Identity and Access Management) mit der entsprechenden Rolle aktualisieren.
Snapshots erstellen
Leistungs-Snapshots sind ein leistungsstarkes Tool, mit dem Sie die Leistung Ihrer Datenbank analysieren und optimieren können. Sie erfassen wichtige Systemmesswerte zu einem bestimmten Zeitpunkt und ermöglichen so einen Vergleich der Datenbankleistung zwischen zwei Zeitpunkten. AlloyDB unterstützt zwei Arten von Snapshots:
- Momentaufnahmen von Systemmesswerten:Diese Momentaufnahmen erfassen wichtige Systemmesswerte wie vCPU-Auslastung, Arbeitsspeichernutzung und Festplatten-E/A.
- Snapshots von Systemmesswerten und SQL-Ausführungsstatistiken:Diese Snapshots enthalten alle Systemmesswerte aus einem Standardsnapshot sowie detaillierte SQL-Ausführungsstatistiken aus der
pg_stat_statements-Erweiterung.
So können Sie den Detaillierungsgrad auswählen, den Sie für Ihre Analyse benötigen.
Snapshot von Systemmesswerten erstellen
Erstellen Sie einen Snapshot am Anfang und am Ende der Arbeitslast, die Sie sich ansehen möchten. Das Zeitintervall zwischen den beiden Snapshots sollte lang genug sein, um eine repräsentative Stichprobe der Arbeitslast zu erfassen.
So optimieren Sie die Leistung von AlloyDB-Datenbanken:
- Erstellen Sie Baseline-Snapshots, wenn Ihre Datenbank inaktiv ist oder eine durchschnittliche Last aufweist.
psql-Client mit einer AlloyDB-Instanz verbindenFühren Sie
SELECT perfsnap.snap()aus. Die Ausgabe sieht dann ungefähr so aus:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)Die Ausgabe dieses Befehls gibt die Snapshot-ID (
snap_id) zurück, die in diesem Beispiel1ist. Sie benötigen diese ID, um später einen Leistungsübersichtsbericht zu erstellen. Dersnap_idin Ihrer Umgebung ist wahrscheinlich anders.Vergleichen Sie die Berichte, die Sie mit beiden Snapshots erstellt haben, und ermitteln Sie Änderungen, mit denen sich die Leistung verbessern lässt. Weitere Informationen zu Leistungsempfehlungen finden Sie unter Empfehlungen zur Optimierung der Datenbankleistung.
Nachdem Sie Messwerte aus dem resultierenden Leistungs-Snapshot-Bericht erhalten haben, können Sie weitere Snapshots erstellen und den Vorgang wiederholen.
Snapshot mit Statistiken zur SQL-Ausführung erstellen
Standardmäßig verwendet AlloyDB die Erweiterung pg_stat_statements, um SQL-Anweisungen zu verfolgen. Wenn Sie detaillierte SQL-Ausführungsstatistiken in Ihren Leistungsbericht aufnehmen möchten, müssen Sie zuerst die Erweiterung pg_stat_statements in Ihrer postgres-Datenbank erstellen. Das Erfassen dieser Statistiken wird durch das Flag pg_stat_statements.track aktiviert, 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 der Datenbankpostgres.postgres=# CREATE EXTENSION pg_stat_statements;
- Wenn Sie jetzt einen Snapshot erstellen, werden automatisch die SQL-Statistiken aus
pg_stat_statementseinbezogen.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Liste der Snapshots ansehen
psql-Client mit einer AlloyDB-Instanz verbinden- 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)
Performance Snapshot Report erstellen
So erstellen Sie einen Bericht, in dem der Unterschied zwischen zwei Snapshots (z. B. Snapshot 1 und Snapshot 2) erfasst wird:SELECT perfsnap.report(1,2)
Der zweite Snapshot in einem differenziellen Vorgang muss nicht direkt auf den ersten Snapshot folgen. Achten Sie jedoch darauf, dass Sie den zweiten Snapshot im Differenziellen nach dem ersten Snapshot aufnehmen.
Beispielbericht
Hier sehen Sie ein gekürztes Beispiel für einen generierten Performance-Snapshot-Bericht:
Beispiel für einen Performance Snapshot Report
$ 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
SQL Report
~~~~~~~~~~
NOTE: Query might be empty if query ID does not have a match in pg_stat_statements at report time. This is expected if the query is not run recently.
Per Query Information (Top 50) By Total Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total Elapsed Time(ms) Execution Count Avg Elapsed Time(ms)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 276400877.8014 36928106 7.4848
prepare payment (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, NUMERIC, VARCHAR) AS select p 36272 36274 tpcc 3864683359055073968 127719636.4656 36928456 3.4586
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 48540963.0880 3694128 13.1400
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 35361366.9271 3692785 9.5758
...
Per Query Information (Top 50) By Read IO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total ReadIO Time(ms) Execution Count Avg ReadIO Time(ms) Total buffer hits Avg buffer hits Total blk reads Avg blk reads
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare ostat (INTEGER, INTEGER, INTEGER, INTEGER, VARCHAR) AS select * from ostat($1,$2,$3,$4,$5) a 36272 36274 tpcc -1640504351418263816 498072.4004 3693895 0.1348 80360201 21.75486877672484 105858 0.028657555236410347
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 12.5438 3694128 0.0000 4477308168 1212.0067761593534 1219908 0.33022894712906536
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 0.8039 36928106 0.0000 10337394097 279.9329620912592 6245570 0.16912781825312134
SELECT name, default_version, installed_version FROM pg_catalog.pg_available_extensions 10 5 postgres 6619165036968781114 0.0000 361 0.0000 361 1 0 0
...
Per Query Information (Top 50) By Standard Deviation of Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Begin STDDEV Elapsed Time(ms) End STDDEV Elapsed Time(ms)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT COUNT($1) FROM perfsnap.g$snapshots 10 5 postgres -8741741796612173369 17.8084 18.1239
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 15.0626 19.8495
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 13.9820 17.0074
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 8.4333 9.6205
----------------------------------------------------
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 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 den folgenden Befehl aus, um einen Snapshot zu löschen:
SELECT perfsnap.delete(SNAP_ID);
Ersetzen Sie SNAP_ID durch die ID des Snapshots, den Sie löschen möchten.
Gelöschte Snapshots können nicht wiederhergestellt werden.
Snapshot als Leistungsreferenz markieren
Wenn Sie beispielsweise alle Snapshots mit IDs zwischen 1 und 3 als Baseline für die Systemleistung 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.
Häufigkeit automatischer Snapshots ändern
Wenn Sie die Häufigkeit automatischer Snapshots anpassen möchten, legen Sie das Flag perfsnap.interval fest, mit dem das automatische Snapshot-Intervall in Sekunden festgelegt wird. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.
Wir empfehlen, den Wert des Flags auf mindestens mehrere Minuten festzulegen, um aussagekräftige Informationen zu erfassen.
Um Ressourcenverschwendung zu vermeiden, sollten Sie das Flag auf den Standardwert (Sekunden pro Tag) zurücksetzen, wenn Sie die benutzerdefinierte Häufigkeit nicht mehr benötigen.
Datenbankleistung mit Snapshot-Berichtsergebnissen 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 Snapshots erstellt haben, und ermitteln 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 Leistungsübersichtsberichts und die empfohlenen Verbesserungen für jeden Abschnitt 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.
| Bereich | Berichtsfeld | Beschreibung des Berichtsfelds | Optimierungsempfehlungen |
|---|---|---|---|
| Snapshot-Details | Snapshot-Details | Gibt den Host, die mit PostgreSQL kompatible Release-Version und die Zeit an, zu der der Computer betriebsbereit ist. | – |
| Snapshot-ID | Hier werden die ID und der Zeitpunkt der Snapshots aufgeführt, die zum Erstellen dieses Berichts verwendet wurden. | – | |
| Systemstatistiken | Host-CPU | Details zur Host-CPU-Auslastung. | Wenn die CPU-Auslastung mehr als 80 % beträgt, empfehlen wir, auf die nächstgrößere verfügbare Größe hochzuskalieren. |
| Hostspeicher | Details zur Hostarbeitsspeicherauslastung. | Wenn der kostenlose Speicherplatz weniger als 15 % beträgt, empfehlen wir, auf die nächste verfügbare Größe zu skalieren. | |
| Profil laden | Hier werden Zähler aufgeführt, mit denen Sie Ihre Arbeitslast für die generierte Write-Ahead-Protokollierung (WAL), die E/A-Anforderungen und die Verbindungsverwaltung qualifizieren können. | Wenn die Anzahl der physischen Lesevorgänge höher ist als die Anzahl der logischen Lesevorgänge, sollten Sie ein Upgrade auf die nächste verfügbare Größe in Betracht ziehen, um das Caching von Daten zu ermöglichen. | |
| Aufschlüsselung nach Reaktionszeit und Warteklasse | Aufschlüsselung der Zeit, die Postgres-Prozesse während der Ausführung der Arbeitslast aufgewendet haben. | Konzentrieren Sie sich beim Optimieren darauf, die E/A-Wartezeit zu verkürzen, wenn sich die Prozesse beispielsweise hauptsächlich im Wartestatus befinden. | |
| Informationen zur Datenbankarbeitslast | Informationen zur Datenbankarbeitslast | Wichtige Messwerte für jede Datenbank, einschließlich Commits, Rollbacks, Trefferquote 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. | Geben Sie an, ob Ihre Arbeitslast eher lese- oder schreibintensiv ist. | |
| Informationen zu Datenbankkonflikten | Zähler für häufige Anwendungs- und Datenbankprobleme. | Suchen Sie nach Problemen in Ihrer Anwendung, wenn ein Deadlock vorliegt. | |
| Informationen zur Datenbankgröße | Zeigt, wie stark die Datenbank im Intervall zwischen zwei Snapshots gewachsen ist. In diesem Feld wird auch angezeigt, ob für die Datenbank Verbindungslimits festgelegt sind. | Suchen Sie in Ihrer Anwendung nach Problemen, wenn das Datenbankwachstum zu groß ist. | |
| Informationen zum Staubsaugen | Informationen zum Staubsaugen | Details zu E/A und Zählern für Vakuumvorgänge. | Standardmäßig führt AlloyDB adaptives VACUUM aus. Sie können einige der Einstellungen für VACUUM an Ihre Arbeitslast anpassen. Reduzieren Sie beispielsweise die Anzahl der VACUUM-Vorgänge, wenn zu viele E/A-Vorgänge für diese Anfragen verwendet werden. |
| Informationen zum Datenbank-Vacuum | Es werden die folgenden Informationen angezeigt:
|
Wenn das Feld „Frozen XID“ zu alt ist oder der Prozentsatz der verbrauchten Transaktionen nahe 90 % liegt, sollten Sie eine Bereinigung in Betracht ziehen. Wenn die aggregierte Vakuumlücke abnimmt, bedeutet dies, dass ein Vakuum von Postgres erzwungen wird, um einen Wraparound zu verhindern. | |
| Wartedetails für Datenbankprozesse | Detaillierte Informationen zu Backend- und Hintergrundprozessen | Details zu allen Wartezuständen nach Backend und Hintergrundprozessen im Berichtszeitraum. Die Informationen umfassen die kumulative Wartezeit, die CPU-Zeit und die durchschnittliche Zeit pro Wartetyp. | Um die Wartezeit für WALWrite zu verkürzen, können Sie beispielsweise die Anzahl der für die Datenbank verfügbaren wal_buffers erhöhen. |
| Detailliertes Histogramm für Backend- und Hintergrund-Warteereignisse | Diese Daten sind standardmäßig im Leistungsübersichtsbericht enthalten. Die Liste enthält das Histogramm für Warteereignisse für Backend- und Hintergrundprozesse, das in 32 Buckets unterteilt ist, von 1 Mikrosekunde bis mehr als 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 | WAL-Statistiken (Write Ahead Log) | Zusammenfassung der WAL-Statistiken. | Wenn die Synchronisierung zu lange dauert, passen Sie die zugehörigen Datenbank-Flags (GUC) an, um die Arbeitslast zu optimieren. 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 ausgeführt werden. | – | |
| Parametereinstellungen | Parametereinstellungen | Wichtige Postgres-Konfigurationsparameter zum Zeitpunkt des End-Snapshots. | Prüfen Sie die Einstellungen für GUC-Parameter (die Postgres-Datenbankflags), um festzustellen, ob die Werte nicht erwartet oder nicht empfohlen werden. |
| Statistiken zur SQL-Ausführung | Informationen pro Abfrage (Top 50) nach insgesamt verstrichener Zeit | Hier werden die 50 Abfragen aufgeführt, für die zwischen den beiden Momentaufnahmen die meiste Zeit verstrichen ist. Außerdem wird die Gesamtzahl der Ausführungen nach Nutzer und Datenbank aufgeschlüsselt, in der die Abfrage ausgegeben wird.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
In diesem Abschnitt können Sie die Abfrage ermitteln, die am meisten Systemzeit in Anspruch nimmt. |
| Informationen pro Abfrage (Top 50) nach Lese-E/A | Listet die 50 wichtigsten Abfragen auf, die während der beiden Snapshots die meiste Lese-E/A-Zeit in Anspruch genommen haben, sowie die Anzahl der Ausführungen, Puffer-Hits und Blk-Lesevorgänge, sowohl insgesamt als auch im Durchschnitt.ReadIO = blk_read_time + temp_blk_read_time während der beiden Snapshots angefallenBuffer Hits = shared_blks_hit + local_blks_hit während der beiden Snapshots angefallenBuffer Reads = shared_blks_read + local_blks_read während der beiden Snapshots angefallenDiese Felder werden standardmäßig von AlloyDB Cloud erfasst, da track_io_timing festgelegt ist. |
In diesem Abschnitt können Sie E/A-intensive Abfragen identifizieren, insbesondere wenn sie häufig Daten von Festplatten lesen müssen. | |
| Informationen pro Abfrage (Top 50) nach Standardabweichung der verstrichenen Zeit | Liste die 50 wichtigsten Anfragen mit der höchsten Standardabweichung der verstrichenen Zeit auf und gib die Standardabweichungen an, die sowohl zum Zeitpunkt des Beginns als auch zum Zeitpunkt des Endes des Snapshots berechnet wurden. Der Wert bezieht sich hier auf stddev_exec_time aus pg_stat_statements. |
Bei Abfragen mit hoher Standardabweichung variiert die Ausführungszeit der Abfrage stark. Möglicherweise ist es an der Zeit, sich die E/A-Vorgänge anzusehen. |
Beschränkungen
Um zu verhindern, dass der Speicherplatz durch übermäßigen Speicherverbrauch zu stark anwächst, können Sie manuell maximal 2.500 Snapshots auf einer Instanz erstellen.
Wenn die Anzahl der Snapshots das Snapshot-Limit überschreitet, löscht AlloyDB 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.
AlloyDB bereinigt regelmäßig manuelle Snapshots, die älter als 90 Tage sind.