Monitorar a performance do banco de dados do AlloyDB Omni

Selecione uma versão da documentação:

Nesta página, descrevemos como monitorar o desempenho do banco de dados do AlloyDB Omni usando scripts de observabilidade do PostgreSQL.

Ver o estado dos processos conectados e os eventos de espera

É possível determinar todos os processos conectados à sua instância do AlloyDB Omni, bem como todos os back-ends que estão aguardando atividade, consultando a visualização 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;

Ver as maiores tabelas

Para determinar o tamanho das maiores tabelas, consulte a visualização 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;

Ver as principais verificações sequenciais

Para conferir as principais verificações sequenciais, consulte a visualização 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;

Ver as principais verificações de índice

Para conferir as principais verificações de índice, consulte a visualização 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;

Ver as transações em execução há mais tempo

É possível ver as transações em execução há mais tempo consultando a visualização pg_stat_activity e verificando a idade da transação.

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;

Verificar o progresso do aspirador

É possível verificar o progresso das operações de vacuum consultando a visualização pg_stat_progress_vacuum e mesclando-a com a visualização pg_stat_activity usando IDs de 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;

Ver consultas assíncronas

Para ver as consultas que estão sendo executadas de forma assíncrona, consulte a visualização pg_stat_activity e filtre as consultas que não são o processo líder.

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;

Ver SQL de bloqueio

É possível ver a atividade bloqueada consultando a visualização pg_locks e mesclando-a com a visualização 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;

Determinar a eficácia do tamanho de work_mem e temp_buffers

Para determinar se o work_mem e o temp_buffers estão dimensionados corretamente para suas necessidades, consulte a visualização pg_stat_database e verifique o arquivo postgres.log. Usando pg_stat_database, execute a consulta a seguir e, se houver algum crescimento em temp_files ou temp_bytes entre as execuções, é provável que seja necessário ajustar work_mem ou temp_buffers.

SELECT
    datname,
    temp_files,
    temp_bytes
FROM
    pg_stat_database;

Depois de executar isso, verifique o arquivo postgres.log para conferir se os arquivos temporários foram usados:

LOG: [fd.c:1772] temporary file: path "base/pgsql_tmp/pgsql_tmp4640.1", size 139264

O objetivo é minimizar a criação de arquivos temporários, não impedir completamente que eles aconteçam. Isso ocorre porque a configuração de work_mem e temp_buffers é um equilíbrio entre a memória disponível no host e o número de conexões que exigem a memória. Para definir esses parâmetros corretamente, é necessário entender cada carga de trabalho individual.

Ver o desempenho da consulta usando o Query Insights

É possível identificar consultas lentas e instruções de alta E/S de disco usando o Query Insights na interface do usuário da Web do AlloyDB Omni. O Query Insights exige que a extensão pg_stat_statements esteja ativada no banco de dados. Para instruções de configuração, consulte Instalar a interface da Web.

Para conferir as métricas de performance de consulta na UI da Web, siga estas etapas:

  1. Conecte-se à interface da Web e selecione o cluster.
  2. No menu de navegação, clique em Query Insights.
  3. Opcional: use a lista Banco de dados para filtrar as instruções por um banco de dados específico ou selecione Todos os bancos de dados.
  4. Analise a tabela Consultas para analisar as estatísticas de execução do SQL. Cada linha exibe as seguintes métricas, além da instrução SQL completa abaixo da linha:
    • Nome do banco de dados: o banco de dados lógico em que a instrução foi executada.
    • Chamadas: o número total de vezes que a instrução foi executada.
    • Linhas: o número total de linhas recuperadas ou afetadas pela instrução.
    • Tempo de execução: média: o tempo médio de execução por chamada.
    • Tempo de execução: total: o tempo de execução cumulativo em todas as chamadas.
    • Ocorrência em cache de bloco compartilhado: o número total de ocorrências em cache de buffer compartilhado.
    • Leitura de blocos compartilhados: o número total de blocos compartilhados lidos do disco.
    • Tipo de consulta: categoriza o impacto no desempenho da consulta, como Slow query ou High disk IO.