Come funzionano i report snapshot delle prestazioni
I report snapshot delle prestazioni sono uno strumento integrato di AlloyDB Omni che acquisisce e analizza i dati sul rendimento per aiutarti a identificare la causa dei problemi di prestazioni.
I report snapshot delle prestazioni mostrano le metriche del database tra due timestamp in un unico report. Puoi utilizzare le informazioni del report snapshot delle prestazioni per identificare i problemi di prestazioni dell'istanza del report snapshot delle prestazioni, ad esempio un calo delle prestazioni del database in determinati momenti della giornata o un calo delle prestazioni in un determinato periodo di tempo.
Utilizzando il report snapshot delle prestazioni, puoi confrontare le metriche con una baseline delle prestazioni per ottenere insight sulle metriche sul rendimento del workload, che puoi utilizzare per ottimizzare o risolvere i problemi relativi alle prestazioni del database. Una baseline è un insieme personalizzato di snapshot del database che misurano le prestazioni e il comportamento standard di un database per una configurazione e un workload specifici.
Per informazioni sugli eventi di attesa nel report snapshot delle prestazioni, consulta Riferimento per il report snapshot delle prestazioni del database.
Ruoli obbligatori
Assicurati di avere il ruolo pg_monitor.
Questo ruolo viene concesso ai super utenti, che possono poi concedere pg_monitor ad altri utenti.
Ad esempio, postgres è il super utente per impostazione predefinita. Puoi eseguire GRANT pg_monitor TO my_user come postgres per consentire a my_user di utilizzare lo strumento per gli snapshot delle prestazioni come descritto in questo documento.
Installa il report snapshot delle prestazioni
perfsnap è il nome dello schema che contiene le funzioni SQL che consentono agli utenti di acquisire snapshot o generare report. Questo schema fa parte dell'estensione g_stats di AlloyDB Omni. Utilizza il ruolo di super utente per installare il report snapshot delle prestazioni.
Per utilizzare le API perfsnap, connettiti a qualsiasi database in cui gli utenti vogliono installare l'estensione e crea l'estensione g_stats con il seguente comando:
CREATE EXTENSION IF NOT EXISTS g_stats;
Crea uno snapshot delle metriche di sistema
Crea uno snapshot all'inizio e alla fine del workload che ti interessa. L'intervallo di tempo tra i due snapshot consente al workload di progredire in modo che il sistema possa accumulare metriche che riflettono il workload. Dopo aver ottenuto le metriche dal report snapshot delle prestazioni risultante, puoi acquisire un altro insieme di snapshot e ripetere la procedura.
- Connetti un client
psqla un'istanza AlloyDB. Esegui
SELECT perfsnap.snap(). L'output è simile al seguente:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Visualizza un elenco di snapshot
- Connetti un client
psqla un'istanza AlloyDB. Esegui
SELECT * FROM perfsnap.g$snapshots. L'output sarà simile al seguente: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)
Genera un report istantanea
Ad esempio, per generare un report che acquisisca la differenza tra gli snapshot 1 e 2, esegui SELECT perfsnap.report(1,2).
Il secondo snapshot di un'operazione differenziale non deve seguire immediatamente il primo snapshot. Tuttavia, assicurati di acquisire il secondo snapshot nel differenziale dopo il primo snapshot.
Il report snapshot delle prestazioni generato è simile al seguente esempio abbreviato:
Esempio di report snapshot delle prestazioni
$ psql -d postgres -U postgres
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)
Per informazioni sui campi dei report e sui suggerimenti per l'ottimizzazione delle prestazioni del database, consulta Suggerimenti per l'ottimizzazione delle prestazioni del database. Per ulteriori informazioni sugli eventi di attesa nei report snapshot delle prestazioni, consulta Riferimento per il report snapshot delle prestazioni del database.
Elimina uno snapshot
Prima di poter eliminare gli snapshot che fanno parte di una baseline esistente, devi cancellare la baseline .
Per eliminare uno snapshot, esegui SELECT perfsnap.delete(n). Una volta eliminato uno snapshot, non puoi recuperarlo.
Contrassegna uno snapshot come base di riferimento per le prestazioni
Ad esempio, per contrassegnare tutti gli snapshot con ID compresi tra 1 e 3 come baseline delle prestazioni del sistema, esegui SELECT perfsnap.make_baseline(1, 3).
Cancella le baseline delle prestazioni
Ad esempio, per cancellare tutte le baseline con ID compresi tra 1 e 3, esegui
SELECT perfsnap.clear_baseline(1, 3).
Ottimizza le prestazioni del database utilizzando i risultati del report snapshot
Segui questi passaggi per ottimizzare le prestazioni del database AlloyDB:
- Crea snapshot di riferimento quando il database è inattivo o quando è sottoposto a un carico medio.
- Avvia il workload o la query di cui vuoi migliorare le prestazioni.
- Quando il workload o la query raggiungono l'utilizzo massimo delle risorse, crea un altro set di snapshot. Ti consigliamo di utilizzare lo stesso intervallo per entrambi i report.
- Confronta i report che hai creato con entrambi i set di istantanee e identifica le modifiche che potrebbero migliorare le prestazioni. Per ulteriori informazioni sui suggerimenti per le prestazioni, consulta Suggerimenti per l'ottimizzazione delle prestazioni del database.
Suggerimenti per l'ottimizzazione delle prestazioni del database
La tabella seguente elenca le sezioni del report snapshot delle prestazioni e i miglioramenti consigliati per ogni sezione del report. Per ulteriori informazioni sulle sezioni del report snapshot delle prestazioni e sugli eventi di attesa, consulta Riferimento per il report snapshot delle prestazioni del database.
| Sezione | Campo report | Descrizione dei campi contenuti nei report | Consigli di ottimizzazione |
|---|---|---|---|
| Dettagli snapshot | Dettagli snapshot | Fornisce l'host, la versione di release compatibile con PostgreSQL e l'ora in cui la macchina è attiva e funzionante. | N/D |
| ID snapshot | Elenca l'ID e il momento specifico degli snapshot utilizzati per creare questo report. | N/D | |
| Insight sul sistema | CPU host | Dettagli sull'utilizzo della CPU host. | Se l'utilizzo della CPU è superiore all'80%, ti consigliamo di passare a un sistema con più vCPU. |
| Memoria host | Dettagli sull'utilizzo della memoria host. | Se la memoria libera è inferiore al 15%, ti consigliamo di fare lo scale up alla dimensione disponibile successiva. | |
| Carica profilo | Elenca i contatori che aiutano a caratterizzare il workload in termini di Write-Ahead Logging (WAL) generato, requisiti di I/O e gestione delle connessioni. | Se le letture fisiche sono superiori a quelle logiche, valuta la possibilità di fare lo scale up alla dimensione successiva disponibile per supportare una memorizzazione nella cache dei dati più grande. | |
| Suddivisione del tempo di risposta e della classe di attesa | Suddivisione del tempo impiegato dai processi Postgres durante l'esecuzione del workload. | Ad esempio, se i processi sono per lo più in stato di attesa, concentrati sulla riduzione dell'attesa I/O. | |
| Informazioni sul workload del database | Informazioni sul workload per database | Metriche chiave per ogni database, tra cui commit, rollback, rapporto di hit e informazioni su tabelle temporanee e operazioni di ordinamento. | Se i rollback sono elevati, ti consigliamo di eseguire la diagnostica dell'app. |
| Informazioni su DML e DQL per database | Contatori per le operazioni di query. | Qualifica il tuo workload come ad alta intensità di lettura o di scrittura. | |
| Informazioni sui conflitti del database | Contatori per problemi comuni relativi ad applicazioni e database. | Individuare i problemi nell'applicazione in caso di deadlock. | |
| Informazioni sul dimensionamento del database |
Mostra di quanto è cresciuto il database nell'intervallo tra due snapshot. Questo campo mostra anche se per il database sono stati stabiliti limiti di connessione. | Individua i problemi nell'applicazione se la crescita del database è troppo elevata. | |
| Informazioni sull'aspirapolvere | Informazioni sull'aspirapolvere | Dettagli di I/O e contatori per le operazioni di vacuum. | Per impostazione predefinita, AlloyDB esegue il vacuuming adattivo. Puoi eseguire l'override di alcune impostazioni di vacuum in base al tuo workload. Ad esempio, riduci le operazioni di vacuum se viene impiegato troppo I/O per queste richieste. |
| Informazioni sul vacuum per database | Mostra le seguenti informazioni:
|
Se l'età del campo XID bloccato è troppo vecchia o se la percentuale di transazioni consumate è vicina al 90%, valuta la possibilità di eseguire il vacuuming. Se il gap di vacuum aggregato diminuisce, significa che verrà applicato un vacuum da Postgres per impedire il wraparound. | |
| Dettagli sull'attesa dei processi del database | Informazioni dettagliate su backend e processi in background di |
Dettagli di tutte le attese dei processi di backend e in background nell'intervallo del report. Le informazioni includono il tempo di attesa cumulativo, il tempo di CPU e il tempo medio per tipo di attesa. | Ad esempio, per ridurre l'attesa su WALWrite, aumenta il numero di
wal_buffers disponibili per il database. |
| Istogramma dettagliato degli eventi di attesa di backend e in background | Questo è incluso nel report snapshot delle prestazioni per impostazione predefinita. L'elenco contiene l'istogramma degli eventi di attesa per i processi di backend e in background, suddivisi in 32 bucket, da 1 us a più di 16 secondi. | Individua gli eventi di attesa e determina se sono presenti troppi eventi di attesa nel bucket dei tempi di attesa più grandi. Potrebbe esserci un problema con un numero eccessivo di eventi di attesa o con il tempo di attesa consumato. | |
| Statistiche varie | Statistiche del log WAL (Write Ahead Log) | Riepilogo delle statistiche WAL. | Se il tempo di sincronizzazione è troppo lungo, modifica i flag di database (GUC) correlati per migliorare il workload. GUC è il sottosistema PostgreSQL che gestisce la configurazione del server. |
| Statistiche di riepilogo (in tutti i database) | Riepilogo di tutte le operazioni del database che si verificano durante l'intervallo dello snapshot. | N/D | |
| Impostazioni parametro | Impostazioni parametro | Parametri di configurazione chiave di Postgres al momento dello snapshot finale. | Controlla le impostazioni dei parametri GUC (i flag di database Postgres) per determinare se i valori non sono previsti o non sono consigliati. |
Limitazioni
Per evitare un aumento eccessivo dello spazio, puoi creare manualmente un massimo di 2500 snapshot su un'istanza. Il gonfiore dello spazio garantisce che gli snapshot non occupino troppo spazio di archiviazione nel database.
Se il numero di snapshot supera il limite, AlloyDB Omni elimina tutti gli snapshot manuali più vecchi di 90 giorni. Per non superare il limite di snapshot, devi eliminare gli snapshot non necessari prima di acquisirne uno nuovo.
AlloyDB Omni pulisce periodicamente gli snapshot manuali più vecchi di 90 giorni.
Passaggi successivi
- Scopri di più sugli eventi di attesa nei report snapshot delle prestazioni.