Questa pagina descrive come monitorare le prestazioni del database AlloyDB Omni utilizzando gli script di osservabilità di PostgreSQL.
Visualizza lo stato dei processi connessi e degli eventi di attesa
Puoi determinare tutti i processi connessi alla tua istanza AlloyDB Omni e tutti i backend in attesa di attività eseguendo una query sulla vista pg_stat_activity.
SELECT
pid,
datname,
age(backend_xid) AS age_in_xids,
now() - xact_start AS xact_age,
now() - query_start AS query_age,
state,
wait_event_type,
wait_event,
query_id,
query
FROM
pg_stat_activity
WHERE
state != 'idle'
AND pid <> pg_backend_pid()
ORDER BY
4 DESC
LIMIT 10;
Visualizza le tabelle più grandi
Puoi determinare le dimensioni delle tabelle più grandi eseguendo una query sulla vista pg_stat_user_tables.
SELECT
oid,
oid::regclass table_name,
pg_size_pretty(pg_relation_size(oid)),
relpages,
s.seq_scan,
s.idx_scan
FROM
pg_class,
pg_stat_user_tables s
WHERE
s.relid = oid
AND oid > 16383
AND relpages > 100
AND relkind = 'r'
ORDER BY
relpages DESC
LIMIT 20;
Visualizza le scansioni sequenziali principali
Puoi visualizzare le principali scansioni sequenziali eseguendo una query sulla vista pg_stat_user_tables.
SELECT
relid,
relname,
seq_scan,
pg_size_pretty(pg_relation_size(relid))
FROM
pg_stat_user_tables
ORDER BY
seq_scan DESC
LIMIT 15;
Visualizza le scansioni degli indici principali
Puoi visualizzare le scansioni dell'indice principali eseguendo una query sulla vista pg_stat_user_tables.
SELECT
relid,
relid::regclass table_name,
idx_scan,
pg_size_pretty(pg_relation_size(relid))
FROM
pg_stat_user_tables
WHERE
idx_scan > 10
ORDER BY
idx_scan DESC
LIMIT 15;
Visualizza le transazioni in esecuzione da più tempo
Puoi visualizzare le transazioni in esecuzione da più tempo eseguendo una query sulla vista pg_stat_activity e controllando l'età della transazione.
SELECT
pid,
age(backend_xid) AS age_in_xids,
now() - xact_start AS xact_age,
now() - query_start AS query_age,
state,
query
FROM
pg_stat_activity
WHERE
state != 'idle'
ORDER BY
2 DESC
LIMIT 10;
Controlla l'avanzamento dell'aspirapolvere
Puoi controllare l'avanzamento delle operazioni di vacuum eseguendo una query sulla vista pg_stat_progress_vacuum e unendola alla vista pg_stat_activity utilizzando gli ID di processo.
SELECT
p.pid,
now() - a.xact_start AS duration,
coalesce(wait_event_type ||'.'|| wait_event, 'f') AS waiting,
CASE
WHEN a.query ~*'^autovacuum.*to prevent wraparound' THEN 'wraparound'
WHEN a.query ~*'^vacuum' THEN 'user'
ELSE
'regular'
END AS mode,
p.datname AS database,
p.relid::regclass AS table,
p.phase,
pg_size_pretty(p.heap_blks_total * current_setting('block_size')::int) AS table_size,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
pg_size_pretty(p.heap_blks_scanned * current_setting('block_size')::int) AS scanned,
pg_size_pretty(p.heap_blks_vacuumed * current_setting('block_size')::int) AS vacuumed,
round(100.0 * p.heap_blks_scanned / p.heap_blks_total, 1) AS scanned_pct,
round(100.0 * p.heap_blks_vacuumed / p.heap_blks_total, 1) AS vacuumed_pct,
p.index_vacuum_count,
round(100.0 * p.dead_tuple_bytes / p.max_dead_tuple_bytes,1) AS dead_pct
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a using (pid)
ORDER BY now() - a.xact_start DESC;
Visualizza le query asincrone
Per visualizzare le query in esecuzione in modo asincrono, puoi eseguire una query sulla vista pg_stat_activity e filtrare in base alle query che non sono il processo leader.
SELECT
query,
leader_pid,
array_agg(pid) FILTER (WHERE leader_pid != pid) AS members
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL
GROUP BY
query,
leader_pid;
Visualizza l'SQL del blocco che causa l'arresto
Puoi visualizzare l'attività bloccata eseguendo una query sulla vista pg_locks e unendola alla vista pg_stat_activity.
SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocked_activity.wait_event AS blocked_wait_event,
blocking_activity.wait_event AS blocking_wait_event,
blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;
Determinare l'efficacia delle dimensioni di work_mem e temp_buffers
Per determinare se work_mem e temp_buffers sono dimensionati correttamente per le tue esigenze, puoi eseguire una query sulla vista pg_stat_database e controllare il file postgres.log.
Utilizzando pg_stat_database, esegui la seguente query e, se si verifica una crescita di temp_files o temp_bytes tra le esecuzioni, è probabile che sia necessaria l'ottimizzazione di work_mem o temp_buffers.
SELECT
datname,
temp_files,
temp_bytes
FROM
pg_stat_database;
Dopo aver eseguito questo comando, controlla il file postgres.log per vedere se sono stati utilizzati file temporanei:
LOG: [fd.c:1772] temporary file: path "base/pgsql_tmp/pgsql_tmp4640.1", size 139264
L'obiettivo è ridurre al minimo la creazione di file temporanei, non impedirla completamente. Questo perché l'impostazione di work_mem e temp_buffers
è un equilibrio tra la memoria disponibile sull'host e il numero di connessioni
che richiedono la memoria. Per impostare correttamente questi parametri, è necessario comprendere ogni singolo workload.
Visualizza le prestazioni delle query utilizzando Query Insights
Puoi identificare le query lente e le istruzioni con un I/O del disco elevato utilizzando Query Insights nell'interfaccia utente web di AlloyDB Omni. Query Insights richiede l'abilitazione dell'estensione pg_stat_statements nel tuo database. Per istruzioni sulla configurazione, consulta Installa la UI web.
Per visualizzare le metriche sul rendimento delle query nell'interfaccia utente web, segui questi passaggi:
- Connettiti alla UI web e seleziona il tuo cluster.
- Nel menu di navigazione, fai clic su Query Insights.
- (Facoltativo) Utilizza l'elenco Database per filtrare le istruzioni in base a un database specifico o seleziona Tutti i database.
- Esamina la tabella Query per analizzare le statistiche di esecuzione SQL. Ogni riga mostra le seguenti metriche insieme all'istruzione SQL completa sotto la riga:
- Nome database: il database logico in cui è stata eseguita l'istruzione.
- Chiamate: il numero totale di volte in cui l'istruzione è stata eseguita.
- Righe: il numero totale di righe recuperate o interessate dall'istruzione.
- Execution time: mean: il tempo di esecuzione medio per chiamata.
- Tempo di esecuzione: totale: il tempo di esecuzione cumulativo di tutte le chiamate.
- Hit di blocco condivisi: il numero totale di successi della cache del buffer condiviso.
- Lettura di blocchi condivisi: il numero totale di blocchi condivisi letti dal disco.
- Tipo di query: classifica l'impatto sul rendimento delle query, ad esempio
Slow queryoHigh disk IO.