Servidor congela sem logs claros: causas reais e como diagnosticar

Esse é um dos piores cenários em produção 😅
servidor congela sem logs, para de responder. Quando isso acontece, quase sempre o problema está abaixo da camada de aplicação.

Quando um servidor Linux congela sem gerar logs claros, o diagnóstico pode se tornar bastante complexo. Nesses casos, é necessário analisar o comportamento do sistema utilizando ferramentas específicas que permitem investigar CPU, memória, disco e processos. Para conhecer as principais utilidades utilizadas em troubleshooting, veja também o guia sobre ferramentas de diagnóstico no Linux.

Vamos por partes — do mais comum ao mais traiçoeiro.

O que “congelar” geralmente significa (na prática)

Normalmente é um destes estados:

• SSH não responde ou conecta e trava
• Ping ainda responde (ou para depois)
• Load pode estar baixo ou absurdamente alto
• Nada novo aparece em /var/log
• Só volta com reboot

Isso não é bug de app, é recurso travado ou kernel sofrendo.

Causas mais comuns (em ordem real de frequência)

1️⃣ I/O travado (disco bloqueando tudo)

Campeão absoluto.

Sintomas:

• SSH conecta e congela
• top não atualiza
• Load Average sobe mesmo sem CPU alta
• Nada grava em log (disco não responde)

Por quê:

• SSD/NVMe com problema
• RAID degradado
• fsync excessivo (MySQL, PHP-FPM, journaling)
• Snapshots do hypervisor

👉 Quando o I/O trava, o sistema inteiro para, inclusive logs.

2️⃣ OOM Killer silencioso ou mal configurado

O kernel começa a matar processos, mas:

• Logs não gravam (I/O já ruim)
• dmesg só mostra algo depois do reboot

Muito comum em VPS.

Pistas:

• Serviços “somem”
• PHP-FPM ou MySQL reiniciam sozinhos
• Nada claro em /var/log/messages

3️⃣ Soft lockup / hard lockup de CPU (kernel)

O kernel entra em loop e para de responder.

Causas típicas:

• Bug de driver (rede, NVMe, virtio)
• Kernel antigo
• Hypervisor bugado

Aqui:

• Nem logs são escritos
• Só reboot resolve

4️⃣ Exaustão de recursos invisíveis

Não é CPU nem RAM.

Exemplos:

• fs.file-max (file descriptors)
• pid_max
• Conntrack cheio
• Inodes esgotados

Resultado:

• Processos não abrem arquivos
• SSH trava
• Logs não gravam

5️⃣ Problemas no hypervisor (fora da sua VM)

Muito comum em VPS barata.

Você vê:

• Congelamento total
• Depois tudo “volta”
• Nenhum log local explica

Porque o problema não está no seu sistema.

Em muitos casos, travamentos de servidor estão relacionados a gargalos de recursos como CPU, memória ou I/O de disco. Utilizar ferramentas adequadas de análise do sistema permite identificar padrões de comportamento antes do incidente ocorrer novamente. Por isso, é importante conhecer as principais ferramentas de diagnóstico de servidores Linux.

O que checar ANTES do próximo congelamento

Configure isso agora, não depois.

1️⃣ Habilite logs que sobrevivem ao reboot

journalctl --list-boots
journalctl -b -1

Se não tiver histórico → problema.

2️⃣ Ative Magic SysRq (salva sua vida)

sysctl -w kernel.sysrq=1

Para deixar definitivo edite o arquivo /etc/sysctl.conf e adicione kernel.sysrq=1. A seguir saia do editor e execute sysctl -p

Durante o travamento, tente:

echo w > /proc/sysrq-trigger   # processos bloqueados
echo t > /proc/sysrq-trigger   # stack trace

Isso pode gravar algo mesmo em caos.

3️⃣ Habilite watchdog do kernel

Evita “congelar pra sempre”.

modprobe softdog

Se travar → reboot automático → logs pós-morte.

4️⃣ Log de I/O e memória

Ative:

• vmstat 1
• iostat -xz 1
• dmesg -w

Nem que seja via screen.

Teste rápido para descobrir o vilão

Antes de travar de novo, rode:

uptime
free -h
df -h
df -i
ulimit -n
cat /proc/sys/fs/file-nr

Se algum estiver no limite → achamos o culpado.

Regra de ouro (bem direta)

Servidor que congela sem log quase sempre está sofrendo fora da aplicação
→ Disco, kernel, memória ou hypervisor.

Aplicação não congela o sistema inteiro sozinha.

Em dedicado, os 4 vilões reais (ordem prática)

🥇 1) Disco / controladora travando o barramento

O campeão absoluto em dedicado.

Mesmo com CPU e RAM ok, se o disco entra em estado ruim:

• Tudo bloqueia (inclusive logs)
• SSH conecta e congela
• Load pode subir absurdamente
• Só reboot resolve

Culpados típicos:

• NVMe com firmware bugado
• RAID (especialmente cache + BBU)
• SATA com timeout (ataX: link is slow to respond)
• Filesystem esperando flush eterno

👉 Quando o I/O trava, o kernel fica refém.

🥈 2) Kernel panic disfarçado / soft lockup

O kernel não “cai”, mas entra em loop.

Sinais:

• Nada responde
• Ventoinhas aumentam
• LEDs de disco parados
• Nenhum log gravado

Muito comum com:

• Kernel antigo
• Driver de rede (ixgbe, bnxt, r8169)
• NVMe genérico

🥉 3) RAM defeituosa (subestimada e cruel)

Sim, RAM com erro intermitente faz isso.

Efeito clássico:

• Congelamento aleatório
• Nenhum padrão
• Às vezes dias sem acontecer

ECC ajuda, mas não é garantia.

🥉 4) CPU microcode / BIOS

Menos comum, mas real:

• Microcode antigo
• BIOS bugada
• Turbo maluco sob carga

Resultado: lock total sem aviso.

O que EU faria agora (checklist cirúrgico)

1️⃣ Ver se houve erro ANTES do silêncio

Após reboot:

journalctl -b -1 -p err
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|ata"

Procure por:

• I/O error
• nvme timeout
• reset controller
• blocked for more than

2️⃣ Teste o disco como gente grande

Mesmo que SMART diga “OK”.

smartctl -a /dev/nvme0
smartctl -a /dev/sda

Procure:

• Media and Data Integrity Errors
• Unsafe Shutdowns
• Command Timeout
• CRC Error Count

⚠️ Qualquer número ≠ 0 já é suspeito.

3️⃣ Teste a RAM (sem dó)

Idealmente via rescue.

memtester 90% 3

Ou no boot:

• Memtest86+
• 2 passes completos no mínimo

4️⃣ Ative NMI watchdog (ouro em freeze)

sysctl -w kernel.watchdog=1

Se o kernel travar → reboot automático → logs do crash.

5️⃣ Se usa RAID…

Cheque agora:

cat /proc/mdstat
megacli -AdpAllInfo -aALL

RAID degradado = freezer profissional.

Teste de provocação controlada

Pra forçar o erro aparecer:

stress-ng --io 4 --vm 2 --vm-bytes 70% --timeout 10m

Se travar aqui → hardware confirmado.

Regra de ouro em dedicado

Congelou sem log = hardware até prova em contrário.

E mais:

• App não congela kernel
• MySQL não congela barramento
• WordPress não mata servidor

Diagnosticar travamentos intermitentes exige uma abordagem estruturada de troubleshooting, combinando análise de logs, métricas de sistema e monitoramento de recursos. Para aprofundar esse processo, veja também o guia completo sobre ferramentas essenciais para diagnóstico de servidores Linux.

FAQ

Veja Mais:

Estratégia real de backup para servidores Linux
Ferramentas de Diagnóstico Linux: Guia Definitivo de Performance (2026)
EXT4 vs XFS: Qual é o melhor filesystem para produção Linux?
Rede ok, mas site lento: onde está o gargalo?