Cette page explique comment surveiller les performances de votre base de données AlloyDB Omni à l'aide de scripts d'observabilité PostgreSQL.
Afficher l'état des processus connectés et des événements d'attente
Vous pouvez déterminer les processus connectés à votre instance AlloyDB Omni, ainsi que les backends en attente d'activité, en interrogeant la vue 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;
Afficher les tables les plus volumineuses
Vous pouvez déterminer la taille de vos plus grandes tables en interrogeant la vue 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;
Afficher les principales analyses séquentielles
Vous pouvez afficher les principales analyses séquentielles en interrogeant la vue 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;
Afficher les principales analyses d'index
Vous pouvez afficher les principales analyses d'index en interrogeant la vue 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;
Afficher les transactions les plus longues
Vous pouvez afficher les transactions les plus longues en interrogeant la vue pg_stat_activity
et en vérifiant l'âge de la transaction.
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;
Vérifier la progression des opérations de nettoyage
Vous pouvez vérifier la progression des opérations de nettoyage en interrogeant la vue pg_stat_progress_vacuum
et en la joignant à la vue pg_stat_activity
à l'aide des ID de processus.
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.num_dead_tuples / p.max_dead_tuples,1) AS dead_pct
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a using (pid)
ORDER BY now() - a.xact_start DESC;
Afficher les requêtes asynchrones
Pour afficher les requêtes exécutées de manière asynchrone, vous pouvez interroger la vue pg_stat_activity
et filtrer les requêtes qui ne sont pas associées au processus principal.
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;
Afficher le code SQL de blocage
Vous pouvez afficher l'activité bloquée en interrogeant la vue pg_locks
et en la joignant à la vue 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;
Déterminer les valeurs appropriées des paramètres work_mem
et temp_buffers
Pour déterminer si vos paramètres work_mem
et temp_buffers
sont correctement dimensionnés, vous pouvez interroger la vue pg_stat_database
et vérifier le fichier postgres.log
.
À l'aide de pg_stat_database
, exécutez la requête suivante. Si temp_files
ou temp_bytes
augmentent entre les exécutions, il est probable qu'un ajustement soit nécessaire pour work_mem
ou temp_buffers
.
SELECT
datname,
temp_files,
temp_bytes
FROM
pg_stat_database;
Après l'exécution de cette commande, vérifiez le fichier postgres.log
pour voir si des fichiers temporaires ont été utilisés :
LOG: [fd.c:1772] temporary file: path "base/pgsql_tmp/pgsql_tmp4640.1", size 139264
L'objectif est de minimiser la création de fichiers temporaires, et non de l'empêcher complètement. En effet, définir à la fois work_mem
et temp_buffers
permet de trouver un équilibre entre la mémoire disponible sur l'hôte et le nombre de connexions qui nécessitent cette mémoire. Pour définir correctement ces paramètres, vous devez comprendre chaque charge de travail individuelle.