A CLI do Linux

Um servidor PostgreSQL não roda isoladamente; ele roda como um processo em um host Linux que possui seus próprios limites de disco, memória e rede. Portanto, ler a linha de comando é, na verdade, ler uma segunda camada por baixo do próprio banco de dados.

Esta página constrói o modelo mental para essa leitura: as três camadas que uma sessão de triagem correlaciona, a doutrina que impede um operador de mudar coisas cegamente e onde a evidência da CLI para e uma decisão em nível de banco de dados começa.

Resumo

• A CLI do Linux oferece ao operador uma segunda visão independente de um cluster Postgres - a visão do sistema operacional - que deve ser correlacionada, e não substituída, pela visão própria do banco de dados.
• Por que Importa: Sintomas que parecem específicos do banco de dados, como uma tempestade de consultas, são frequentemente, na verdade, exaustão em nível de host de disco, memória ou descritores de arquivo usando uma fantasia do Postgres.
• Conceitos-Chave: correlação de três camadas, doutrina de triagem, pacote de incidentes, parada segura versus interrupção forçada, eventos de espera.
• Quando Usar: Recorra a este modelo no momento em que um sistema parecer lento ou sem resposta e você ainda não souber se a causa está no SO, no processo Postgres ou na própria carga de trabalho.
• Limitações / Compromissos: A evidência da CLI diz onde procurar, raramente diz a solução por si só, e agir com base na saída de um único comando sem corroboração é como incidentes ruins pioram.
• Tópicos Relacionados: Ferramentas de IO e memória, triagem de incidentes, recuperação de disco cheio.

Fundamentos

Toda sessão de triagem em um host Postgres está, na verdade, trabalhando em três camadas ao mesmo tempo, mesmo quando não parece.

A primeira camada é o sistema operacional: espaço em disco, pressão de memória e conexões de rede, todas visíveis através de ferramentas como df, free e ss que não sabem nada sobre SQL.

A segunda camada é o processo: os trabalhadores postgres reais rodando nesse host, visíveis através de ps, pgrep e systemctl, que sabem que um processo existe, mas não qual consulta ele está executando.

A terceira camada é o estado do banco de dados: pg_stat_activity, pg_locks e os logs do servidor, que sabem exatamente qual SQL está sendo executado, mas nada sobre a memória livre do host.

Uma analogia útil é um médico lendo sinais vitais, um raio-X e uma entrevista com o paciente separadamente - cada camada é precisa em seus próprios termos, e um diagnóstico só se sustenta quando todos os três concordam.

A disciplina central que esta página ensina é correlação: um sintoma de disco cheio na camada do SO e um PANIC: could not write to file no log do Postgres são o mesmo evento visto de duas camadas, não dois problemas separados.

Aprender a se mover fluentemente entre essas três camadas, em vez de viver em apenas uma delas, é o que separa a triagem rápida de adivinhação.

Mecânica e Interações

A razão pela qual a triagem da CLI tem uma ordem estrita - SO primeiro, depois processo, depois banco de dados - é que as ferramentas de cada camada respondem a uma janela de tempo diferente e a um tipo diferente de pergunta.

Comandos em nível de SO como vmstat e iostat respondem "o que está acontecendo agora neste host", independentemente de qual banco de dados ou consulta o causou.

Comandos em nível de processo como ps e systemctl status respondem "o processo Postgres em si está saudável", o que é importante porque um loop de reinicialização pode se disfarçar como um problema de desempenho de consulta.

Visualizações em nível de banco de dados como pg_stat_activity respondem "o que o Postgres está fazendo agora", incluindo eventos de espera que explicam por que um backend está lento, em vez de apenas que ele está lento.

A doutrina de triagem que une tudo isso é simples: meça em todas as três camadas antes de alterar qualquer configuração, reiniciar qualquer serviço ou matar qualquer processo, porque agir apenas com base na evidência de uma camada rotineiramente diagnostica mal as outras duas.

É também por isso que existe um script de pacote de incidentes - capturando df, free, vmstat e os snapshots relevantes de pg_stat_activity/pg_locks juntos, em uma única passagem, antes que qualquer coisa no sistema mude.

# Snapshot mínimo de três camadas, tirado junto, não sequencialmente ao longo de minutos
df -h "$PGDATA"; free -h
ps -eo pid,rss,cmd --sort=-rss | grep postgres | head -5
psql "$DATABASE_URL" -c "SELECT wait_event_type, count(*) FROM pg_stat_activity GROUP BY 1;"

Capturados juntos, esses três comandos contam uma história coerente; capturados com cinco minutos de intervalo durante um incidente ao vivo, cada um pode descrever um momento diferente.

Considerações Avançadas e Aplicações

A doutrina de "medir antes de tocar" torna-se mais difícil de manter sob pressão real de incidentes, que é exatamente quando ela mais importa.

Um modo de falha comum é um operador ver alta CPU ou IO e ir direto para uma alteração de GUC ou um failover, quando a leitura de três camadas teria mostrado um pico de checkpoint transitório que já estava se resolvendo por conta própria.

A escalada para failover é uma decisão em nível de banco de dados que a evidência da CLI pode apoiar, mas raramente deve acionar sozinha - falha de hardware, corrupção ou um disco irrecuperável são os tipos de descobertas em nível de SO que realmente a justificam.

A distinção entre uma parada graciosa e um kill é onde a mecânica da CLI encontra risco real: systemctl stop permite que o Postgres complete seu checkpoint, enquanto kill -9 no postmaster arrisca um checkpoint incompleto e uma recuperação mais longa e arriscada na próxima inicialização.

O controle de acesso segue a mesma lógica de camadas - comandos de SO e SQL somente leitura são razoáveis para qualquer engenheiro executar, enquanto qualquer coisa que pare um processo ou altere um GUC pertence a um gate de plantão ou de sistema de dupla verificação.

À medida que a infraestrutura muda para contêineres, o mesmo modelo de três camadas ainda se aplica dentro de uma sessão kubectl exec, apenas substituindo systemctl pela visibilidade de processo do próprio runtime do contêiner.

Conceitos Equivocados Comuns

• "Uma tempestade de consultas sempre significa um problema de banco de dados" - muitas vezes significa que o host ficou sem memória ou disco primeiro, e o Postgres é apenas o processo mais visivelmente afetado.
• "kill -9 é uma maneira rápida e segura de reiniciar um Postgres travado" - arrisca um checkpoint incompleto, transformando uma reinicialização lenta em uma recuperação mais longa e arriscada.
• "pg_stat_activity sozinho diz se o host está saudável" - ele só sabe sobre o estado em nível de SQL e não diz nada sobre espaço em disco, pressão de memória ou o histórico de reinicialização do próprio processo.
• "Alta CPU sempre significa que uma consulta precisa ser ajustada" - atividade de checkpoint, autovacuum e até mesmo vizinhos barulhentos em nível de host podem produzir a mesma assinatura de CPU que um plano de consulta ruim.
• "Você precisa de ferramentas exóticas para triar um host Postgres" - df, free, vmstat e ps estão presentes em quase todas as imagens Linux e cobrem a maior parte da triagem de primeira passagem sem nenhuma instalação extra.

FAQs

Relacionados

• Noções Básicas da CLI do Linux para DBAs - os dez comandos concretos que o modelo desta página organiza.
• Ferramentas de IO e Memória - o conjunto de ferramentas em nível de SO em profundidade.
• Habilidade de Triagem de Incidentes - uma habilidade de agente construída sobre esta mesma doutrina de triagem.
• Disco Cheio em PGDATA - o cenário de disco cheio do qual o exemplo de três camadas desta página se baseia.
• Triagem de Tempestade de Locks - a metade em nível de banco de dados de uma investigação de tempestade de locks.

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 rodando em Linux (systemd, layouts Debian e RHEL); ela é conceitual e não está vinculada a uma versão específica de ferramenta.