Confrontare le istantanee del rendimento

Seleziona una versione della documentazione:

Questo documento descrive come identificare e mitigare i problemi di rendimento del database AlloyDB Omni utilizzando un report che confronta gli snapshot delle metriche di sistema tra due diversi momenti nel tempo. 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.

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 rendimento.

I report snapshot delle prestazioni mostrano le metriche del database tra due timestamp in un unico report. Puoi utilizzare le informazioni del report sull'istantanea del rendimento per identificare i problemi di rendimento dell'istanza del report sull'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 sull'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 avere il ruolo pg_monitor. Questo ruolo viene concesso ai superuser, che possono poi concedere pg_monitor ad altri utenti.

Ad esempio, postgres è il superutente per impostazione predefinita. Puoi eseguire GRANT pg_monitor TO my_user come postgres per consentire a my_user di utilizzare lo strumento di snapshot del rendimento come descritto in questo documento.

Report snapshot delle prestazioni delle installazioni

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 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 workload di avanzare in modo che il sistema possa accumulare metriche che riflettono il workload. Dopo aver ottenuto le metriche dal report dell'istantanea del rendimento risultante, puoi acquisire un altro insieme di snapshot e ripetere la procedura.

  1. Connetti un client psql a un'istanza AlloyDB.
  2. Esegui SELECT perfsnap.snap(). L'output è simile al seguente:

    postgres=# select perfsnap.snap();
     snap
    ------
        1
    (1 row)
    

Visualizzare un elenco di snapshot

  1. Connetti un client psql a un'istanza AlloyDB.
  2. 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 acquisisca 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 seguire immediatamente il primo snapshot. Tuttavia, assicurati di acquisire il secondo snapshot nel differenziale dopo il primo snapshot.

Il report sul rendimento generato è simile al seguente esempio abbreviato:

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

 ----------------------------------------------------
 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 del rendimento, consulta Riferimento al report sugli snapshot del rendimento 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). 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).

Ottimizzare le prestazioni del database utilizzando i risultati del report snapshot

Segui questi passaggi per ottimizzare il rendimento del database AlloyDB:

  1. Crea snapshot di riferimento quando il database è inattivo o quando sta registrando un carico medio.
  2. Avvia il workload o la query di cui vuoi migliorare le prestazioni.
  3. 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.
  4. 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 consigli sul rendimento, vedi Consigli 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 dell'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 dell'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 caratterizzare il carico di lavoro in termini di Write-Ahead Logging (WAL) generato, requisiti di I/O e gestione delle connessioni. Se le letture fisiche sono superiori alle letture 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 ampia.
Informazioni sull'aspirapolvere Informazioni sull'aspirapolvere Dettagli di I/O e contatori per le operazioni di pulizia. Per impostazione predefinita, AlloyDB esegue la pulizia adattiva. Puoi eseguire l'override di alcune impostazioni dell'aspirapolvere per adattarle al tuo carico di lavoro. Ad esempio, riduci le operazioni di pulizia se viene utilizzato troppo I/O per queste richieste.
Informazioni sul vacuum per database Mostra le seguenti informazioni:
  • Età attuale di datfrozenxid (XID meno recenti non bloccati) di ogni database o il numero di transazioni da datfrozenxid all'XID della transazione attuale.
  • ID transazione scongelati consumati su tutti gli ID transazione.
  • Risultato di autovacuum_freeze_max_age - age(pg_database.datfrozenxid), che indica le lacune approssimative di età (in transazioni) al secondo momento dello snapshot, quando autovacuum viene attivato per evitare wraparound a livello aggregato del database.
Se l'età del campo XID congelato è troppo elevata o se la percentuale di transazioni consumate è vicina al 90%, valuta la possibilità di eseguire il vacuum. Se lo spazio vuoto di vacuum aggregato diminuisce, significa che Postgres imporrà un vacuum per evitare il wraparound.
Dettagli attesa processi database Informazioni dettagliate sul backend e sui
processi in background
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 di 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, che sono 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 troppi 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 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.

Limitazioni

  • Per evitare un eccessivo utilizzo dello spazio, puoi creare manualmente un massimo di 2500 snapshot su un'istanza. L'espansione 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 rimanere entro il limite di snapshot, devi eliminare quelli non necessari prima di acquisirne uno nuovo.

  • AlloyDB Omni esegue periodicamente la pulizia degli snapshot manuali più vecchi di 90 giorni.

Passaggi successivi