← Guia Completo: Diagnóstico de Desempenho em VMs Linux

⚙️ Componente: Processos e Serviços. Quando os recursos de sistema parecem normais mas uma aplicação ou serviço está lento, o problema está frequentemente em syscalls bloqueadas, ficheiros locked, dependências em falha ou configuração de prioridade inadequada. Este artigo cobre as ferramentas de diagnóstico ao nível do processo.

Quando diagnosticar ao nível do processo?

  • CPU, RAM e disco estão normais mas um serviço específico está lento ou irresponsivo
  • Um serviço inicia mas para ao fim de minutos sem razão aparente
  • Processo em estado D (uninterruptible sleep) no ps ou top
  • Erros de permissão ou “ficheiro em uso” nos logs da aplicação
  • Processo zombie (Z) sem processo pai para o acolher

1. ps — Análise de Processos

# Todos os processos, ordenados por CPU
ps aux --sort=-%cpu | head -15

# Árvore de processos (relações parent-child)
ps auxf | head -30
pstree -p

# Processo específico por nome
ps aux | grep <nome_processo>

# Threads de um processo específico
ps -eLf | grep <PID>

# Processos em estado D (uninterruptible — aguardam I/O)
ps aux | awk '$8 ~ /^D/ {print}'

Estados de processo no ps

Estado Significado Preocupante?
R Running ou runnable — em execução ou fila de CPU Normal
S Sleeping — à espera de evento (normal) Normal
D Uninterruptible sleep — aguardando I/O de disco/rede ⚠️ Se persistente
T Stopped — parado por sinal SIGSTOP ⚠️ Verificar
Z Zombie — terminou mas pai não recolheu exit code ⚠️ Leak de processo
I Idle kernel thread Normal
⚠️ Processos em estado D: Um processo em estado D não pode ser terminado com kill -9 — está bloqueado no kernel aguardando I/O. Persistência deste estado indica bloqueio severo de disco ou NFS. Verificar iostat e dmesg em simultâneo.

2. strace — Rastreio de Chamadas ao Sistema

# Rastrear syscalls de um processo em execução
strace -p <PID> -f -T 2>&1 | head -30

# Resumo estatístico (mais útil para diagnóstico)
strace -c -p <PID>
# aguardar 10-20 segundos, depois Ctrl+C

# Focar em I/O de ficheiros
strace -p <PID> -e trace=read,write,open,openat,close,stat 2>&1

# Rastrear processo e todos os seus filhos
strace -f -p <PID> 2>&1 | tail -20

Interpretar o output do strace -c

Syscall dominante Possível causa de lentidão
read / write Bottleneck de I/O de disco ou rede
futex Contention de locks entre threads — problema de concorrência
epoll_wait / select / poll Normal — à espera de eventos de I/O de rede
nanosleep / clock_nanosleep O processo tem delays deliberados — verificar configuração
mmap / mprotect Gestão de memória intensa — possível memory pressure
connect / recvfrom Chamadas de rede lentas — verificar latência de rede
💡 Caso de uso típico: Uma aplicação está lenta mas CPU e memória parecem normais. strace -c -p <PID> durante 30 segundos mostra que 90% do tempo está em read() — confirma bottleneck de I/O de disco. Verificar iostat para o disco correspondente.

3. lsof — Ficheiros e Conexões Abertas

# Ficheiros abertos por processo específico
lsof -p <PID>

# Que processo tem um ficheiro específico aberto
lsof /var/log/syslog

# Conexões de rede de um processo
lsof -i -p <PID>

# Todos os ficheiros de rede abertos
lsof -i

# Quantos ficheiros abertos tem o sistema
cat /proc/sys/fs/file-nr    # em uso / livre / máximo

# Limite de ficheiros abertos para um processo
cat /proc/<PID>/limits | grep 'open files'
⚠️ Limite de ficheiros abertos: Se uma aplicação atingir o limite de open files, começará a falhar com erros “Too many open files”. Verificar: lsof -p <PID> | wc -l e comparar com o limite em /proc/<PID>/limits. Aumentar se necessário em /etc/security/limits.conf.

4. systemctl e journalctl — Serviços systemd

# Serviços com falha
systemctl --failed

# Estado detalhado de um serviço
systemctl status <nome_servico>

# Reiniciar serviço com falha
systemctl restart <nome_servico>

# Logs de um serviço (últimas 100 linhas)
journalctl -u <nome_servico> -n 100 --no-pager

# Logs em tempo real
journalctl -u <nome_servico> -f

# Logs desde o último arranque do serviço
journalctl -u <nome_servico> --since today
# Listar todos os serviços em execução
systemctl list-units --type=service --state=running

# Tempo de arranque por serviço (identificar serviços lentos no boot)
systemd-analyze blame | head -15

# Cadeia crítica de arranque
systemd-analyze critical-chain
💡 systemd-analyze blame: Mostra os serviços ordenados pelo tempo que demoraram a arrancar. Útil para identificar serviços que atrasam o boot ou que têm dependências problemáticas.

5. nice e renice — Prioridade de Processos

# Lançar processo com baixa prioridade (nice 19 = mínima prioridade)
nice -n 19 <comando>

# Baixar prioridade de processo em execução (não requer root para subir nice value)
renice -n 10 -p <PID>

# Elevar prioridade (requer root — nice negativo)
renice -n -5 -p <PID>

# Ver prioridade atual de todos os processos
ps -eo pid,ni,pri,stat,comm --sort=-ni | head -20
💡 Nice values: Variam de -20 (maior prioridade) a +19 (menor prioridade). O default é 0. Reduzir o nice value de um processo problemático (ex: backup, compilação) para +15 ou +19 pode aliviar a pressão sobre processos críticos sem parar o processo.

6. Checklist — Diagnóstico de Processos e Serviços

  • ✅ ps aux | awk '$8 ~ /^D/' — processos bloqueados em I/O?
  • ✅ ps auxf — processos zombie (Z) ou parados (T)?
  • ✅ systemctl --failed — serviços com falha?
  • ✅ journalctl -u <serviço> -n 50 — erros nos logs do serviço?
  • ✅ strace -c -p <PID> — qual syscall domina o tempo do processo?
  • ✅ lsof -p <PID> | wc -l — próximo do limite de ficheiros abertos?
  • ✅ systemd-analyze blame — serviços lentos no arranque?
← Diagnóstico de Rede
Próximo: Kernel e Logs →

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário