Site lento: é PHP, banco de dados ou disco?

Escolhi este título porque vai direto à dor do administrador de sistemas que precisa isolar o gargalo exato de performance.

Você acessa o servidor e percebe que tudo está se arrastando. Um site lento afasta visitantes, derruba conversões em minutos e despenca seu ranqueamento no Google. Na prática, o sintoma visível no navegador é sempre o mesmo: a rodinha girando sem parar. No entanto, a raiz do problema no servidor pode estar escondida em diferentes camadas da sua infraestrutura.

A causa exata costuma se dividir em quatro suspeitos principais: processamento ineficiente do PHP, consultas pesadas travando o banco de dados, gargalos físicos de leitura e escrita no disco ou saturação da interface de rede. Tentar adivinhar o culpado aumentando a memória RAM cegamente não resolve a falha e apenas queima seu orçamento.

Neste tutorial, você vai aprender a diagnosticar sua infraestrutura como um engenheiro de operações. Vou mostrar os comandos exatos que uso na prática diária para isolar falhas. Abaixo, preparei uma tabela resumida relacionando os sintomas clássicos com as ferramentas que usaremos.

Pré-requisitos para o diagnóstico

• Acesso SSH ao servidor com privilégios de root ou usuário sudo.
• Familiaridade básica com a linha de comando de sistemas Linux.
• Servidor rodando uma distribuição baseada em Debian, Ubuntu ou AlmaLinux.
• Pacotes de monitoramento instalados nativamente (htop, sysstat, iotop).

Tela de terminal escuro mostrando o comando htop em execução, com barras coloridas indicando alto uso de CPU e memória em um servidor web Linux.

Passo 1: Identificando gargalos de CPU e PHP

O primeiro suspeito em aplicações dinâmicas modernas é quase sempre a camada do PHP. Quando o código é ineficiente ou entra em loops infinitos, ele consome ciclos de CPU até travar completamente o servidor. Para verificar o comportamento em tempo real, utilizo o comando htop no terminal.

Basta digitar o comando e observar as barras superiores coloridas. Se a CPU estiver colada em 100% e os processos no topo da lista forem php-fpm ou lsphp, você encontrou o culpado primário. O próximo passo é descobrir exatamente qual script PHP está exigindo tanto do processador.

Para aprofundar a investigação, ative o slow log do PHP-FPM. Edite o arquivo de configuração do seu pool (geralmente localizado em /etc/php/8.1/fpm/pool.d/www.conf) e descomente as diretivas de log. Defina request_slowlog_timeout = 5s. Reinicie o serviço. A partir desse instante, qualquer execução que demorar mais de 5 segundos será registrada no arquivo de log especificado.

Se o processo PHP estiver travado e você não souber o motivo, use a ferramenta strace. Executando strace -p ID_DO_PROCESSO, você visualiza as chamadas de sistema em tempo real. Muitas vezes, o PHP está apenas aguardando a resposta de uma API externa lenta. Para dominar todas as diretivas, acesse o Manual de Configuração do PHP-FPM.

⚠️ Atenção: Nunca deixe o slow log ativado com um tempo muito baixo em ambientes de produção com alto tráfego. A gravação excessiva de logs no disco criará um novo gargalo de I/O, piorando a situação.

Passo 2: Encontrando problemas no Banco de Dados

Se a CPU está tranquila e o PHP não registra lentidão interna, o próximo passo é investigar o MySQL ou MariaDB. Consultas lentas prendem as conexões do PHP, esgotam os workers disponíveis e causam o temido erro 504 Gateway Timeout no navegador do usuário.

Para investigar com precisão, ative o Slow Query Log. Acesse o console do banco digitando mysql -u root -p. Você pode habilitar o registro dinamicamente sem reiniciar o serviço em produção. Execute SET GLOBAL slow_query_log = 'ON'; seguido de SET GLOBAL long_query_time = 2;. Isso registrará qualquer consulta que demore mais de dois segundos.

Analise o arquivo gerado usando a ferramenta nativa do banco de dados. O comando mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log processa o arquivo e exibe as 10 consultas que mais se repetem. Pegue a query problemática e execute um EXPLAIN SELECT ... no console. Se o resultado mostrar “Using filesort” ou “Using temporary”, a tabela precisa de índices urgentes.

Se você gerencia múltiplos servidores via painéis de controle modernos, recomendo ler nossa análise sobre RunCloud, ServerPilot, Ploi ou Forge. A maioria dessas ferramentas permite ativar os logs de lentidão com um único clique. Consulte também as melhores práticas no Guia de Otimização do MySQL.

⚠️ Atenção: O comando mysqldumpslow agrupa consultas semelhantes. Concentre sua atenção nas queries que apresentam um alto tempo de “Lock” ou que varrem milhões de linhas na métrica “Rows examined”.

Passo 3: Como diagnosticar gargalos de Disco (I/O)

Muitas vezes, a CPU e a memória RAM estão sobrando, mas a aplicação continua extremamente arrastada. Isso ocorre quando o disco físico não acompanha o volume de leitura e gravação exigido pelo software. Chamamos esse cenário de gargalo de I/O (Input/Output).

Para confirmar se o disco é o vilão da história, instale o pacote sysstat e utilize o comando iostat -dx 2. Esta ferramenta atualizará as estatísticas de uso do disco a cada dois segundos. Concentre-se na coluna %util. Se ela estiver constantemente acima de 80% ou 90%, seu dispositivo de armazenamento está fisicamente saturado.

Para descobrir exatamente qual processo está martelando o disco, instale o iotop. Ele funciona de maneira muito semelhante ao htop, mas foca exclusivamente no uso de disco por processo. Digite iotop -o para visualizar apenas os programas que estão ativamente lendo ou gravando dados naquele exato milissegundo.

Problemas severos de disco são incrivelmente comuns em servidores que rodam backups compactados em horário de pico ou bancos de dados sem memória RAM suficiente para o buffer pool. Mais detalhes técnicos podem ser vistos na página de manual do Linux para iostat.

⚠️ Atenção: Se o seu servidor ainda utiliza discos rígidos mecânicos antigos (HDD), a única solução definitiva é migrar para SSD ou NVMe. Nenhuma otimização mágica de software consegue salvar um hardware obsoleto e fisicamente lento.

Para garantir uma infraestrutura moderna e discos NVMe ultrarrápidos, recomendo testar servidores na DigitalOcean. Eles entregam excelente performance de I/O para bancos de dados pesados.

Testar DigitalOcean com Crédito Grátis

Passo 4: Verificando a saturação de Rede

Quando a aplicação está perfeitamente otimizada e o hardware tem recursos de sobra, mas os clientes finais ainda reclamam de lentidão, o bloqueio pode estar na rede. O tráfego de dados pode estar estrangulado pelo limite da porta do servidor, ataques externos ou rotas ruins de internet.

Para medir a largura de banda em tempo real, utilizo ferramentas como o vnstat ou o iftop. O comando iftop -n exibe as conexões ativas e a banda consumida individualmente por cada IP. É uma ferramenta cirúrgica para detectar ataques DDoS volumétricos ou tráfego anômalo consumindo seu link.

Para diagnosticar problemas de rota e perda de pacotes entre o usuário e o servidor, a melhor ferramenta é o mtr (My Traceroute). Ele combina as funções do ping e do traceroute, mostrando exatamente em qual salto da rede os pacotes estão sendo perdidos ou sofrendo alta latência.

Ferramentas de monitoramento externo e CDNs são vitais para mitigar problemas na borda da rede. O Cloudflare ajuda a absorver picos de tráfego antes que atinjam sua máquina. Consulte a Documentação de Rede do Cloudflare para entender o impacto do roteamento. Verifique também a velocidade de resolução do seu DNS com o comando dig.

⚠️ Atenção: Provedores de nuvem de baixo custo costumam vender instâncias virtuais com portas de rede altamente compartilhadas. Se um vizinho de servidor abusar da banda, sua conexão sofrerá as consequências diretamente.

Diagrama técnico limpo mostrando o fluxo de uma requisição web, passando pela rede, processamento do PHP, consulta ao banco de dados MySQL e armazenamento em disco NVMe.

3 Erros Comuns ao diagnosticar performance

1. Ignorar o uso de Memória Swap

Muitos administradores olham apenas para a métrica de RAM livre. Se o servidor esgotar a memória física, o sistema operacional passará a usar o disco de armazenamento como memória (fenômeno conhecido como Swap). Como o disco é infinitamente mais lento que a RAM, isso destrói a performance global. Solução: monitore a barra de swap no htop. Se estiver em uso constante, você precisa aumentar a RAM. Entenda a fundo este mecanismo na Documentação do Kernel Linux sobre Memória Virtual.

2. Configurar Workers do PHP de forma irreal

Ao tentar otimizar configurações, é um erro clássico colocar valores altíssimos na diretiva pm.max_children do PHP-FPM, acreditando que isso deixará o sistema capaz de atender mais usuários. Na prática, cada worker ativo consome uma fatia de RAM. Se você configurar mais workers do que a memória física suporta, o servidor vai travar por falta de recursos. Solução: calcule o limite exato dividindo a memória RAM livre pelo consumo médio de um único processo PHP.

3. Esquecer de analisar o tempo de resposta externo (TTFB)

Às vezes o servidor responde rápido nos testes internos, mas o usuário final continua experimentando lentidão. Isso ocorre devido à falta de cache de página ou problemas graves de latência geográfica. Solução: meça o Time to First Byte (TTFB) usando ferramentas externas de auditoria. A implementação de uma CDN moderna e regras de cache no servidor web (como Nginx FastCGI Cache) resolve boa parte desse problema sem exigir upgrades de hardware.

Conclusão e Próximos Passos

Descobrir a raiz de um projeto web arrastado exige método científico, não adivinhação. Ao isolar sistematicamente os componentes de CPU, banco de dados, disco e rede, você para de aplicar soluções genéricas e ataca o gargalo exato que está prejudicando a performance. Ao testar na prática, percebo que a esmagadora maioria dos problemas reside em consultas ruins no banco de dados ou infraestrutura subdimensionada.

O próximo passo lógico é implementar um monitoramento contínuo na sua infraestrutura. Não espere os visitantes reclamarem no suporte. Configure alertas automáticos baseados em limites de consumo de CPU e tempo de resposta. Se o seu projeto escalou e a otimização de software chegou ao limite técnico, considere migrar para servidores dedicados ou instâncias em nuvem com recursos isolados.

Perguntas Frequentes (FAQ)

1. Como saber se o problema é o meu provedor de hospedagem?

Se você já otimizou seu código rigorosamente, adicionou índices nas tabelas do banco de dados, implementou cache de página agressivo e ainda sofre com lentidão constante ou picos de instabilidade, o problema muito provavelmente é o provedor limitando seus recursos físicos de forma arbitrária.

2. O que significa Steal Time na CPU?

Em servidores virtuais (VPS) e ambientes de nuvem, o Steal Time (exibido como ‘st’ no comando top) indica a porcentagem de tempo que a sua máquina virtual precisou esperar pela CPU física. Isso acontece porque o provedor sobrecarregou o servidor principal com muitos clientes. Se o Steal Time passar de 5% com frequência, mude de host imediatamente.

3. O uso de Cache resolve todos os problemas de performance?

Não. O cache de página resolve a lentidão apenas para visitantes anônimos que consomem conteúdo estático. Se o gargalo estiver em áreas dinâmicas, como no checkout de uma loja virtual, no painel administrativo ou em fóruns de usuários logados, o cache tradicional é ignorado. Nesses casos, você precisará otimizar o PHP e o banco de dados.

4. Qual a diferença entre lentidão no front-end e no back-end?

Lentidão no back-end significa que o servidor físico demora para processar os dados e gerar o HTML inicial (alto TTFB). Lentidão no front-end significa que o servidor responde rápido, mas elementos como imagens gigantes, scripts bloqueadores de renderização ou CSS mal otimizado demoram para ser processados pelo navegador do visitante.

5. Como identificar se um plugin específico está causando o gargalo?

A forma mais técnica e precisa é utilizar ferramentas de APM (Application Performance Monitoring), como o New Relic ou o Datadog. Elas rastreiam a requisição web no nível do código-fonte e apontam exatamente qual função, gancho (hook) ou plugin consumiu a maior parte do tempo de processamento da CPU.