Questo documento descrive come generare manualmente report di snapshot del rendimento, che consentono di confrontare gli snapshot delle metriche di sistema tra due momenti nel tempo. Puoi utilizzare i report snapshot delle prestazioni per identificare e mitigare i problemi di prestazioni del database AlloyDB per PostgreSQL. Le metriche di sistema acquisite in ogni snapshot 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.
Snapshot automatici e manuali
AlloyDB supporta i seguenti snapshot:
Snapshot automatici:per impostazione predefinita, AlloyDB acquisisce automaticamente gli snapshot una volta al giorno e li archivia per 7 giorni. Gli snapshot automatici consentono di generare report con granularità giornaliera del carico di lavoro. Non puoi modificare la conservazione di uno snapshot automatico, ma puoi configurare la frequenza.
Snapshot manuali:puoi acquisire manualmente snapshot e generare report.
Puoi combinare snapshot automatici e manuali per generare report sul rendimento. Ad esempio, puoi generare un report snapshot sul rendimento che confronta uno snapshot generato manualmente con uno snapshot automatico.
Questo documento descrive come generare manualmente i report sugli snapshot del rendimento.
Come funzionano i report snapshot delle prestazioni
I report snapshot delle prestazioni sono uno strumento integrato di AlloyDB 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, come approfondimenti sul sistema, 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 un rendimento del database ridotto in determinati orari del giorno o un rendimento ridotto in un determinato periodo di tempo.
Utilizzando il report Istantanea del rendimento, puoi confrontare le metriche con una baseline del rendimento per ottenere informazioni sulle metriche sul rendimento del workload, che puoi utilizzare per ottimizzare o risolvere i problemi relativi al rendimento 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 carico di lavoro specifici.
Per informazioni sugli eventi di attesa nel report snapshot delle prestazioni, vedi Riferimento al report snapshot delle prestazioni del database.
Ruoli obbligatori
Assicurati di disporre del ruolo alloydbsuperuser.
Per impostazione predefinita, AlloyDB concede il ruolo pg_monitor a
alloydbsuperuser. Per ulteriori informazioni, consulta
Ruoli predefiniti di PostgreSQL.
Se preferisci utilizzare gli altri ruoli definiti autonomamente, esegui
GRANT pg_monitor TO my_user come alloydbsuperuser. Per saperne di più, consulta Aggiornare un account Identity and Access Management (IAM) con il ruolo appropriato.
Creare snapshot
Gli snapshot delle prestazioni sono uno strumento potente per comprendere e ottimizzare le prestazioni del database. Acquisiscono le metriche chiave del sistema in un momento specifico, consentendoti di confrontare il rendimento del tuo database tra due momenti. AlloyDB supporta due tipi di snapshot:
- Snapshot delle metriche di sistema:questi snapshot acquisiscono metriche di sistema chiave come utilizzo di vCPU, utilizzo della memoria e I/O del disco.
- Snapshot delle metriche di sistema e delle statistiche di esecuzione SQL:questi snapshot contengono tutte le metriche di sistema di uno snapshot standard, oltre a statistiche dettagliate di esecuzione SQL dall'estensione
pg_stat_statements.
In questo modo, puoi scegliere il livello di dettaglio necessario per la tua analisi.
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 deve essere sufficientemente lungo da acquisire un campione rappresentativo del workload.
Segui questi passaggi per ottimizzare il rendimento del database AlloyDB:
- Crea snapshot di riferimento quando il database è inattivo o quando registra un carico medio.
- Connetti un client
psqla un'istanza AlloyDB. Esegui
SELECT perfsnap.snap(). L'output è simile al seguente:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)L'output di questo comando restituisce l'ID snapshot (
snap_id), che in questo esempio è1. Avrai bisogno di questo ID per generare in un secondo momento un report snapshot sul rendimento. Ilsnap_idnel tuo ambiente è probabilmente diverso.Confronta i report che hai creato con entrambi i set di snapshot e identifica le modifiche che potrebbero migliorare il rendimento. Per ulteriori informazioni sui suggerimenti per il rendimento, consulta Suggerimenti per l'ottimizzazione del rendimento del database.
Dopo aver ottenuto le metriche dal report di snapshot del rendimento risultante, puoi acquisire un altro insieme di snapshot e ripetere la procedura.
Crea uno snapshot che contenga le statistiche di esecuzione SQL
Per impostazione predefinita, AlloyDB utilizza l'estensione pg_stat_statements per monitorare le istruzioni SQL. Per includere statistiche dettagliate sull'esecuzione di SQL nel report sul rendimento, devi prima creare l'estensione pg_stat_statements nel database postgres. Tieni presente che l'acquisizione di queste statistiche è attivata dal flag pg_stat_statements.track, non dalla creazione dell'estensione stessa.
Per creare uno snapshot che contenga anche le statistiche di esecuzione SQL:
- Crea l'estensione
pg_stat_statementsnel databasepostgres.postgres=# CREATE EXTENSION pg_stat_statements;
- Ora, quando acquisisci uno snapshot, questo include automaticamente le statistiche SQL di
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Visualizzare un elenco di snapshot
- Connetti un client
psqla un'istanza AlloyDB. - 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 delle prestazioni
Per generare un report che acquisisca la differenza tra due snapshot, ad esempio gli snapshot 1 e 2, esegui:SELECT perfsnap.report(1,2)
Il secondo snapshot in un'operazione differenziale non deve seguire immediatamente il primo snapshot. Tuttavia, assicurati di acquisire il secondo snapshot nel differenziale dopo il primo snapshot.
Rapporto di esempio
Di seguito è riportato un esempio abbreviato di un report snapshot delle prestazioni generato:
Report snapshot delle prestazioni di esempio
$ 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)
Per informazioni sui campi dei report e sui consigli per l'ottimizzazione del rendimento, vedi Consigli per l'ottimizzazione del rendimento del database. Per ulteriori informazioni sugli eventi di attesa nei report sugli snapshot delle prestazioni, consulta Riferimento al report sugli 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 questo comando:
SELECT perfsnap.delete(SNAP_ID);
Sostituisci SNAP_ID con l'ID dello snapshot che vuoi eliminare.
Dopo aver eliminato uno snapshot, non puoi recuperarlo.
Contrassegnare uno snapshot come base di riferimento del rendimento
Per contrassegnare tutti gli snapshot con ID compresi tra 1 e 3, ad esempio, come baseline delle prestazioni del sistema, esegui SELECT perfsnap.make_baseline(1, 3).
Cancella le baseline del rendimento
Per cancellare tutte le baseline con ID compresi tra 1 e 3, ad esempio, esegui
SELECT perfsnap.clear_baseline(1, 3).
Modificare la frequenza degli snapshot automatici
Per personalizzare la frequenza degli snapshot automatici, imposta il flag perfsnap.interval,
che imposta l'intervallo di snapshot automatico in secondi. Per saperne di più, consulta Configura i flag di database.
Ti consigliamo di impostare il valore del flag almeno superiore a diversi minuti per acquisire informazioni significative.
Per evitare di sprecare risorse, quando non hai più bisogno della frequenza personalizzata, reimposta il flag sul valore predefinito (secondi al giorno).
Ottimizzare le prestazioni del database utilizzando i risultati del report snapshot
Segui questi passaggi per ottimizzare il rendimento del database AlloyDB:
- Crea snapshot di riferimento quando il database è inattivo o quando sta registrando un carico medio.
- Avvia il workload 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 i set di snapshot e identifica le modifiche che potrebbero migliorare il rendimento. Per ulteriori informazioni sui suggerimenti per il rendimento, consulta Suggerimenti per l'ottimizzazione del rendimento del database.
Consigli per l'ottimizzazione delle prestazioni del database
La tabella seguente elenca le sezioni del report Riepilogo del rendimento 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 Documentazione di riferimento del report snapshot delle prestazioni del database.
| Sezione | Campo report | Descrizione del campo del report | Consigli di ottimizzazione |
|---|---|---|---|
| Dettagli snapshot | Dettagli snapshot | Fornisce l'host, la versione di rilascio compatibile con PostgreSQL e l'ora in cui la macchina è in funzione. | N/D |
| ID snapshot | Elenca l'ID e il momento nel tempo 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 eseguire lo scale up alla dimensione successiva disponibile. |
| Memoria host | Dettagli sull'utilizzo della memoria host. | Se la memoria libera è inferiore al 15%, ti consigliamo di eseguire lo scale up alla dimensione successiva disponibile. | |
| Carica profilo | Elenca i contatori che aiutano a qualificare il workload di Write-Ahead Logging (WAL) generato, i requisiti di I/O e la gestione delle connessioni. | Se le letture fisiche sono superiori a quelle logiche, valuta la possibilità di eseguire lo scale up alla dimensione successiva disponibile per supportare una memorizzazione nella cache più ampia dei dati. | |
| Tempo di risposta e suddivisione della classe di attesa | Suddivisione del tempo trascorso dai processi Postgres durante l'esecuzione del workload. | Concentrati sull'ottimizzazione per ridurre l'attesa I/O se i processi sono principalmente in stato di attesa, ad esempio. | |
| Informazioni sul workload del database | Informazioni sul workload per database | Metriche chiave per ogni database, inclusi commit, rollback, hit ratio e informazioni su tabelle temporanee e operazioni di ordinamento. | Se i rollback sono elevati, valuta la possibilità di diagnosticare la tua 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 scrittura. | |
| Informazioni sui conflitti del database | Contatori per problemi comuni di applicazioni e database. | Individua i problemi nella tua applicazione in caso di deadlock. | |
| Informazioni sul dimensionamento del database | Mostra la crescita del database durante l'intervallo tra due snapshot. 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 vuoto. | Per impostazione predefinita, AlloyDB esegue la pulizia adattiva. Puoi eseguire l'override di alcune impostazioni di pulizia per adattarle al tuo carico di lavoro. Ad esempio, riduci le operazioni di vacuum se viene utilizzato troppo I/O per queste richieste. |
| Informazioni sul vacuum per database | Mostra le seguenti informazioni:
|
Se l'età del campo XID bloccato è troppo elevata o se la percentuale di transazioni utilizzate è vicina al 90%, valuta la possibilità di eseguire il vacuum. Se lo spazio vuoto aggregato diminuisce, significa che Postgres applicherà un vuoto per impedire il wraparound. | |
| Dettagli attesa processi database | Informazioni dettagliate sui processi in background e sul backend | Dettagli di tutte le attese per backend e processi 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 l'attesa per WALWrite, ad esempio, aumenta il numero di wal_buffers disponibili per il database. |
| Istogramma dettagliato degli eventi di attesa del backend e in background | Questi dati sono inclusi per impostazione predefinita nel report Istantanea del rendimento. L'elenco contiene l'istogramma degli eventi di attesa per i processi di backend e in background, suddivisi in 32 bucket, da 1 microsecondo a più di 16 secondi. | Individua gli eventi di attesa e determina se ce ne sono troppi nel bucket del tempo di attesa più lungo. Potrebbe esserci un problema con un numero eccessivo di eventi di attesa o con ogni tempo di attesa consumato. | |
| Statistiche varie | Statistiche del log Write Ahead (WAL) | Riepilogo delle statistiche WAL. | Se riscontri tempi di sincronizzazione troppo lunghi, modifica i flag del database correlati (GUC) per migliorare il tuo workload. GUC è il sottosistema PostgreSQL che gestisce la configurazione del server. |
| Statistiche riepilogative (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 dell'ultimo snapshot. | Controlla le impostazioni dei parametri GUC (i flag del database Postgres) per determinare se i valori non sono previsti o non sono consigliati. |
| Statistiche di esecuzione SQL | Informazioni per query (prime 50) in base al tempo totale trascorso | Elenca le prime 50 query che hanno impiegato più tempo durante i due snapshot, nonché il conteggio totale delle esecuzioni, suddiviso per utente e database in cui viene emessa la query.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
Utilizza questa sezione per identificare la query più pesante che richiede la maggior parte del tempo di sistema. |
| Informazioni per query (prime 50) per I/O di lettura | Elenca le 50 query che hanno utilizzato più tempo di I/O di lettura durante i due snapshot, nonché il numero di esecuzioni, gli hit del buffer e le letture di blocchi, sia in totale che in media.ReadIO = blk_read_time + temp_blk_read_time accumulato durante i due snapshotBuffer Hits = shared_blks_hit + local_blks_hit accumulato durante i due snapshotBuffer Reads = shared_blks_read + local_blks_read accumulato durante i due snapshotQuesti campi vengono monitorati per impostazione predefinita da AlloyDB Cloud poiché è impostato track_io_timing. |
Utilizza questa sezione per identificare le query con I/O elevato, soprattutto se devono leggere frequentemente dai dischi. | |
| Informazioni per query (prime 50) in base alla deviazione standard del tempo trascorso | Elenca le 50 query con la deviazione standard più elevata del tempo trascorso, elencando le deviazioni standard calcolate sia all'inizio che alla fine dell'istantanea. Qui il valore fa riferimento a stddev_exec_time da pg_stat_statements |
Per le query con deviazione standard elevata, il tempo di esecuzione della query varia molto e potrebbe essere il momento di esaminare l'I/O. |
Limitazioni
Per evitare l'aumento dello spazio dovuto a un consumo eccessivo di spazio di archiviazione, puoi creare manualmente un massimo di 2500 snapshot su un'istanza.
Se il numero di snapshot supera il limite, AlloyDB elimina tutti gli snapshot manuali più vecchi di 90 giorni. Per rimanere entro il limite di snapshot, devi eliminare quelli non necessari prima di acquisirne uno nuovo.
AlloyDB esegue periodicamente la pulizia degli snapshot manuali che risalgono a più di 90 giorni fa.
Passaggi successivi
- Scopri di più sugli eventi di attesa nei report sugli snapshot delle prestazioni.