investigação de performance. Evitar achismo é a chave para resolver problemas de performance de forma confiável. Isso exige abordagem metódica, baseada em dados e evidências. Vou te dar um passo a passo completo que funciona para servidores, aplicações e bancos de dados.

Investigar problemas de performance em servidores Linux exige analisar diversos recursos do sistema, incluindo CPU, disco, rede e memória. Muitas vezes, gargalos estão diretamente relacionados ao uso incorreto de RAM ou interpretação equivocada do cache do sistema. No guia completo sobre gerenciamento de memória no Linux na prática, explicamos como o kernel administra RAM, page cache e swap em ambientes de produção.

1. Defina o problema com precisão

Antes de qualquer análise técnica, é importante saber exatamente o que está lento, quando e em que contexto:

• É o servidor todo ou apenas uma aplicação específica?
• Lento para todos os usuários ou apenas alguns?
• O problema ocorre sempre ou apenas em horários de pico?

Ferramentas úteis: registros de tickets, monitoramento histórico, usuários relatando erro.

2. Colete métricas objetivas

Evite olhar apenas para a percepção. Você precisa de dados concretos:

No servidor

• CPU e memória: top, htop, vmstat, free -h
• I/O de disco: iostat -x, iotop, df -h
• Rede: iftop, nload, netstat -s
• Processos pesados: ps aux --sort=-%cpu

Em aplicações

• Logs detalhados (access.log, error.log)
• Latência de respostas HTTP (tempo de resposta de endpoints)
• Contadores de filas e threads (PHP-FPM, Node.js, etc.)

No banco de dados

• Consultas lentas: EXPLAIN ou logs slow query
• Locks e waits (SHOW PROCESSLIST MySQL, pg_stat_activity Postgres)
• Índices e cardinalidade das tabelas

3. Estabeleça um baseline

Compare o comportamento atual com um ponto de referência conhecido:

• Ex.: “Em horário normal, CPU < 40% e tempo médio de resposta < 200ms”.
• Isso evita confundir picos normais com problemas reais.

4. Correlacione métricas com sintomas

Não adianta olhar métrica isolada. Pergunte:

• Quando a CPU sobe, o que mais muda?
• Quando a latência HTTP aumenta, o banco de dados está com lock?
• Quando o disco está saturado, há jobs de backup ou logs crescendo?

Essa correlação transforma dados em diagnóstico confiável, não em achismo.

5. Ferramentas de análise avançada

Para problemas complexos, use monitoramento e profiling:

Durante investigações de performance, é comum encontrar servidores com grande quantidade de memória utilizada em cache. Isso não significa necessariamente um problema. Entender como funciona o gerenciamento de memória no Linux ajuda a interpretar corretamente métricas de RAM, buffers e page cache.

6. Teste hipóteses

Depois de identificar um possível gargalo:

• Faça pequenas alterações isoladas (ex.: aumentar cache, limitar threads).
• Meça novamente.
• Se a métrica melhora, você encontrou o ponto crítico.

Isso evita consertar “o que parece errado” e cria evidência concreta de causa e efeito.

7. Documente e repita

• Anote cada passo: dados coletados, análise feita, solução testada.
• Isso cria histórico e reduz risco de “achismo” futuro.

💡 Resumo prático:

1. Defina o problema claramente.
2. Colete métricas objetivas.
3. Compare com baseline.
4. Correlacione métricas com sintomas.
5. Use ferramentas de análise.
6. Teste hipóteses.
7. Documente tudo.

Vou montar um checklist de investigação de performance para servidores LAMP/WordPress, passo a passo, sem achismo, totalmente baseado em dados. Ele cobre servidor, banco, PHP-FPM, Nginx/Apache, disco e rede, além de como correlacionar os dados.

Checklist de Investigação de Performance

1️⃣ Definição do problema

• Qual serviço/app está lento? (site, painel, API)
• O problema é contínuo ou apenas em horários de pico?
• Todos os usuários são afetados ou apenas alguns?
• Qual a métrica de referência para normalidade? (ex.: tempo médio < 200ms)

2️⃣ Coleta de métricas do servidor

CPU / Memória

• top ou htop → identificar processos que consomem mais CPU/memória
• vmstat 1 5 → verificar swapping ou picos de uso
• free -h → memória disponível e buffers/cache

Disco / I/O

• iostat -x 1 5 → identificar discos saturados
• iotop → processos que mais escrevem/leem
• df -h → checar espaço disponível

Rede

• iftop ou nload → tráfego de rede em tempo real
• netstat -s → estatísticas de TCP/UDP

3️⃣ Logs da aplicação

• error.log e access.log (Nginx/Apache) → verificar erros 5xx ou latências altas
• Plugins WordPress que fazem consultas pesadas → identificar por timestamps
• Ativar WP_DEBUG + Query Monitor para rastrear queries lentas e hooks problemáticos

4️⃣ PHP-FPM / Apache / Nginx

• PHP-FPM status: pm.status_path → checar processos ativos e filas
• Logs de slow requests do PHP-FPM (request_slowlog_timeout)
• Nginx/Apache access log → identificar endpoints mais lentos
• Verificar número de workers, limites de conexão e max_children do PHP-FPM

5️⃣ Banco de dados

• Slow query log (MySQL/MariaDB): SET GLOBAL slow_query_log = 'ON';
• Analisar queries lentas: pt-query-digest ou mysqldumpslow
• SHOW PROCESSLIST → ver queries ativas e locks
• Índices e cardinalidade das tabelas → EXPLAIN nas queries críticas

6️⃣ Correlacionar métricas

• CPU alta → é devido a PHP-FPM ou MySQL?
• I/O alto → é leitura de disco ou logs crescendo?
• Latência HTTP alta → é banco, aplicação ou rede?
• Swapping → memória insuficiente ou configuração de cache mal dimensionada?

7️⃣ Testar hipóteses

• Limitar/conter processo específico e medir impacto
• Ativar cache (Redis/OPcache/Cache de página) e medir diferença
• Teste de carga controlado: ab ou hey para medir comportamento sob stress

8️⃣ Ferramentas avançadas (opcional)

• Monitoramento contínuo: Zabbix, Netdata, Prometheus/Grafana
• Profiling PHP: Blackfire, Tideways, Xdebug
• Logs centralizados: ELK Stack, Loki, Graylog
• Análise de banco: Percona Monitoring, pgBadger

9️⃣ Documentar

• Coletar métricas antes e depois de qualquer mudança
• Registrar alterações feitas, testes e resultados
• Criar baseline para referência futura

Antes de concluir qualquer diagnóstico de performance, é essencial compreender como o sistema operacional utiliza seus recursos internos. Por isso, recomendamos entender como o Linux gerencia memória na prática em servidores de produção.

FAQ

Veja Mais:

Gerenciamento de Memória no Linux: Guia Prático e Mitos
Diagnóstico completo de problemas de rede em servidores
Decisão estratégica de infraestrutura: comparação técnica para produção
AlmaLinux em Produção: Guia de Boas Práticas e Segurança 2026