Site lento na Hostinger: como ler CPU, I/O, RAM e PHP workers antes de trocar de plano

Fala aí, beleza? Abriu o hPanel e deu de cara com o aviso "Your websites could experience slower performance" na página Resources Usage?

Esse recado quer dizer que o plano encostou em algum limite, e a documentação da Hostinger sobre limites atingidos separa isso em quatro grupos: CPU, I/O, RAM e processos, e PHP workers

Cada grupo dá um sintoma diferente, e a própria Hostinger coloca o upgrade como passo DEPOIS de otimizar sem resultado

Então antes de passar o cartão, bora descobrir qual deles está apertando 🙂

Onde ver o uso de recursos da Hostinger e como ler os gráficos

Os gráficos ficam na página Resources Usage do hPanel, e é ali que você descobre qual limite está sendo atingido

O guia de uso de recursos explica o caminho e o que cada gráfico mostra, se liga no passo a passo:

1. Abra a página de uso de recursos. Em planos web ou cloud, o caminho documentado é Websites > Dashboard (do site) > Hosting plan > Resources Usage, e no plano Agency é Websites > Dashboard > Resources Usage

O erro comum deste passo: procurar exatamente esses nomes e travar. A interface do hPanel pode ser atualizada, então procure pela página Resources Usage dentro do site

2. Identifique as métricas exibidas: CPU, Memory (RAM), Throughput (I/O), PHP Workers, Storage performance (IOPS) e Max processes

3. Procure a linha vermelha em cada gráfico. Ela marca o limite do plano, e o recomendado é que os sites nem encostem nela

4. Troque da visão ao vivo para o histórico de 6 horas, 24 horas e 7 dias

O erro comum deste passo: olhar só o ao vivo, ver tudo tranquilo e concluir que não tem problema. Um pico que aconteceu de madrugada só aparece no histórico!

Como validar: no fim tu precisa ter anotado duas coisas, qual gráfico encosta na linha vermelha e com que frequência isso acontece

Com isso em mãos, é só pular pra seção do limite certo

Limite de CPU na Hostinger: site lento sem mensagem de erro

Quando o plano bate no limite de CPU, o site não quebra: ele fica lento e passa a enfileirar as requisições dos visitantes em vez de atender na hora

Por isso esse é o mais traiçoeiro, não aparece erro nenhum e o visitante só sente a demora…

Causa mais comum, segundo a Hostinger: código mal otimizado rodando a cada acesso

Sinais adicionais para checar nas análises do site: requisições loopback (o site chamando ele mesmo) ou tráfego com sinais de ataque DDoS, que também podem gerar excesso de CPU ou RAM

O que fazer:

• Revisar o código
• Reduzir os plugins
• Diminuir os cron jobs ao mínimo necessário
• Ativar cache
• Checar nas análises do site se há requisições loopback ou sinais de DDoS

Como prevenir: depois de cada mudança (plugin novo, cron novo, tema novo), dá uma olhada no histórico de CPU e vê se a curva subiu

Limite de I/O de disco: quando leitura e escrita deixam o site lento

I/O é o limite da velocidade de leitura e escrita de dados no disco, e quando o plano bate nele o site fica lento, igualzinho acontece com a CPU

Pensa assim: não adianta ter processador sobrando se o disco está numa fila pra entregar os arquivos haha

O que fazer:

• Ativar cache. No WordPress, a Hostinger recomenda o plugin LiteSpeed Cache
• Analisar a velocidade do site pra descobrir quais páginas e arquivos (imagens, scripts e etc) precisam de otimização

Como prevenir: monitorar os gráficos Throughput (I/O) e Storage performance (IOPS) no histórico, principalmente depois de subir muito conteúdo novo

Limite de RAM e processos: por que aparece o erro 503

Se o plano atinge o limite de processos ou de RAM, os visitantes podem receber o erro 503 Service Unavailable

Aqui o site não fica só lento, ele simplesmente não responde pra parte das pessoas

E o que conta como processo?

O limite de processos (NPROC) soma TODOS os processos e threads do plano, não só apps Node.js, e é compartilhado por todos os sites do plano

Ou seja, se tu tem cinco sites no mesmo plano, um deles pode estar comendo o limite dos outros quatro

O que fazer: reduzir os processos ao mínimo, revisando o que cada site roda em paralelo

Critério documentado: se o limite de processos ou RAM for atingido de 10 a 20 vezes no mesmo mês, a orientação é reduzir os processos ao mínimo e fazer upgrade se o problema continuar

Como prevenir: olhar Max processes e Memory no histórico de 7 dias, contando quantas vezes a linha vermelha foi tocada

App Next.js com muitos processos na hospedagem web: o que o redeploy resolve

App Next.js em hospedagem web costuma pesar no limite de processos, e muitas vezes um redeploy pelo painel já resolve isso

O motivo está nos limites de Node.js da Hostinger: um app Next.js pode usar cerca de 10 a 11 threads, e dominio.tld e www.dominio.tld rodam cada um em um processo separado

Soma isso ao NPROC compartilhado e tu entende por que o 503 aparece rápido: segundo a documentação de Node.js da Hostinger, o app pode retornar 503 ao atingir o limite de processos

A boa notícia: em planos de hospedagem web, a plataforma tem uma otimização para apps Next.js que reduz bastante os processos criados em execução, e deploys novos já vêm com ela aplicada

Pra aplicar num app que já existe:

1. Abra o dashboard do site e vá em Deployments
2. Clique em Redeploy
3. Revise as configurações e clique em Save and Redeploy
4. Depois volte em Resources Usage e acompanhe o gráfico de Max processes

Pra ter noção do teto, esses são os limites de processos para Node.js documentados por plano:

Plano	Processos	Entry processes
Business / Unlimited	120	60
Cloud Startup	200	100
Cloud Professional	400	200
Cloud Enterprise	600	300
Cloud Enterprise Plus	800	400

Tome cuidado! Tem limitação que não é falta de recurso: em todos os planos web e cloud, Node.js interrompe a requisição depois de 120 segundos, e não há suporte a WebSockets de entrada nem a workers de fundo sempre ativos

Se teu app depende disso, subir de plano não muda nada, o problema é de arquitetura

Limite de PHP workers: atrasos e timeouts no WordPress

Cada PHP worker processa uma requisição por vez, e quando todos estão ocupados os usuários podem ter atrasos ou timeouts

É como caixa de supermercado: cada caixa atende um cliente por vez, e se todos estão ocupados a fila cresce até alguém desistir 😛

O que fazer:

• Reduzir plugins e scripts que disparam processos PHP
• Usar cache pra executar menos PHP

Isso vale pra WordPress e também pra quem fez um site PHP com banco de dados na hospedagem compartilhada: quanto menos PHP roda por visita, menos workers ficam presos

Se mesmo assim o site atinge o limite de forma constante, aí sim vale considerar upgrade. Pra um aumento temporário, existe o boost

Como prevenir: acompanhar o gráfico de PHP Workers em horários de pico, tipo depois de mandar uma newsletter ou postar algo que viraliza

Quando usar o boost de recursos em vez de fazer upgrade

O boost da Hostinger dá ao plano a capacidade de um plano superior por 24 horas, e serve pra situações pontuais, não pra problema que se repete todo dia

Usos indicados pela documentação:

• Pico temporário de tráfego
• Importação de muitos dados
• Atualização completa do site
• Teste de um plano maior antes de fazer upgrade

Esse último é o mais útil aqui: tu ativa o boost, observa os gráficos e vê se a linha vermelha para de ser tocada

Se parar, o upgrade tende a resolver. Se continuar batendo, o problema provavelmente é otimização e não tamanho de plano

Regras do boost:

• O gratuito pode ser ativado uma vez por mês e volta a ficar disponível um mês depois do último uso
• Não existe no Cloud Enterprise Plus
• Há boost pago de 7 ou 30 dias, só para Cloud Startup, Cloud Professional e Cloud Enterprise

Como ativar o gratuito: Websites > Dashboard > Resources Usage > Boost resources > Boost. A mensagem de boost ativado aparece na seção Order usage

Otimizar ou trocar de plano: critério para decidir o upgrade na Hostinger

O critério observável é simples: o limite continua sendo atingido DEPOIS que você aplicou as otimizações daquele grupo

Para processos e RAM, a referência documentada é bater o limite de 10 a 20 vezes no mesmo mês com o problema persistindo

Quando isso acontece, a Hostinger considera que o site cresceu e precisa de mais recursos

Agora, se a causa é um cron rodando a cada minuto, um plugin travando ou um app Next.js sem redeploy, comprar plano maior só esconde o problema por um tempo… Configuração se corrige, não se compra

Se tu já passou por tudo isso e o gráfico continua colado na linha vermelha, o caminho mais tranquilo é subir dentro da própria Hostinger (link de afiliado da Hostinger) para um plano web maior ou para Cloud Hosting

O motivo técnico é que, segundo a própria Hostinger, upgrades de planos web e cloud valem na hora, e arquivos, e-mails e bancos de dados vão para o novo plano automaticamente (no upgrade de hospedagem web para Cloud, só o endereço IP muda)

O upgrade fica em Websites > (⋯) ao lado do plano > Upgrade ou pela área Billing

E a VPS?

Não existe upgrade direto de hospedagem web ou Cloud para VPS: é preciso contratar a VPS à parte e migrar o conteúdo manualmente

Por isso ela só faz sentido quando otimização e Cloud não resolveram, ou quando teu projeto precisa de algo que a hospedagem web não oferece (como os WebSockets de entrada que vimos no caso do Node.js)

Conteúdo extra do canal

Curte usar IA pra aprender programação mais rápido? Esse vídeo do canal Hora de Codar mostra como acelerar o aprendizado com IA 😀

Conclusão

Teu próximo passo é abrir Resources Usage agora, trocar pro histórico de 7 dias e anotar qual gráfico encosta na linha vermelha

Achou o culpado? Aplica a ação daquele limite (cache, menos plugins, menos cron, redeploy do Next.js) e volta nos gráficos alguns dias depois pra comparar

Se o aperto continuar mesmo assim, aí o site realmente cresceu, e vale olhar os planos maiores e o Cloud da Hostinger com o boost como teste antes de decidir

Até o próximo post! 🙂

Perguntas frequentes

PHP workers esgotados é a mesma coisa que atingir o limite de processos (NPROC)?

Não, são dois grupos separados de limite. PHP workers controlam quantas requisições PHP rodam ao mesmo tempo e, quando esgotam, geram atrasos ou timeouts; o NPROC soma todos os processos e threads do plano (incluindo apps Node.js) e, quando esgota, pode gerar erro 503.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.