Questo documento descrive come identificare e mitigare i problemi di rendimento del database AlloyDB Omni utilizzando un report che confronta gli istantanei delle metriche di sistema tra due diversi punti nel tempo. Le metriche di sistema acquisite in ogni scatto istantaneo includono l'utilizzo della CPU virtuale (vCPU), l'utilizzo della memoria, l'I/O del disco, il conteggio delle transazioni e gli eventi di attesa.
Come funzionano i report snapshot delle prestazioni
I report Istantanea del rendimento sono uno strumento integrato di AlloyDB Omni che acquisisce e analizza i dati sul rendimento per aiutarti a identificare la causa dei problemi di rendimento. Questo strumento integra altre funzionalità di osservabilità di AlloyDB Omni, come gli approfondimenti sui sistemi, gli approfondimenti sulle query e Metrics Explorer, che forniscono metriche in tempo reale sulla tua istanza.
I report snapshot delle prestazioni mostrano le metriche del database tra due timestamp in un unico report. Puoi utilizzare le informazioni del report Istantanea del rendimento per identificare i problemi di rendimento dell'istanza del report Istantanea del rendimento, ad esempio la diminuzione del rendimento del database in determinati momenti della giornata o la diminuzione del rendimento in un determinato periodo di tempo.
Utilizzando il report Istantanea del rendimento, puoi confrontare le metriche con un valore di riferimento per ottenere informazioni sulle metriche sul rendimento del carico di lavoro, che puoi utilizzare per ottimizzare o risolvere i problemi relativi al rendimento del database. Un valore di riferimento è un insieme personalizzato di istantanee del database che misurano le prestazioni e il comportamento standard di un database per una configurazione e un carico di lavoro specifici.
Per informazioni sugli eventi di attesa nel report snapshot delle prestazioni, consulta Informazioni di riferimento sul report snapshot delle prestazioni del database.
Ruoli obbligatori
Assicurati di avere il ruolo alloydbsuperuser.
Per impostazione predefinita, AlloyDB concede il ruolo pg_monitor a
alloydbsuperuser. Per ulteriori informazioni, consulta
Ruoli predefiniti di PostgreSQL.
Se preferisci utilizzare altri ruoli definiti autonomamente, esegui prima GRANT pg_monitor TO my_user come alloydbsuperuser. Per ulteriori informazioni, consulta Aggiornare un account Identity and Access Management (IAM) con il ruolo appropriato.
Installare il report Istantanea report sulle 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 AlloyDB Omni g_stats. Utilizza il ruolo superutente 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 carico di lavoro di progredire in modo che il sistema possa accumulare metriche che riflettano il carico di lavoro. Dopo aver ottenuto le metriche dal report sull'istantanea del rendimento risultante, puoi acquisire un altro insieme di istantanee 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)
Visualizzare un elenco di istantanee
- Connetti un client
psqla un'istanza AlloyDB Omni. Esegui
SELECT * FROM perfsnap.g$snapshots. L'output è 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)
Generare un report snapshot
Per generare un report che catturi la differenza tra gli snapshot 1
e 2, ad esempio, esegui SELECT perfsnap.report(1,2).
Il secondo snapshot in un'operazione differenziale non deve necessariamente seguire immediatamente il primo. Tuttavia, assicurati di acquisire il secondo snapshot nel differenziale dopo il primo snapshot.
Il report sull'istantanea del rendimento generato è simile al seguente esempio abbreviato:
Report di esempio sugli snapshot delle prestazioni
$ 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)
Per informazioni sui campi dei report e sui consigli per l'ottimizzazione delle prestazioni, consulta Consigli per l'ottimizzazione delle prestazioni del database. Per ulteriori informazioni sugli eventi di attesa nei report sugli snapshot del rendimento, consulta Informazioni di riferimento sul report sugli snapshot del rendimento del database.
Elimina uno snapshot
Prima di poter eliminare gli snapshot che fanno parte di un baseline esistente, devi cancellare il baseline .
Per eliminare uno snapshot, esegui SELECT perfsnap.delete(n). Una volta eliminato, un
screenshot non può essere recuperato.
Contrassegnare un'istantanea come base di riferimento per il rendimento
Per contrassegnare tutti gli snapshot con ID compresi tra 1 e 3, ad esempio, come base di riferimento per le prestazioni del sistema, esegui SELECT perfsnap.make_baseline(1, 3).
Basi di riferimento chiare sul rendimento
Per cancellare tutte le linee di base con ID compresi tra 1 e 3, ad esempio, esegui
SELECT perfsnap.clear_baseline(1, 3).
Ottimizzare le prestazioni del database utilizzando i risultati del report snapshot
Per ottimizzare il rendimento del database AlloyDB, segui questi passaggi:
- Crea snapshot di riferimento quando il database è inattivo o quando registra un carico medio.
- Avvia il carico di lavoro o la query di cui vuoi migliorare le prestazioni.
- Quando il carico di lavoro o la query raggiunge il picco di utilizzo delle risorse, crea un altro insieme di snapshot. Ti consigliamo di utilizzare lo stesso intervallo per entrambi i report.
- Confronta i report che hai creato con entrambi gli insiemi di istantanee e identifica le modifiche che potrebbero migliorare il rendimento. Per ulteriori informazioni sui consigli sul rendimento, consulta Consigli per l'ottimizzazione del rendimento del database.
Consigli per l'ottimizzazione delle prestazioni del database
La tabella seguente elenca le sezioni del report Istantanea sul rendimento e i miglioramenti consigliati per ogni sezione. Per ulteriori informazioni sulle sezioni del report sugli snapshot del rendimento e sugli eventi di attesa, consulta la sezione Informazioni di riferimento sul report sugli snapshot del rendimento del database.
| Sezione | Campo del report | Descrizione del campo del report | Consigli di ottimizzazione |
|---|---|---|---|
| Dettagli snapshot | Dettagli snapshot | Fornisce l'host, la versione della release compatibile con PostgreSQL e l'ora in cui la macchina è in esecuzione. | N/D |
| ID snapshot | Elenca l'ID e il momento in cui sono stati acquisiti gli snapshot utilizzati per creare questo report. | N/D | |
| Insight sul sistema | CPU host | Dettagli sull'utilizzo della CPU dell'host. | Se l'utilizzo della CPU è superiore all'80%, ti consigliamo di passare a un sistema con più vCPU. |
| Memoria dell'host | Dettagli sull'utilizzo della memoria dell'host. | Se la memoria libera è inferiore al 15%, ti consigliamo di eseguire lo scaling fino alla dimensione successiva disponibile. | |
| Profilo di carico | Elenca i contatori che aiutano a caratterizzare il carico di lavoro in termini di logging Write-Ahead (WAL) generato, requisiti I/O e gestione delle connessioni. | Se le letture fisiche sono superiori a quelle logiche, valuta la possibilità di eseguire lo scaling up fino alla dimensione successiva disponibile per supportare una memorizzazione nella cache più grande dei dati. | |
| Analisi dettagliata dei tempi di risposta e delle classi di attesa | Suddivisione del tempo impiegato dai processi Postgres durante l'esecuzione del workload. | Ad esempio, concentrati sulla riduzione del tempo di attesa I/O se i processi sono principalmente in stato di attesa. | |
| Informazioni sul carico di lavoro del database | Informazioni sul carico di lavoro per database | Metriche chiave per ogni database, inclusi commit, rollback, rapporto di hit e informazioni su tabelle temporanee e operazioni di ordinamento. | Se i rollback sono elevati, valuta la possibilità di diagnosticare l'app. |
| Informazioni su DML e DQL per database | Contatori per le operazioni di query. | Classifica il tuo carico di lavoro come con un'elevata intensità di lettura o di scrittura. | |
| Informazioni sui conflitti del database | Contatori per problemi comuni relativi ad applicazioni e database. | Individua i problemi nella tua applicazione se si verifica un deadlock. | |
| Informazioni sul dimensionamento del database |
Mostra quanto è cresciuto il database durante l'intervallo tra due screenshot. Questo campo mostra anche se sono stati stabiliti limiti di connessione per il database. | Individua i problemi nella tua applicazione se la crescita del database è troppo elevata. | |
| Informazioni sull'aspirapolvere | Informazioni sull'aspirapolvere | Dettagli di I/O e contatori per le operazioni di aspirazione. | Per impostazione predefinita, AlloyDB esegue l'evacuazione adattiva. Puoi eseguire l'override di alcune impostazioni di eliminazione per adattarle al tuo carico di lavoro. Ad esempio, riduci le operazioni di svuotamento se viene utilizzata troppa I/O per queste richieste. |
| Informazioni per il sottovuoto del database | Mostra le seguenti informazioni:
|
Se la data del campo XID congelato è troppo vecchia o se la percentuale di transazioni consumate è vicina al 90%, valuta la possibilità di eseguire il 'evacuazione". Se la distanza vuota aggregata diminuisce, significa che Postgres applicherà un vuoto per impedire il wrapping. | |
| Dettagli sull'attesa dei processi del database | Informazioni dettagliate sul backend e sui processi in background |
Dettagli di tutte le attese per i 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. | Per ridurre il tempo di attesa su WALWrite, ad esempio, aumenta il numero di
wal_buffers disponibili per il database. |
| Istogramma dettagliato degli eventi di attesa in background e nel backend | Questo valore è incluso nel report Istantanea del rendimento per impostazione predefinita. L'elenco contiene l'istogramma degli eventi di attesa per i processi di backend e in background, che sono suddivisi in 32 bucket, da 1 μs a più di 16 secondi. | Individua gli eventi di attesa e determina se ce ne sono troppi nel bucket del tempo di attesa più grande. Potrebbe esserci un problema con troppi eventi di attesa o con ogni tempo di attesa consumato. | |
| Statistiche varie | Statistiche del log Write Ahead (WAL) | Riepilogo delle statistiche WAL. | Se il tempo di sincronizzazione è troppo lungo, modifica i flag (GUC) del database correlati per migliorare il tuo carico di lavoro. 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 dell'snapshot. | N/D | |
| Impostazioni parametro | Impostazioni parametro | Parametri di configurazione di Postgres principali al momento dello snapshot finale. | Controlla le impostazioni dei parametri GUC (i flag del 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 una istanza. La funzionalità Space bloat (Aumento inutilmente 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 precedenti a 90 giorni. Per rispettare il limite di snapshot, devi eliminare gli snapshot non necessari prima di crearne uno nuovo.
AlloyDB Omni esegue periodicamente la pulizia degli snapshot manuali risalenti a più di 90 giorni fa.
Passaggi successivi
- Scopri di più sugli eventi di attesa nei report Istantanea sul rendimento.