Leistungs-Snapshots vergleichen

Wählen Sie eine Dokumentationsversion aus:

In diesem Dokument wird beschrieben, wie Sie Leistungsprobleme in AlloyDB Omni-Datenbanken mithilfe eines Berichts erkennen und beheben können, in dem Snapshots von Systemmesswerten zu zwei verschiedenen Zeitpunkten verglichen werden. Die in jedem Snapshot erfassten Systemmesswerte umfassen die Nutzung der virtuellen CPU (vCPU), die Speichernutzung, die Datenträger-E/A, die Anzahl der Transaktionen und Warteereignisse.

Funktionsweise von Performance Snapshot Reports

Leistungs-Snapshot-Berichte 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 dargestellt. Mithilfe der Informationen im Leistungsübersichtsbericht können Sie Leistungsprobleme mit Ihrer Leistungsübersichtsbericht-Instanz erkennen, z. B. eine verringerte Datenbankleistung zu bestimmten Tageszeiten oder über einen bestimmten Zeitraum.

Im Leistungsübersichtsbericht 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 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 Leistungs-Snapshot-Bericht finden Sie unter Referenz zum Leistungs-Snapshot-Bericht für Datenbanken.

Erforderliche Rollen

Prüfen Sie, ob Sie die Rolle pg_monitor haben. Diese Rolle wird Superusern zugewiesen, die dann anderen Nutzern pg_monitor zuweisen 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 Tool für Leistungssnapshots 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 Rolle „Superuser“, 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 sich ansehen 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 Leistungs-Snapshot-Bericht erhalten haben, können Sie weitere Snapshots erstellen und den Vorgang wiederholen.

  1. psql-Client mit einer AlloyDB-Instanz verbinden
  2. 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 ansehen

  1. psql-Client mit einer AlloyDB-Instanz verbinden
  2. Führen Sie SELECT * FROM perfsnap.g$snapshots aus. 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 beispielsweise einen Bericht erstellen möchten, in dem der Unterschied zwischen Snapshot 1 und Snapshot 2 erfasst wird, führen Sie
SELECT perfsnap.report(1,2) aus.

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.

Der generierte Leistungsübersichtsbericht sieht in etwa so aus:

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

 ----------------------------------------------------
 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 Leistungs-Snapshot-Berichten finden Sie in der Referenz zum Leistungs-Snapshot-Bericht für 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. Nachdem Sie einen Snapshot gelöscht haben, können Sie ihn nicht wiederherstellen.

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.

Datenbankleistung mit Snapshot-Berichtsergebnissen optimieren

So optimieren Sie die Leistung von AlloyDB-Datenbanken:

  1. Erstellen Sie Baseline-Snapshots, wenn Ihre Datenbank im Leerlauf ist oder eine durchschnittliche Last aufweist.
  2. Starten Sie die Arbeitslast oder Abfrage, deren Leistung Sie verbessern möchten.
  3. Erstellen Sie eine weitere Reihe von Snapshots, wenn die Arbeitslast oder Abfrage die maximale Ressourcennutzung erreicht. Wir empfehlen, für beide Berichte dasselbe Intervall zu verwenden.
  4. Vergleichen Sie die Berichte, die Sie mit beiden Snapshot-Sets 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 Leistungs-Snapshot-Berichts und zu Warteereignissen finden Sie unter Referenz zum Leistungs-Snapshot-Bericht für Datenbanken.

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 betriebsbereit ist.
Snapshot-ID Hier werden die ID und der Zeitpunkt der Snapshots aufgeführt, 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, zu einem System mit mehr vCPUs zu wechseln.
Hostspeicher Details zur Hostspeicherauslastung. Wenn der freie Speicherplatz weniger als 15 % beträgt, empfehlen wir, auf die nächstgrößere verfügbare Größe zu skalieren.
Profil laden Hier werden Zähler aufgeführt, mit denen sich Ihre Arbeitslast in Bezug auf generiertes Write-Ahead Logging (WAL), E/A-Anforderungen und Verbindungsverwaltung charakterisieren lässt. Wenn die Anzahl der physischen Lesevorgänge höher ist als die Anzahl der logischen Lesevorgänge, sollten Sie auf die nächste verfügbare Größe hochskalieren, um ein größeres 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 schreiblastig ist.
Informationen zu Datenbankkonflikten Zähler für häufige Anwendungs- und Datenbankprobleme. Suchen Sie nach Problemen in Ihrer Anwendung, wenn ein Deadlock vorliegt.
Datenbank
Informationen zur Dimensionierung
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 nach Problemen in Ihrer Anwendung, wenn das Datenbankwachstum zu groß ist.
Informationen zum Staubsauger Informationen zum Staubsauger Details zu E/A und Zählern für Vakuumvorgänge. Standardmäßig führt AlloyDB adaptives Vacuuming durch. Sie können einige der Vakuum-Einstellungen 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 VACUUM-Befehl pro Datenbank Es werden die folgenden Informationen angezeigt:
  • Aktuelles Alter von datfrozenxid (älteste nicht eingefrorene XIDs) jeder Datenbank oder die Anzahl der Transaktionen von datfrozenxid bis zur XID der aktuellen Transaktion.
  • Anzahl der nicht fixierten Transaktions-IDs, die von allen Transaktions-IDs verwendet wurden.
  • Ergebnis von autovacuum_freeze_max_age - age(pg_database.datfrozenxid), das die ungefähren Alterslücken (in Transaktionen) zum Zeitpunkt des zweiten Snapshots angibt, wenn „autovacuum“ ausgelöst wird, um Wraparounds auf Datenbankebene zu verhindern.
Wenn das Feld „Frozen XID“ zu alt ist oder der Prozentsatz der verarbeiteten Transaktionen nahe 90 % liegt, sollten Sie eine Bereinigung in Betracht ziehen. Wenn sich die aggregierte Vakuumlücke verringert, bedeutet dies, dass Postgres ein Vakuum erzwingt, 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 wal_buffers erhöhen, die für die Datenbank verfügbar sind.
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 µs bis zu mehr als 16 Sekunden. Suchen Sie nach den Warteereignissen und prüfen Sie, ob es zu viele Warteereignisse im größeren Wartezeitbereich gibt. Möglicherweise gibt es ein Problem mit zu vielen Warteereignissen oder mit der jeweils benötigten Wartezeit.
Sonstige Statistiken WAL-Statistiken (Write Ahead Log) Zusammenfassung der WAL-Statistiken. Wenn die Synchronisierung zu lange dauert, passen Sie die entsprechenden 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 GUC-Parametereinstellungen (die Postgres-Datenbankflags), um festzustellen, ob die Werte nicht erwartet oder nicht empfohlen werden.

Beschränkungen

  • Um Speicherplatzverschwendung zu vermeiden, können Sie maximal 2.500 Snapshots auf einer Instanz manuell 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. Damit Sie das Snapshot-Limit nicht ü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