Saltar para o conteúdo 
A carga irregular da CPU no WordPress é frequentemente causada por uma configuração inadequada. tarefas cron do WordPress, que são iniciados como processos em segundo plano sempre que uma página é acedida, causando picos. Mostro como esses gatilhos prolongam o TTFB, ocupam os PHP Workers e geram latências – e como pode voltar a mais uniforme Último a chegar.
Pontos centrais
A seguinte visão geral resume os aspetos mais importantes, antes de aprofundar o tema e explicar os passos concretos. Mantenho a lista curta, para que o foco permaneça em Ação e efeito.
- WP-Cron é acionado quando as páginas são acedidas e gera uma carga imprevisível.
- Processos PHP acumulam-se no tráfego e diminuem o TTFB.
- Cronograma do sistema desacopla tarefas do fluxo de visitantes.
- Intervalos e as prioridades suavizam os picos da CPU.
- Monitorização deteta gargalos e eventos com erros.
O que os cronjobs do WordPress realmente fazem – e de onde vem a carga
O WordPress utiliza um sistema pseudo-cron: quando chamado, o wp-cron.php é acionado por POST, verifica eventos pendentes e inicia tarefas como publicações, verificações de atualizações, salvamento de rascunhos via Heartbeat e limpeza do banco de dados – cada evento custa tempo de CPU. Essa abordagem parece confortável, mas causa gatilhos incontroláveis, porque as visitas determinam a execução e não um temporizador programável. Quando várias chamadas ocorrem ao mesmo tempo, processos PHP paralelos são iniciados, competindo por trabalhadores. As configurações multisite amplificam o efeito, pois cada subsite mantém a sua própria pilha de eventos, aumentando assim o número de verificações [1]. Quem quiser aprofundar os conhecimentos sobre o assunto encontrará bases sólidas em Entender o WP-Cron, mas a mensagem principal permanece: o direcionamento de visitantes não é adequado como um método fiável relógio.
O verdadeiro travão: processos PHP paralelos através do wp-cron.php
Cada acionador Cron inicia um processo PHP separado, que vincula um trabalhador e, assim, a disponibilidade tempo de computação para renderizações reais de páginas. Se os gatilhos se acumularem, o tempo de espera por um trabalhador livre aumenta, o TTFB se prolonga e o primeiro byte chega mais tarde ao navegador [2]. As medições mostraram um atraso de até 800 milissegundos, o que sobrecarrega o Core Web Vitals e diminui a visibilidade orgânica [3]. A hospedagem partilhada ou configurações PHP-FPM restritas agravam o efeito, porque max_children é rapidamente atingido e os processos ficam em filas de espera. Especialmente durante picos de lojas ou campanhas, isso pode se tornar um círculo vicioso: mais tráfego gera mais verificações cron, que por sua vez bloqueiam a renderização e assim Tempos de carregamento esticar [1][2].
Lidar corretamente com cache, CDN e armadilhas de loopback
O WP-Cron utiliza por predefinição um Pedido de loopback para o seu próprio domínio. Se houver um cache de página agressivo, um CDN ou um bloqueio de autenticação básica, a chamada pode falhar ou ficar em espera – as execuções cron ficam paradas, repetem-se e, assim, prolongam a ligação da CPU. Por isso, certifico-me de que /wp-cron.php não é armazenado em cache, não tem limite de taxa e é acessível internamente. O cron do sistema atenua essa vulnerabilidade porque sem HTTP-Loopback executa diretamente PHP. Se houver um proxy a montante, verifico adicionalmente se as solicitações para 127.0.0.1 serem transmitidos corretamente e nenhuma regra WAF bloqueie o ponto final. Nas fases de manutenção, é importante: ou pausar o Cron conscientemente ou deixar o ponto final passar explicitamente, para que as tarefas vencidas não sejam „repetidas“ como pacote.
Detectar e classificar cargas irregulares da CPU
São típicos os picos de carga nas horas de ponta, que não se explicam apenas pelo número de visitantes, mas por ondas cron de eventos atrasados que se acumulam e disparam em conjunto. As instalações multisite multiplicam a carga, uma vez que cada subsite gere listas cron e é verificado durante a visita – isto resulta em picos curtos, mas intensos, que os ficheiros de registo mostram como cascatas de wp-cron.php-POSTs [1]. Frequentemente, os plugins registam os seus próprios eventos com intervalos muito curtos, por vezes a cada cinco minutos ou mais, o que, com dez plugins, rapidamente se soma a dezenas de verificações por chamada. Preste também atenção ao seu Limite de PHP Workers, pois os trabalhadores sobrecarregados forçam tempos de espera que os utilizadores sentem diretamente. Quem lê esses padrões entende a curva irregular como consequência de gatilhos, não como inevitável. humor do tráfego.
Por que o System Cron suaviza a carga
Um verdadeiro cron do sistema separa as tarefas do fluxo de visitantes e define um ritmo claro, por exemplo, a cada cinco minutos, hora ou dia – assim, a execução pode ser planeada e a carga é distribuída uniformemente [1][6]. Os visitantes deixam de acionar tarefas cron, o que alivia o TTFB e prioriza a renderização. Mesmo com pouco tráfego, as tarefas funcionam de forma fiável, porque o servidor as executa mesmo que ninguém visite a página. Isso ajuda as atualizações, e-mails ou pings de índice a funcionar pontualmente e evita que os eventos „fiquem parados“ e sejam disparados mais tarde como um pacote. Assim, crio uma previsibilidade. carga do sistema, que não varia de acordo com o humor do tráfego.
Passo a passo: desativar o WP-Cron e configurar o System-Cron
Começo por desativar o gatilho interno no wp-config.php, para que nenhuma chamada de página inicie mais tarefas cron. Para isso, adiciono a seguinte linha e guardo o ficheiro, para que o WordPress não inicie nenhuma verificação cron durante a renderização. Em seguida, configuro uma regra crontab limpa que aciona o wp-cron.php ciclicamente, sem gerar saída desnecessária. Assim, a tarefa é executada de forma temporizada e alivia consistentemente as visualizações de páginas. O resultado: a renderização tem prioridade, as tarefas cron têm a sua própria sincronização.
// wp-config.php define('DISABLE_WP_CRON', true);
# Exemplo de crontab (a cada 5 minutos) */5 * * * * php -q /var/www/html/wp-cron.php > /dev/null 2>&1
WP-CLI em vez de chamada PHP direta
Para um melhor controlo, gosto de definir a execução do cron através de WP-CLI Assim, posso executar apenas eventos „vencidos“, registar-me com mais detalhes e processar multisites de forma direcionada. Além disso, um bloqueio impede que várias execuções sejam iniciadas em paralelo.
# WP-CLI: processar apenas eventos vencidos */5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet
# Com bloqueio simples através de flock (recomendado) */5 * * * * flock -n /tmp/wp-cron.lock /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet
Em ambientes multisite, posso fazer isso através de --url= Percorra o site por site ou faça os sites rodarem através de um pequeno loop shell. Isso evita que 100 subsites atinjam o mesmo ritmo ao mesmo tempo e criem picos de carga.
Intervalos e prioridades: quais tarefas devem ser executadas e quando
Nem todas as tarefas precisam ser realizadas a cada minuto; eu as classifico por relevância e custo, para que as tarefas críticas para SEO tenham prioridade e as tarefas dispendiosas sejam transferidas para horários secundários [1]. O foco está na criação de mapas do site, pings de indexação e aquecimento de cache, seguidos pela manutenção do banco de dados e exclusões transitórias. Planeio as cópias de segurança durante a noite e escolho procedimentos incrementais para evitar picos de I/O. Agrupo as filas de newsletters ou importadores e deixo-os funcionar em intervalos fixos, em vez de os verificar sempre que a página é acedida. Esta organização garante prioridades claras e evita que intervalos de sondagem curtos CPU entupir.
| Tarefa | Intervalo recomendado | Impacto na CPU | Nota |
|---|---|---|---|
| Mapa do site/Pings de indexação | a cada hora até 1 vez por dia | baixo | Relevante para SEO; antes do cache warming priorizar |
| Aquecimento da cache | 1–2 vezes por dia | médio | Classificar URLs, não fazer varreduras completas em horários de pico |
| Cópias de segurança | à noite | elevado | incremental; destino remoto com limite de largura de banda |
| Limpeza da base de dados | diariamente ou semanalmente | médio | Revisões/transientes em blocos excluir |
| Notificações por e-mail | a cada hora/1×/dia | baixo | Formar lotes, utilizar fila |
Mecanismos de execução única e bloqueios limpos
Para que as execuções do Cron não se sobreponham, defino, além de rebanho incluindo as restrições próprias do WordPress. WP_CRON_LOCK_TIMEOUT define por quanto tempo uma execução permanece exclusiva. Se a página estiver lenta ou se houver tarefas demoradas, aumento o valor moderadamente para que nenhum segundo processo seja iniciado prematuramente. Por outro lado, reduzo-o quando as tarefas são curtas e não quero que um travamento provoque uma cascata de erros.
// wp-config.php – Tempo de bloqueio em segundos (padrão 60) define('WP_CRON_LOCK_TIMEOUT', 120);
Além disso, limito conscientemente a paralelidade nos plugins (tamanhos de lote, comprimentos de passo, intervalos entre pedidos). Assim, evito que uma execução cron gere dezenas de processos PHP e aumente a curva de carga.
Monitorização e análise: tornar visíveis os pontos de estrangulamento
Começo pelos registos de acesso e filtro os pedidos POST em wp-cron.php para identificar a frequência e os intervalos de tempo; muitos intervalos curtos indicam intervalos curtos ou eventos bloqueadores. Paralelamente, verifico os registos de erros quanto a tempos limite, bloqueios e tempos de espera da base de dados que afetam as tarefas cron. No backend, o WP Crontrol fornece informações sobre eventos registados, seus hooks e tempos de execução planeados; lá, elimino entradas desatualizadas ou pendentes. Para obter informações mais detalhadas sobre transações, tempos de consulta e filas PHP-FPM, utilizo Ferramentas APM para WordPress para isolar pontos críticos. Assim, encontro as causas, em vez de apenas atenuar os sintomas, e posso agir de forma direcionada. Medidas priorizar.
Objetivos mensuráveis e teste rápido em 10 minutos
Defino valores-alvo claros: TTFB p95 para páginas em cache abaixo de 200–300 ms, para páginas sem cache abaixo de 800 ms; fila PHP-FPM permanentemente próxima de 0; CPU sem picos extremos que levam à saturação. O teste rápido: desativar o WP-Cron, definir o System-Cron, processar eventos vencidos uma vez por WP-CLI e, em seguida, verificar os registos. Em 10 minutos, você verá se o TTFB cai, se a fila PHP diminui e se os hooks chamativos (por exemplo, verificações de atualização, importadores) são os principais responsáveis. Em seguida, ajuste os intervalos, tamanhos de lote e o ritmo até que as curvas fiquem estáveis.
Domine a API Heartbeat e os eventos de plug-ins
O mecanismo Heartbeat atualiza sessões e rascunhos, mas muitas vezes gera solicitações desnecessárias no frontend; eu o restrinjo a áreas administrativas ou defino intervalos adequados. Muitos plugins registram tarefas cron com valores padrão que são muito frequentes; aqui, eu mudo para intervalos mais longos e transfiro tarefas para horários fora do pico. Nas configurações da loja, limito os feeds de inventário e as sincronizações de preços a intervalos fixos, em vez de fazer a verificação a cada minuto. Para feeds e cache warming, utilizo listas em lote, para que nem todos os URLs sejam executados de uma só vez. Essas intervenções reduzem as frequências de solicitação e suavizam o curva claramente.
Escalabilidade: de tarefas cron para filas e trabalhadores
Em caso de tráfego intenso, mantenho o WP-Cron o mais pequeno possível e transfiro tarefas que exigem muito processamento para filas com trabalhadores dedicados. As filas de tarefas distribuem a carga por vários processos, podem ser expandidas horizontalmente e evitam que o frontend tenha de esperar. Em configurações de contentores ou orquestração, escalo os trabalhadores independentemente do PHP-FPM, o que faz com que a renderização e o trabalho em segundo plano recebam recursos separados. As filas são especialmente úteis para importações, processamento de imagens, lotes de newsletters e sincronizações de API. Assim, o frontend permanece responsivo, enquanto as tarefas em segundo plano são controladas e planeável correr.
WooCommerce, Action Scheduler e grandes filas
O WooCommerce traz com o Programador de acções uma fila própria que processa e-mails de encomendas, webhooks, assinaturas e sincronizações. É precisamente aqui que surgem picos de CPU, quando milhares de ações estão „pendentes“. Não deixo o Runner a funcionar quando a página é acedida, mas sim o aciono através do System Cron ou WP-CLI em janelas fixas. Defino os tamanhos dos lotes e a paralelidade de forma que uma execução não bloqueie a base de dados e os PHP-FPM-Worker permaneçam livres. Distribuo importadores, regeneração de imagens e picos de webhooks em várias pequenas execuções – prefiro 10× curtas do que 1× durante horas com bloqueios de I/O.
Especificações multisite: equilibrar o clock por site
Em configurações multisite, a carga aumenta porque cada site tem a sua própria lista de eventos. Em vez de verificar tudo a cada cinco minutos, eu faço uma rotação dos sites: grupos de sites com intervalos ligeiramente desfasados, para que nem todas as listas cron sejam executadas ao mesmo tempo. Para sites muito ativos, a fila recebe um slot com mais frequência, enquanto sites menos ativos recebem com menos frequência. O resultado é uma curva de CPU mais uniforme e menos concorrência por trabalhadores – com o mesmo trabalho total.
Verificação prática: configuração sem obstáculos
Primeiro, verifico se DISABLE_WP_CRON está definido corretamente, pois gatilhos duplos (internos + externos) aumentam os picos de carga. Em seguida, verifico o Crontab: caminho correto, sem saída desnecessária, intervalo adequado e sem sobreposições com janelas de backup. No WP Crontrol, limpo hooks desatualizados e altero intervalos curtos para ciclos realistas. Adapto as configurações do PHP-FPM ao perfil dos visitantes, para que os PHP-Workers não fiquem constantemente no limite superior. Por fim, monitorizo o TTFB, os tempos de resposta e a CPU, para avaliar claramente o efeito das alterações. Taxa.
Dimensionar adequadamente PHP-FPM, OPCache e limites de tempo
A melhor estratégia Cron é inútil se o PHP-FPM for muito pequeno ou estiver mal sincronizado. Eu escolho pm=dinâmico ou pm=sob demanda dependendo do perfil de tráfego e encaminhe pm.max_children do orçamento real de RAM: como regra geral, RAM_para_PHP / consumo médio de script. Exemplo: um orçamento de 2 GB e ~128 MB por processo resultam em ~16 trabalhadores. pm.max_requests Eu defino um valor moderado (500–1000) para limitar as fugas. request_terminate_timeout limita os trabalhos excecionais; um registo lento deteta loops de consulta e tempos de espera externos. Um OPCache saudável (suficiente max_accelerated_files, consumo de memória, buffer_de_strings_internas) evita arranques a frio e poupa CPU por pedido – também para execuções cron.
Cache de objetos e higiene de opções
Um cache de objetos persistente (por exemplo, Redis/Memcached) reduz significativamente a pressão sobre o banco de dados para verificações cron. É importante que Higiene no wp_options-Tabela: A opção cron não deve ultrapassar vários megabytes, caso contrário, cada verificação ficará cara. Removo eventos desatualizados ou pendentes, reduzo o lixo do autoload e coloco em espera opções grandes e raramente utilizadas. autoload = não. Assim, os tempos de consulta diminuem e as listas cron podem ser avaliadas mais rapidamente.
Ajustes finos: ritmo, sequência e limites de recursos
Para sites com picos pela manhã, eu programo o aquecimento do cache para o início da noite e executo mapas do site pouco antes do horário comercial, para que os rastreadores vejam dados atualizados. Divido limpezas caras de bancos de dados em blocos menores para reduzir os tempos de bloqueio e evitar picos de consultas. Defino grandes exportações para janelas de fim de semana, quando há menos interação. Quando faz sentido, limito tarefas paralelas para que vários processos cron-php não disputem I/O ao mesmo tempo. Esse ajuste fino garante um rendimento uniforme e melhor Tempos de resposta.
Segurança: proteger o wp-cron.php contra acessos externos
Como o Cron deve ser acionado internamente, bloqueio o acesso externo direto a /wp-cron.php. Assim, evita abusos, DDoS e chamadas acidentais de terceiros. Permita apenas chamadas locais (loopback ou CLI) e bloqueie todas as outras. Isso reduz o ruído nos registos e protege os PHP-Workers.
# Exemplo Nginx location = /wp-cron.php { allow 127.0.0.1; deny all; include fastcgi_params; fastcgi_pass php-fpm; }
# Exemplo Apache Require ip 127.0.0.1
Causas frequentes de carga „fantasma“ devido ao Cron
Intervalos muito curtos (1–5 minutos) para tarefas não críticas estão entre os maiores impulsionadores de carga, especialmente em combinação com muitos plugins. Eventos pendentes, que são replanejados repetidamente devido a execuções com falha, geram loops que inundam os logs. Problemas de bloqueio na base de dados forçam as tarefas cron a terem tempos de execução mais longos, o que aumenta as sobreposições. Além disso, bloqueios HTTP (por exemplo, DNS ou API remota) podem prolongar artificialmente as execuções cron e ocupar os trabalhadores. Quem conhece esses padrões economiza muito tempo na busca pela causa e reduz o Picos rápido.
Brevemente resumido
A carga irregular da CPU no WordPress tem frequentemente origem no WP-Cron, que atua como um gatilho nas visualizações de páginas e vincula o PHP Worker. Desativo o gatilho interno, defino um cron do sistema, otimizo intervalos e priorizo tarefas relevantes para SEO, para que a renderização tenha prioridade. A monitorização com logs, WP Crontrol e análises APM mostra-me eventos com erros, ciclos curtos e processos bloqueadores. Para projetos grandes, transfiro trabalhos com uso intensivo de computação para filas, a fim de separar claramente as tarefas de front-end e de fundo. Isso leva a uma carga uniforme, TTFB mais curto e uma melhoria notável. mais rápido Entrega – sem picos inesperados.
