Toda hospedagem compartilhada tem limites. O problema não é que eles existam — é que quase ninguém explica o que significam antes de você esbarrar num deles.
Você vê no painel palavras como inode, entry processes e I/O, com números ao lado, e nenhuma indicação do que fazer. Ou pior: o site começa a falhar, e a mensagem de erro não menciona limite nenhum.
Este guia explica cada um deles: o que é, o valor típico, como ver o seu consumo, o que acontece ao estourar, e o que fazer.
| Onde ver o consumo | cPanel → Uso de recursos, na barra lateral |
| O limite que mais surpreende | Inode — estoura com espaço sobrando |
| O que derruba o site em pico | Entry processes — e o erro é 508 |
| O que causa lentidão silenciosa | CPU e I/O — o site fica lento sem sair do ar |
| Por que os limites existem | Para que um site não derrube os vizinhos |
Conteúdo
Por que existem limites
Numa hospedagem compartilhada, dezenas ou centenas de sites dividem o mesmo servidor físico. Se um deles consumisse tudo, todos os outros parariam.
Foi exatamente o que acontecia antes. Um site com pico de acesso, um script mal escrito ou um plugin em loop derrubavam o servidor inteiro — e os demais clientes ficavam fora do ar sem ter feito nada.
Os limites são o que impede isso. Cada conta recebe uma fatia, e quando ela é atingida, só aquela conta é afetada.
Hoje isso é feito por tecnologia específica, o CloudLinux, que isola CPU, memória e processos por conta. Nosso guia sobre CloudLinux explica o mecanismo.
⚠️ A consequência prática: quando o seu site atinge um limite, o problema é seu, não do servidor. O suporte pode aumentar o limite ou ajudar a reduzir o consumo — mas o servidor está funcionando normalmente para todos os outros.
Onde ver o seu consumo
No cPanel, o item se chama “Uso de recursos” — normalmente na barra lateral direita, ou em Métricas.
Ele mostra três coisas:
O consumo atual de cada recurso, em porcentagem do limite.
O histórico, com os picos das últimas 24 horas ou dos últimos dias.
E as falhas — quantas vezes cada limite foi atingido no período.
⚠️ A coluna de falhas é a mais importante e a menos olhada. Se ela mostra qualquer número diferente de zero, aquele limite está sendo atingido — e provavelmente alguém viu o site falhar.
No DirectAdmin, a informação fica em Uso de recursos ou Estatísticas da conta, com nomes parecidos.
Os limites, um por um
| Limite | O que limita | O que acontece ao estourar |
|---|---|---|
| Inode | A quantidade de arquivos e pastas | Nada novo pode ser criado |
| Entry processes | Visitantes simultâneos processando algo | Erro 508 para os excedentes |
| CPU | O processamento usado pela conta | O site fica lento, sem sair do ar |
| Memória física | A RAM disponível para a conta | Erro 500 ou tela branca |
| I/O | A velocidade de leitura e escrita no disco | Tudo fica lento — inclusive o painel |
| NPROC | O total de processos da conta | Processos novos são recusados |
| Espaço em disco | O armazenamento total | Upload falha e e-mails são recusados |
| Tráfego mensal | Os dados transferidos no mês | Varia: suspensão ou cobrança extra |
Inode: o limite que mais surpreende
Cada arquivo ou pasta na sua conta consome um inode — independentemente do tamanho. Um arquivo de 1 KB e um de 1 GB consomem exatamente o mesmo: um.
⚠️ É por isso que ele surpreende: você pode estar usando 10% do espaço em disco e 100% dos inodes.
O que consome inode sem você perceber
As miniaturas de imagem. O WordPress gera de cinco a dez versões de cada imagem enviada — mil fotos podem virar oito mil arquivos.
Os e-mails. Cada mensagem na caixa é um arquivo. Uma conta com 20 mil e-mails guardados consome 20 mil inodes.
O cache. Plugins de cache criam um arquivo por página visitada, e alguns não limpam sozinhos.
E os backups antigos dentro da própria conta — cada arquivo dentro do pacote conta.
Como reduzir
Esvazie a lixeira e o spam das contas de e-mail. É a medida que mais libera de uma vez.
Limpe o cache pelo plugin, e configure a expiração automática.
Apague backups antigos da conta — e mantenha-os fora do servidor.
E remova miniaturas não usadas, com plugins que identificam tamanhos que o tema não utiliza.
Como ver o consumo
No cPanel, em “Uso de recursos” ou no resumo lateral, aparece como File Usage ou Inodes.
Para descobrir onde estão, o Gerenciador de Arquivos não ajuda — ele mostra tamanho, não quantidade. ⚠️ Se você tem acesso SSH, o comando que resolve é:
for d in */; do echo "$(find "$d" | wc -l) $d"; done | sort -rn | head Ele lista as dez pastas com mais arquivos, da maior para a menor.
Entry processes: o que derruba o site no pico
É o limite mais confundido de todos — e o que mais causa site fora do ar em campanha.
Entry process não é visitante. É uma requisição sendo processada naquele instante. Se uma página leva 0,2 segundo para ser gerada, um único processo atende cinco visitantes por segundo.
⚠️ Por isso um plano com 20 entry processes não significa 20 visitantes simultâneos — significa muito mais, desde que o site seja rápido.
E é aqui que a matemática vira contra você: um site lento consome processos por mais tempo, e estoura o limite com menos visitantes.
O sintoma
Erro 508 — Resource Limit Is Reached. Os visitantes excedentes veem essa mensagem enquanto os demais navegam normalmente.
E ele é intermitente: aparece no pico e some depois, o que dificulta o diagnóstico.
Como reduzir
Cache é a solução principal. Uma página servida do cache não gera processo PHP nenhum — é o que multiplica a capacidade do mesmo plano.
Corte plugins pesados, sobretudo os que rodam consulta ao banco em toda visita.
E desative o wp-cron padrão, substituindo por cron real do servidor. O wp-cron dispara a cada visita, e num site com tráfego isso consome processo constantemente.
CPU e I/O: a lentidão que ninguém explica
Esses dois não derrubam o site — deixam tudo lento, o que é pior de diagnosticar.
O limite de CPU é medido em porcentagem de um núcleo. Ao atingi-lo, os processos da conta são desacelerados, não interrompidos.
O limite de I/O é a velocidade de leitura e escrita em disco, em KB por segundo. Quando ele satura, até o painel de controle fica lento — porque ele também lê do disco.
⚠️ O sintoma característico: o site está lento, o servidor está normal, e o plugin de teste de velocidade não acusa nada. Só o gráfico de uso de recursos mostra.
O que costuma consumir
Consultas pesadas ao banco — plugins de estatística, relacionados, e busca sem índice.
Processamento de imagem no upload, sobretudo se o tema gera muitas miniaturas.
Backup rodando em horário de pico — é I/O intenso e concorre com os visitantes.
E bots. ⚠️ Rastreadores agressivos consomem CPU e I/O sem trazer visitante nenhum — e desde que os robôs de IA começaram a rastrear em volume, isso virou causa comum.
Memória: o erro 500 sem explicação
O limite de memória física é a RAM disponível para os processos da conta.
Ao estourar, o processo é encerrado — e o visitante vê erro 500 ou tela branca, sem mensagem.
⚠️ E há uma confusão comum aqui. O WP_MEMORY_LIMIT do WordPress e o memory_limit do PHP não ultrapassam o limite da conta. Se o plano dá 512 MB e você configura 1 GB no wp-config.php, o limite real continua sendo 512.
Nosso guia sobre memory_limit explica a hierarquia.
Espaço e tráfego
Espaço em disco é o mais intuitivo — e ao estourar, o efeito passa despercebido por um tempo: o site continua no ar, mas os uploads falham e as contas de e-mail param de receber.
⚠️ Essa última é a que causa prejuízo. Um cliente envia um orçamento, a mensagem é recusada por caixa cheia, e ninguém fica sabendo.
Tráfego mensal é a soma dos dados transferidos. Para um site comum, o limite raramente é atingido — quem esbarra nele costuma servir vídeo, download ou imagens muito pesadas.
E o que fazer é diferente do resto: um CDN serve os arquivos estáticos de fora do seu servidor, o que reduz o tráfego contabilizado.
O que fazer quando um limite estoura
Três caminhos, nesta ordem.
1. Reduza o consumo. É o certo na maioria dos casos, e o mais barato. Cache, limpeza de inodes, corte de plugin pesado. Boa parte dos limites estourados vem de acúmulo, não de crescimento.
2. Aumente o limite. Muitos provedores ajustam limites pontualmente, sobretudo os de inode e de entry processes, se o consumo for justificável.
3. Mude de plano. Se o consumo é real e recorrente, o site cresceu — e seguir espremendo é remendo.
⚠️ Como saber qual é o seu caso: se o limite volta a estourar poucos dias depois de uma limpeza, é crescimento. Se a limpeza resolve por meses, era acúmulo.
Quando é hora do VPS
Não é quando um limite estoura uma vez. É quando:
Vários limites estouram ao mesmo tempo, com frequência.
A limpeza não segura mais que algumas semanas.
Ou você precisa de algo que a compartilhada não oferece — acesso root, versão específica de software, serviço próprio.
Nosso guia sobre VPS cobre o que muda.
Na Homehost, o consumo de cada recurso fica no painel, com histórico — você vê o que está apertando antes de o site falhar. O CloudLinux isola cada conta para que o vizinho não consuma os seus recursos, e o suporte em português ajuda a identificar o que reduzir. A partir de R$ 7,90/mês, com migração gratuita.
Ver planos de hospedagemPerguntas frequentes
O que é inode numa hospedagem?
É a unidade que conta arquivos e pastas, não espaço. Cada arquivo consome um inode, independentemente do tamanho — por isso é possível estourar o limite usando 10% do disco. As maiores fontes de consumo são miniaturas de imagem, e-mails guardados e arquivos de cache.
O que significa o erro 508?
Que o limite de entry processes foi atingido — há mais requisições sendo processadas ao mesmo tempo do que o plano permite. É intermitente por natureza: aparece no pico de acesso e some depois. Cache é a solução principal, porque páginas servidas do cache não geram processo.
Entry processes é o mesmo que visitantes simultâneos?
Não, e confundir os dois leva a conclusões erradas. Entry process é uma requisição sendo processada naquele instante. Se uma página leva 0,2 segundo para ser gerada, um processo atende cerca de cinco visitantes por segundo. Um site rápido atende muito mais gente com o mesmo limite.
Onde vejo o consumo de recursos da minha conta?
No cPanel, em Uso de recursos, normalmente na barra lateral ou em Métricas. Ele mostra o consumo atual, o histórico e — o mais importante — quantas vezes cada limite foi atingido no período. No DirectAdmin, a informação fica em Uso de recursos ou Estatísticas da conta.
Estourei o limite de CPU. O site sai do ar?
Não. Diferente dos limites de processo e memória, o de CPU desacelera em vez de interromper: o site continua funcionando, mas fica lento. É o sintoma mais difícil de diagnosticar, porque nenhum erro aparece — só o gráfico de uso de recursos mostra.
Por que aumentar o memory_limit não resolveu?
Porque ele não ultrapassa o limite da conta. Se o plano dá 512 MB e você configura 1 GB no wp-config.php ou no php.ini, o limite real continua sendo 512 — a configuração pede mais do que existe.
O que consome tantos inodes no WordPress?
Três coisas, nesta ordem: as miniaturas de imagem, porque o WordPress gera de cinco a dez versões de cada foto enviada; os e-mails guardados, já que cada mensagem é um arquivo; e o cache, que cria um arquivo por página visitada.
Bots consomem meus recursos de hospedagem?
Sim, e sem trazer visitante nenhum. Rastreadores agressivos geram requisições que consomem CPU, I/O e entry processes exatamente como um visitante real. É causa cada vez mais comum, desde que os robôs de IA começaram a rastrear em volume.
O que acontece quando o espaço em disco enche?
O site continua no ar, mas os uploads falham e as contas de e-mail param de receber mensagens. Esta última é a que causa prejuízo sem aviso: um cliente envia algo, a mensagem é recusada por caixa cheia, e ninguém fica sabendo.
Posso pedir para aumentar um limite?
Na maioria dos provedores, sim — sobretudo os de inode e entry processes, que costumam ser ajustáveis se o consumo for justificável. Vale sempre tentar reduzir primeiro, porque boa parte dos limites estourados vem de acúmulo e não de crescimento real.
Como saber se preciso de um VPS?
Não é quando um limite estoura uma vez. É quando vários estouram com frequência, quando a limpeza não segura mais que algumas semanas, ou quando você precisa de algo que a compartilhada não oferece — acesso root ou software específico.
Por que existem limites se o plano é “ilimitado”?
Porque “ilimitado” costuma se referir a um recurso específico, normalmente espaço ou tráfego — e mesmo esses têm uma cláusula de uso justo nos termos. Os limites de CPU, memória, processos e inode continuam existindo, porque sem eles um site derrubaria todos os outros do servidor.
Conclusão
Os limites de uma hospedagem compartilhada não são uma armadilha do provedor — são o que impede que o site de outra pessoa derrube o seu. O problema nunca foi a existência deles, e sim a falta de explicação sobre o que significam.
Três ideias resolvem a maior parte dos casos. O inode conta arquivos, não espaço — e estoura com disco sobrando. Entry process não é visitante: um site rápido atende muito mais gente com o mesmo limite, e é por isso que cache multiplica a capacidade do plano. E CPU e I/O não derrubam o site, só o deixam lento — o que os torna os mais difíceis de diagnosticar.
E o hábito que evita a surpresa: olhe o “Uso de recursos” do painel uma vez por mês, e preste atenção na coluna de falhas. Se ela mostra número diferente de zero, algum limite já está sendo atingido — e alguém já viu o seu site falhar.
