Manual MyTable

PostgreSQL • Health/Diagnóstico

A área de Health/Diagnóstico ajuda a entender rapidamente a saúde do seu ambiente PostgreSQL: conectividade, locks, atividade de sessões, autovacuum, bloat (tabelas/índices), uso de disco, replicação e pistas de performance (consultas lentas). Use este painel sempre que notar lentidão, erros recorrentes ou para auditorias preventivas.


Abrir “Health/Diagnóstico”

  1. Conecte-se à sua conexão PostgreSQL e selecione o banco.
  2. No menu principal, toque em Health/Diagnóstico.
  3. Alguns cartões exigem permissões ou extensões habilitadas no servidor (o app indicará quando algo estiver indisponível).

O que você encontra no painel

  • Status de Conexão: tempo de resposta, versão do PostgreSQL, parâmetros-chave (resumo).
  • Atividade Atual: sessões ativas, em espera, em transação longa, tempo médio de execução.
  • Locks: visão por tipo (ROW, ACCESS SHARE/EXCLUSIVE), quem bloqueia x quem está bloqueado.
  • Autovacuum: últimos ciclos, filas, tabelas com autovacuum atrasado.
  • Bloat (quando disponível): estimativas de bloat em tabelas e índices mais críticos.
  • Uso de Disco: top N objetos por tamanho; tendência (se habilitada).
  • Replicação (se houver): atraso (replication lag) do(s) standby(s).
  • Consultas Lentas (quando o ambiente fornece): últimas N com duração acima do limiar.

Testes rápidos

  • Ping/latência: mede ida/volta de uma consulta simples.
  • Permissões básicas: verifica se o usuário consegue SELECT no schema escolhido.
  • Espaço livre (servidor/volume)*: alerta quando aproximando do limite.
    *Sujeito a permissões/integrações do seu ambiente.

Atividade e sessões

Veja backends executando, em espera (idle in transaction) ou aguardando locks. Transações longas podem bloquear VACUUM e aumentar bloat.

  • Use filtros por usuário, aplicação, tabela ou estado.
  • Identifique sessões “idle in transaction” há muito tempo — solicite commit/rollback ao responsável.

Locks (bloqueios)

O painel lista cadeias de bloqueio: Who blocks whom. Útil para descobrir a origem do gargalo.

  • Expanda um lock para ver comando, tabela, tempo esperando e PID.
  • Boa prática: negocie com o time antes de encerrar sessões. Prefira resolver pelo aplicativo.

Autovacuum & Bloat

O PostgreSQL usa autovacuum para limpar tuplas mortas; quando atrasado, cresce o bloat. O painel destaca tabelas/índices com sinais de bloat elevado e ciclos pendentes.

  • Se bloat está alto: agende Manutenção (VACUUM/REINDEX).
  • Avalie autovacuum por tabela (thresholds/custos) com a equipe de DBAs quando necessário.

Replicação

Em ambientes com standby, monitore o lag (atraso) para garantir RPO/RTO. Se o atraso crescer:

  • Verifique IO/rede entre primário e réplica.
  • Revise cargas pesadas (ETL, manutenção) executadas no primário.

Uso de disco (Top N)

  • Veja as maiores tabelas/índices do banco e o impacto no volume.
  • Se uma tabela cresceu demais, combine diagnóstico com Partições e Manutenção.

Consultas lentas

Quando habilitado (ex.: pg_stat_statements / logs de slow query), o painel mostra consultas que ultrapassaram o limiar configurado.

  • Abra a consulta no Editor SQL para investigar plano e índices.
  • Considere criar/ajustar Índices ou reescrever o filtro.

Alertas comuns (e como agir)

“Autovacuum atrasado em várias tabelas”

  • Execute VACUUM manual nas mais críticas e ajuste a carga fora do pico.

“Muitas sessões ‘idle in transaction’”

  • Eduque consumidores a fechar transações rapidamente; identifique queries que ficam abertas sem necessidade.

“Cadeias de locks longas”

  • Descubra o processo raiz; reprograme a operação ou quebre em lotes menores.

“Replicação com lag elevado”

  • Cheque rede/IO, reduza operações pesadas, aumente paralelismo de wal sender se apropriado.

“Bloat alto em índices/tabelas”

  • Planeje REINDEX e VACUUM (FULL quando necessário) em janela; reavalie padrões de escrita.

Boas práticas

  • Monitore regularmente o painel e registre ocorrências em Logs & Auditoria.
  • Padronize janelas de manutenção e comunique times de negócio.
  • Evite “apagar incêndio” matando sessões sem entender a causa; priorize soluções de processo.

Ferramentas relacionadas

Voltar: PostgreSQL • Visualizar Registros