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 tous les processus connectés à votre instance AlloyDB Omni ainsi que tous 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 tables les plus volumineuses 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 dont l'exécution prend le plus de temps

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

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 du verrou bloquant

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 avoir exécuté 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 réduire la création de fichiers temporaires, et non de l'empêcher complètement. En effet, la définition de work_mem et de temp_buffers permet d'équilibrer la mémoire disponible sur l'hôte et le nombre de connexions qui nécessitent de la mémoire. Pour définir correctement ces paramètres, vous devez comprendre chaque charge de travail.

Afficher les performances des requêtes à l'aide d'Insights sur les requêtes

Vous pouvez identifier les requêtes lentes et les instructions d'E/S de disque élevées à l'aide d'Insights sur les requêtes dans l'interface utilisateur Web d'AlloyDB Omni. Insights sur les requêtes nécessite l'activation de l'extension pg_stat_statements sur votre base de données. Pour obtenir des instructions de configuration, consultez Installer l'interface utilisateur Web.

Pour afficher les métriques de performances des requêtes dans l'interface utilisateur Web, procédez comme suit :

  1. Connectez-vous à l'interface utilisateur Web et sélectionnez votre cluster.
  2. Dans le menu de navigation, cliquez sur Insights sur les requêtes.
  3. Facultatif : Utilisez la liste Base de données pour filtrer les instructions par base de données spécifique ou sélectionnez Toutes les bases de données.
  4. Examinez le tableau Requêtes pour analyser les statistiques d'exécution SQL. Chaque ligne affiche les métriques suivantes, ainsi que l'instruction SQL complète sous la ligne :
    • Nom de la base de données : base de données logique dans laquelle l'instruction a été exécutée.
    • Appels : nombre total de fois où l'instruction a été exécutée.
    • Lignes : nombre total de lignes récupérées ou affectées par l'instruction.
    • Temps d'exécution : moyenne : temps d'exécution moyen par appel.
    • Temps d'exécution : total : temps d'exécution cumulé pour tous les appels.
    • Succès de cache de bloc partagé : nombre total de succès de cache de tampon partagé.
    • Lecture de blocs partagés : nombre total de blocs partagés lus à partir du disque.
    • Type de requête : classe l'impact sur les performances des requêtes, par exemple Slow query ou High disk IO.