Linux para DBAs: os comandos que você usa às 3 da manhã

Quando um banco fica lento às 3 da manhã, o diagnóstico mais rápido muitas vezes não vem do SQL, e sim de um punhado de comandos Linux. Este é o kit enxuto que todo DBA deveria ter na memória muscular — o suficiente para dizer, em dois minutos, se o problema é o banco ou o servidor embaixo dele.

O servidor de banco ainda é uma máquina Linux

Metade dos chamados de "o banco está lento" é, na verdade, "o servidor onde ele roda está sufocado". Antes de ajustar um único parâmetro do Postgres, descarte o sistema operacional. Aqui está o kit mínimo.

CPU e carga

uptime          # load average: 1, 5, 15 min. Compare ao número de núcleos (nproc)
top -o %CPU     # ao vivo, ordenado por CPU. Tecle '1' para ver por núcleo
mpstat 1 5      # utilização por núcleo, detecta um único núcleo saturado

Um load average acima do número de núcleos significa processos enfileirados por CPU. Se o %iowait no top está alto, o gargalo é disco, não CPU.

Memória e o OOM Killer

free -h         # usado / livre / disponível — observe 'available', não 'free'
dmesg -T | grep -i 'oom\|killed process'

Essa linha do dmesg é a que resolve mistérios. Se o OOM killer do kernel matou um backend postgres, você verá aqui — o "crash" do banco foi o SO recuperando memória. A correção costuma ser reduzir work_mem × conexões, não o banco em si.

I/O de disco — geralmente o culpado real

iostat -xz 1    # %util perto de 100 = disco saturado; await = latência por I/O
df -h           # a partição de dados/WAL está cheia?
du -sh /var/lib/postgresql/*/main/pg_wal   # o WAL está inflando?

Um disco quase cheio ou a 100% de utilização explica mais incidentes "de banco" do que qualquer consulta. Um diretório pg_wal crescendo aponta direto para um replication slot inativo.

Conexões e portas

ss -tnp state established '( dport = :5432 or sport = :5432 )' | wc -l
ss -s           # resumo de sockets, total de conexões estabelecidas

Contar as conexões estabelecidas reais na porta 5432 pelo lado do SO confere o que o pg_stat_activity diz — útil quando uma aplicação vaza conexões.

Acompanhando os logs

journalctl -u postgresql -f --since "10 min ago"
tail -f /var/lib/postgresql/*/main/log/postgresql-*.log

De checagens manuais à visibilidade contínua

Esses comandos são ótimos para um incidente ao vivo, mas rodá-los na mão significa olhar só depois que algo quebra. O PG Monitoring coleta os mesmos sinais do host — CPU, memória, I/O de disco e eventos de OOM — junto das métricas do banco e os correlaciona, então quando uma consulta fica lenta você vê na hora se a causa é o banco ou a máquina embaixo dele.