Troubleshooting: Performance e Memória

Estado atual do servidor

# Verificar estado completo
free -h && swapon --show && pm2 list | grep -v "^$"

Configuração

RAM: 31GB total
Swap: 5GB (criado por nos)
Backend: 6 workers × ~2GB = ~12GB
Frontend: ~60MB
Outros servicos: ~3GB

Sintoma 1: Swap alto (>3GB)

swapon --show
# NAME      TYPE SIZE USED PRIO
# /swapfile file   5G 3.2G   -2  ← PROBLEMA se >3GB

Causa: 6 workers backend usando ~12GB de RAM com pressão de memória. Node.js começa a usar swap → GC pauses → timeouts do Baileys → erros.

Monitorar:

# Ver processo mais pesado
ps aux --sort=-%mem | head -10
 
# Ver memoria por worker PM2
pm2 list | grep zpro-backend | awk '{print "Worker", $1, ":", $NF}'

Solução temporária: Sem reiniciar nada, aguardar Claude Code ser fechado (~4GB liberados).

Solução permanente: Reduzir CLUSTER_INSTANCES de 6 para 4 em backend/.env (requer pm2 restart — fora do horário comercial)

Sintoma 2: Backend worker reiniciando com frequência

pm2 list | grep zpro-backend
# Verificar coluna "restarts" — se >200 em 24h = problema

Causa: Worker atingiu max_memory_restart: 7G configurado.

ecosystem.config.js atual:

max_memory_restart: '7G',
node_args: '--max-old-space-size=5120',
min_uptime: '30s',
max_restarts: 15,
restart_delay: 20000

Verificar logs de OOM:

pm2 logs zpro-backend --lines 20 --nostream 2>&1 | grep -i "memory\|heap\|OOM\|killed"
dmesg | grep -i "oom\|killed" | tail -10

Sintoma 3: Frontend lento / timeout

# Verificar status do frontend
pm2 list | grep zpro-frontend
# Verificar logs de erro
cat /home/deployzdg/.pm2/logs/zpro-frontend-novo-error.log | tail -20

Causa comum: Build Next.js grande + servidor com pouca RAM.

Solução:

# Verificar tamanho do .next
du -sh /home/deployzdg/zpro.io/frontend/.next/
 
# Reload (mais leve que restart)
pm2 reload zpro-frontend-novo

Sintoma 4: PostgreSQL terminando conexões

pm2 logs zpro-backend --lines 50 --nostream 2>&1 | grep "terminating connection"

Causa: PgBouncer ou PostgreSQL matando conexões ociosas após timeout. Com 6 workers fazendo muitas queries = muitas conexões simultâneas.

Verificar conexões ativas (precisa de acesso ao banco):

SELECT count(*), state FROM pg_stat_activity 
WHERE datname = 'postgres' GROUP BY state;

Sintoma resultante: Worker crasha → Baileys desconecta → loop de reconexão.

Sintoma 5: Baileys timeouts durante init

pm2 logs zpro-backend --lines 20 --nostream 2>&1 | grep "Timed Out\|executeInitQueries"

Causa: Alta pressão de memória → GC pauses → WebSocket WhatsApp timeout durante init.

Cadeia: swap alto → GC pause → timeout Baileys → worker restart → Baileys reconecta → loop.

Comandos de diagnóstico rápido

# Snapshot completo do sistema
echo "=== RAM ===" && free -h
echo "=== SWAP ===" && swapon --show
echo "=== DISCO ===" && df -h / | head -2
echo "=== PM2 ===" && pm2 list
echo "=== TOP PROCESSOS ===" && ps aux --sort=-%mem | head -8
echo "=== SWAP USAGE ===" && cat /proc/swaps
echo "=== BACKEND LOGS ===" && pm2 logs zpro-backend --lines 5 --nostream 2>&1 | tail -10

Ações de emergência (sem pm2 restart)

# 1. Liberar cache do sistema (não afeta processos)
sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
 
# 2. Verificar se swap pode ser reduzido
# (APENAS se RAM disponivel > swap usado)
free_ram=$(free -m | awk '/^Mem:/{print $7}')
swap_used=$(free -m | awk '/^Swap:/{print $3}')
echo "RAM disponivel: ${free_ram}MB | Swap em uso: ${swap_used}MB"
 
# 3. Reload gradual do backend (sem downtime)
pm2 reload zpro-backend
 
# 4. Frontend reload (sempre seguro)
pm2 reload zpro-frontend-novo

🧠 ZPRO CRM Brain

Explorador

performance