Surveiller les performances de la base de données AlloyDB Omni

Sélectionnez une version de la documentation :

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.