Solucionar performance no Plesk Web Host Edition Linux

Solucionar performance no Plesk Web Host Edition Linux consiste em ajustar PHP-FPM, OPcache, workers do servidor web, cotas por assinatura e cache HTTP com base em RAM livre, processos ativos e TTFB real. Sem esses parâmetros alinhados ao hardware, o painel e os sites ficam lentos mesmo com CPU ociosa. Para recuperar desempenho de forma controlada, siga estes passos:

1. Meça CPU, RAM, swap, I/O e TTFB antes de alterar qualquer limite
2. Ajuste o pool PHP-FPM (pm, max_children, memory) por domínio ou plano
3. Ative e dimensione OPcache na versão PHP em uso (8.3/8.4)
4. Escolha o modo Nginx, Apache ou Nginx+Apache e habilite HTTP/2 e compressão
5. Revise cotas de CPU/RAM/I/O por assinatura e agende backups fora do pico
6. Recarregue serviços, valide logs e reteste sob carga real

Pré-requisitos

• Acesso de administrador ao Plesk Web Host Edition em servidor Linux (Debian 13, Rocky Linux 10 ou AlmaLinux 10)
• SSH com root ou sudo para tuning de sistema e leitura de logs
• PHP 8.3 ou 8.4 com handler PHP-FPM habilitado nos domínios críticos
• Backup recente das configurações de domínio, planos de serviço e arquivos em /etc/php e /etc/nginx (ou Apache)
• Ferramentas de diagnóstico: htop, ss, free, iostat e acesso aos logs do Plesk
• Janela de manutenção curta para recarregar PHP-FPM e o servidor web sem downtime prolongado

Diagnosticar gargalos antes de tunar o Plesk Web Host Edition

O primeiro passo para solucionar performance no Plesk Web Host Edition Linux é separar lentidão do painel, de um domínio específico ou do servidor inteiro. Muitos administradores sobem max_children ou cotas sem medir, e o resultado é swap, erros 502 e filas de PHP. Comece pelo estado da máquina e pelo TTFB dos sites mais acessados.

No SSH, colete um baseline rápido de memória, carga e portas em escuta:

free -h
uptime
ss -tulpn | head -n 40
df -h
plesk bin php_handler --list

Output esperado:
               total        used        free      shared  buff/cache   available
Mem:            15Gi       9.2Gi       1.1Gi       400Mi       5.1Gi       5.8Gi
Swap:          2.0Gi       600Mi       1.4Gi
 14:02:11 up 42 days,  3:11,  2 users,  load average: 2.41, 1.98, 1.55

Se a memória disponível estiver baixa e o swap em uso constante, qualquer aumento de workers PHP piora a latência. Verifique processos PHP-FPM e o consumo por usuário de assinatura:

ps aux --sort=-%mem | head -n 25
plesk db "SELECT name, real_name FROM domains LIMIT 20"

No painel, abra Ferramentas e configurações e revise o uso de recursos por assinatura, filas de backup e tarefas agendadas. Compare o TTFB com uma requisição local ao domínio de teste seudominio.com.br. Valores altos com CPU baixa costumam apontar para pool PHP subdimensionado, OPcache desligado, disco saturado por backups simultâneos ou Apache processando estáticos sem Nginx na frente. Documente números antes e depois de cada mudança; sem baseline, não há como provar ganho. Em ambientes de acesso a servidores VPS Linux, mantenha uma sessão SSH de monitoramento aberta enquanto aplica os ajustes no Plesk.

Otimizar PHP-FPM e OPcache no Plesk para reduzir TTFB

O pool PHP-FPM é o ponto de maior impacto quando o objetivo é recuperar velocidade de páginas dinâmicas no Plesk. Cada domínio ou plano pode usar handler próprio; altere com cuidado para não esgotar RAM em VPS com muitos clientes. Prefira pm = dynamic em tráfego estável e ondemand em sites esporádicos. Calcule pm.max_children pela memória livre reservada a PHP, não pelo valor “máximo” do assistente.

Exemplo de raciocínio: com 4 GB livres para PHP e média de 80 MB por processo, max_children próximo de 40–45 é teto seguro inicial. No Plesk, vá em Domínios → seudominio.com.br → PHP, confirme FPM e abra as configurações adicionais, ou edite o pool via CLI quando necessário:

plesk bin domain --update-php-settings seudominio.com.br -settings opcache.enable=1
grep -E 'pm\.|memory_limit' /var/www/vhosts/system/seudominio.com.br/etc/php-fpm.conf

Output esperado:
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
memory_limit = 256M

Atenção: não multiplique max_children em todos os domínios ao mesmo tempo. Ajuste os cinco sites mais pesados, recarregue o serviço da versão PHP correspondente e observe RAM por 15–30 minutos.

systemctl reload plesk-php84-fpm
systemctl status plesk-php84-fpm --no-pager

Output esperado:
Active: active (running)
# sem falhas de "seems busy" ou "max_children reached" nos logs recentes

Ative OPcache com memória coerente (128M–256M conforme quantidade de código) e valide com um phpinfo restrito ou CLI do handler Plesk. Combine com memory_limit realista (128M–256M para CMS comuns; mais só se a aplicação exigir). Monitore error_log do domínio após cada alteração. Se aparecerem 502 logo após o reload, reduza children ou aumente timeouts do proxy Nginx→Apache/FPM. Para stacks mistos e comparação de painéis, o material sobre hospedagem de sites vs. VPS ajuda a dimensionar se o hardware atual comporta o número de assinaturas ativas.

Ajustar Nginx, Apache e cache HTTP no servidor web do Plesk

O modo de servidor web define como estáticos e dinâmicos competem por CPU. No Plesk Web Host Edition, Nginx na frente (com ou sem Apache atrás) costuma entregar melhor concorrência e menor uso de processos por arquivo estático. Apache isolado permanece útil quando há forte dependência de .htaccess, mas exige KeepAlive e limites de worker bem calibrados.

Em Ferramentas e configurações → Configurações do servidor Apache e nginx, ative proxy Nginx, HTTP/2 e compressão gzip (e Brotli se o pacote estiver disponível na distro). Evite regras de cache agressivas em áreas logadas de CMS. Para um domínio de teste:

plesk bin domain_settings --update seudominio.com.br -nginx-http2 true
curl -sI --http2 https://seudominio.com.br | head -n 15

Output esperado:
HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8
# cache-control coerente com a política do site

Revise buffers e timeouts se houver uploads grandes ou APIs lentas. Sintomas de proxy mal ajustado incluem 504 esporádico e TTFB irregular. Confirme que não há dois mecanismos de cache brigando (plugin de página + cache FastCGI + CDN com TTL conflitante). Em Rocky Linux 10 ou AlmaLinux 10, após mudanças manuais em templates personalizados do Plesk, reconstrua a configuração do domínio pela interface ou CLI para não perder o ajuste no próximo rebuild. Sites que redirecionam HTTP→HTTPS de forma incorreta também infliam latência percebida; valide a cadeia de redirect com o guia como redirecionar um site http para https antes de culpar só o PHP-FPM.

Para estáticos, garanta expires em assets versionados e evite passar CSS/JS desnecessariamente pelo backend Apache. Meça de novo com a mesma URL e horário aproximado do baseline. Ganho consistente de TTFB em HTML dinâmico indica pool/OPcache; ganho só em imagens/CSS indica Nginx e compressão.

Limites por assinatura, I/O e tarefas que derrubam a performance global

Mesmo com PHP e Nginx corretos, o Plesk fica lento quando muitas assinaturas estouram CPU, quando backups coincidem com cron de clientes ou quando o disco enche de logs e dumps. Cotas de CPU, RAM e I/O por assinatura existem para isolar ruído: use-as com valores realistas, não “ilimitado” em todos os planos de revenda.

Revise planos de serviço e assinaturas com picos. Reduza processos simultâneos em contas de teste. Agende backup do Plesk e dumps de banco fora do horário comercial. Verifique filas de e-mail e antivírus de anexos, que competem por I/O no mesmo volume dos vhosts.

plesk bin subscription --list
du -sh /var/lib/psa/dumps /var/www/vhosts 2>/dev/null
journalctl -u sw-engine -n 30 --no-pager

Output esperado:
seudominio.com.br
cliente2.com.br
# dumps não devem crescer sem retenção; sw-engine sem erros repetidos de timeout

Se o painel (sw-engine) estiver lento com sites rápidos, limpe sessões antigas do administrador, desative extensões Plesk não usadas e confirme que o disco do sistema não está em 95%+. Em caso de serviços que não sobem após tuning agressivo, siga o fluxo de solução de problemas de inicialização de serviços no VPS Linux antes de reverter às cegas. Tuning de kernel (fs.file-max, somaxconn) só faz sentido depois que pools e cotas estão estáveis; altere sysctl com backup e uma linha de cada vez.

Problemas comuns e como resolver

Sintoma: erro 502 Bad Gateway após subir max_children

Causa: memória esgotada, workers PHP mortos pelo OOM killer ou upstream Nginx apontando para socket FPM indisponível.
Solução: confira dmesg e logs do pool; reduza pm.max_children; recarregue plesk-phpXX-fpm; valide o socket em ss -xl | grep php-fpm e reteste o domínio.

Sintoma: painel Plesk lento com sites relativamente rápidos

Causa: sw-engine sobrecarregado, extensões pesadas, disco cheio ou muitos backups/tarefas simultâneas.
Solução: libere espaço em /var, pause extensões desnecessárias, reagende backups e reinicie de forma controlada os serviços do painel apenas se os logs confirmarem travamento.

Sintoma: max_children reached nos logs com CPU ainda folgada

Causa: pool pequeno demais para a concorrência real ou scripts lentos segurando workers.
Solução: aumente children com base na RAM; otimize consultas e cron do CMS; use pm = dynamic com spare adequado; identifique URLs lentas nos access logs antes de só escalar hardware.

Sintoma: TTFB alto só em horários de backup

Causa: contenção de I/O por dumps, rsync ou antivírus em massa.
Solução: mova janelas de backup, limite paralelismo, separe volume de backup quando possível e monitore iostat -xz 1 durante a tarefa.

Perguntas frequentes sobre solucionar performance no Plesk Web Host Edition Linux

Quais parâmetros de performance priorizar no Plesk Web Host Edition?

Priorize pool PHP-FPM (pm, max_children, memory), OPcache, worker do Nginx ou Apache, limites de CPU/RAM por assinatura e cache HTTP. Ajuste com base em RAM livre, média de processos PHP ativos e TTFB sob carga real, não só em valores padrão do painel.

Como otimizar PHP-FPM pelo Plesk sem derrubar sites?

Altere o handler e o pool por domínio ou plano, use pm=ondemand ou dynamic conforme o tráfego, defina max_children pela memória disponível e recarregue o serviço PHP-FPM. Monitore error_log e uso de RAM após cada mudança e evite max_children excessivo em VPS com pouca memória.

Nginx ou Apache no Plesk Web Host Edition é melhor para performance?

Nginx (ou Nginx com Apache atrás) costuma atender melhor estáticos e alta concorrência; Apache isolado ainda é comum com .htaccess. No Plesk, escolha o modo de servidor web alinhado ao tipo de site, ative HTTP/2 e gzip/brotli quando disponível e teste TTFB e erros 502 após trocar o stack.

O que fazer se o Plesk ficar lento após aumentar limites de clientes?

Revise cotas de CPU, RAM e I/O por assinatura, quantidade de domínios ativos, cron e backups simultâneos. Reduza max_children global, limite processos por usuário e agende tarefas pesadas fora do pico. Verifique também swap, disco e filas de e-mail que competem por I/O.

Preciso de root para tunar performance no Plesk Web Host Edition?

Muitos ajustes de domínio e PHP saem pelo painel com permissão de administrador Plesk. Tuning de sistema (sysctl, limites globais de arquivos, serviços extras) exige SSH root ou sudo no Linux. Sempre faça backup das configurações antes de editar arquivos fora da interface.

Conclusão

• Meça baseline (RAM, load, TTFB, logs FPM) antes de qualquer alteração no Plesk Web Host Edition
• Dimensione PHP-FPM e OPcache por memória real e recarregue serviços de forma gradual, domínio a domínio
• Alinhe Nginx/Apache, cotas por assinatura e janelas de backup para eliminar contenção de I/O e 502 sob pico

Leia também

• Como Instalar e Configurar o PHP-FPM no VPS Linux para Máxima Performance
• Como otimizar o MySQL para alta performance no VPS Linux (com exemplos reais)
• Passo a passo para configurar Nginx com PHP-FPM no VPS Linux: Guia Completo

Precisa de ajuda com performance no Plesk Web Host Edition?

Se o tuning de PHP-FPM, Nginx e cotas no Linux ainda deixar TTFB instável, um VPS com recursos dedicados e suporte facilita aplicar os ajustes com monitoramento contínuo.

Conhecer servidores VPS da AviraHost