Saltar para o conteúdo 
Serviços cronológicos do WordPress falham sob carga quando os pedidos de página bloqueiam o agendador interno, as caches interceptam os pedidos ou os limites de alojamento limitam as tarefas longas. Mostro as causas, as consequências e as soluções concretas para garantir que tarefas como actualizações, cópias de segurança e publicações agendadas são executadas de forma fiável.
Pontos centrais
Para começar, vou resumir os aspectos mais importantes de forma breve e clara antes de entrar em mais pormenores e explicar passos específicos que utilizo de forma produtiva. Identificação do problema e Causas são o foco aqui.
- MecânicaO WP-Cron é acionado nos pedidos de página em vez de ser acionado através do cron do sistema.
- CargaO tráfego elevado e o „wordpress cron load“ geram timeouts.
- Armazenamento em cacheO armazenamento em cache CDN completo interrompe a execução do cron.
- LimitesOs tempos limite do PHP e os orçamentos de recursos cancelam tarefas.
- soluçãoCalendário do servidor, intervalos de limpeza, registo e afinação.
WP-Cron brevemente explicado: Chamada de página em vez de serviço de sistema
Começo com o Ideia de baseO WordPress verifica se as tarefas agendadas são devidas com cada pedido de página e dispara-as através de um pedido HTTP interno para wp-cron.php. Essa abordagem compensa a falta de acesso aos crones reais do servidor, mas cria uma dependência do Tráfego. Se uma página quase não chega a nenhum visitante, as tarefas são executadas com atraso ou não são executadas de todo. Se um CDN servir todos os pedidos a partir da cache, o PHP não carrega e o WP-Cron permanece silencioso. Isto explica porque é que as publicações agendadas, as tarefas de correio eletrónico ou as cópias de segurança parecem pouco fiáveis em algumas instalações. Quanto mais plugins registarem tarefas adicionais, mais densa se torna a fila de espera e mais vulnerável se torna a execução.
Porque é que o Last Cronjobs está a cair
Se o fluxo de visitantes aumentar, o mesmo acontece com as verificações cron e, por conseguinte, com o Carga do servidor. Mais pedidos simultâneos competem por PHP workers, E/S e base de dados, fazendo com que as chamadas cron entrem em timeouts. As latências acumulam-se, as tarefas bloqueiam-se umas às outras e as tarefas longas saem da janela de tempo. Eu sempre trato disso em configurações produtivas, como WP-Cron em sítios de produção é frequentemente o gatilho para tempos de resposta lentos. Sob carga elevada, os abrandamentos estão diretamente relacionados com os accionadores cron utilizados em excesso. Para além disso, as tarefas mal escritas agravam a situação porque iniciam pesquisas na base de dados que consomem ainda mais recursos.
Limites de alojamento e suas consequências
Muitos hosters utilizam um Tempo limite do PHP de 30-60 segundos; se uma tarefa exceder esta marca, o sistema termina-a de imediato. Isto afecta trabalhos de migração, grandes exportações, processamento de imagens ou e-mails em massa. Memory_limit, limites de processo e limites de taxa para loopbacks HTTP têm um efeito semelhante. Se o tráfego também for baixo, os eventos devidos acumulam-se e são executados com atraso ou não são executados de todo. Por isso, primeiro verifico os limites e os registos antes de ajustar a aplicação. Isto permite-me reconhecer se o ambiente está a causar estrangulamentos ou se as tarefas individuais são ineficientes.
Verificação rápida: causas, sintomas, soluções
A visão geral que se segue ajuda-me a separar os padrões de erro de uma forma estruturada e a atuar com um objetivo em vez de experimentar ao acaso. Cada linha mostra um Causa, a visível Sintoma e uma medida imediata.
| Causa | Sintoma típico | medida imediata |
|---|---|---|
| CDN/Reversed Proxy serve 100% a partir da cache | As contribuições planeadas aparecem com atraso | Desacoplar o WP-Cron, definir o cron do servidor real |
| Tempo limite do PHP (30-60 s) | Cópias de segurança/exportações canceladas | Aumentar o tempo de espera, dividir a tarefa em lotes mais pequenos |
| Demasiados eventos cron | Latência percetível com picos de tráfego | Alongar os intervalos, eliminar eventos desnecessários |
| Consultas SQL ineficientes | A utilização da base de dados aumenta a passos largos | Definir índices, reduzir SELECTs, guardar em cache |
| Sítio Web com pouco tráfego | Horas de atraso | Executar o cron do sistema a cada 15-60 minutos |
Complemento a verificação com métricas reais dos registos e da monitorização para verificar os pressupostos e analisar o Causa claramente. A tabela não substitui uma medição, canaliza-a. Só quando sei se o timeout, a cache ou a base de dados estão a limitar é que tomo as medidas adequadas. De seguida, testo repetidamente e verifico se existem efeitos subsequentes. Desta forma, minimizo o esforço e resolvo o problema de forma sustentável.
Melhores práticas: Do WP-Cron para o Server-Cron
Primeiro desactivei o acionador baseado na página com DESACTIVAR_WP_CRON em wp-config.php: define(‚DISABLE_WP_CRON‘, true);. Em seguida, configurei um cron de sistema real que chama wp-cron.php ciclicamente (por exemplo, via curl a cada 5 minutos para tráfego alto, de hora em hora para tráfego baixo). Isto permite-me dissociar as execuções do fluxo de visitantes e suavizar o Carga. Ao mesmo tempo, limito as chamadas simultâneas para que não ocorram tempestades cron. Se prevejo picos, aumento os PHP workers e ajusto os tempos limite. Especialmente com tráfego flutuante, eu reduzo Carga irregular da CPU e evitar reacções em cadeia.
Intervalos, conceção de tarefas e base de dados
Verifico se cada evento tem o seu Intervalo e alargar as frequências sempre que tal se justifique. Em vez de a cada minuto, faço análises de hora a hora ou diariamente se a tarefa não precisar de valor em tempo real. Divido tarefas longas em pequenos lotes que são executados em segurança dentro do tempo limite do PHP. Quando acedo a bases de dados, defino índices, reduzo as colunas e evito verificações completas. Coloco dados frequentes em cache para intercetar repetições e minimizar o Base de dados de trabalho desnecessário. Isto reduz os tempos de execução e as execuções cron permanecem calculáveis.
O diagnóstico na prática: criar visibilidade
Antes de reconstruir, quero ter uma Dados de diagnóstico. Começo com a apresentação do estado do sítio WordPress e ativo o registo (WP_DEBUG_LOG) para tornar visíveis os erros de PHP durante as chamadas cron. Em seguida, listo os eventos devidos e agendados e os respectivos tempos de execução. Em fluxos de trabalho produtivos, utilizo passos repetíveis para este efeito:
- Ativar eventos de vencimento através do WP-CLI: wp cron event run -due-now
- Lista de eventos agendados: lista de eventos wp cron
- Defina os seus próprios pontos de medição: Registar a hora de início/fim da tarefa, incluindo a memória de pico
- Verificar a página da base de dados: Identificar SELECTs longos e adicionar os índices necessários
Se o Site Health mostrar „Delayed cron execution“, analiso os registos de acesso em wp-cron.php, os códigos de resposta e a duração. 429/503 indicam limites de taxa ou de recursos, 401/403 indicam bloqueio por autenticação, firewall ou WAF. Verifico se os pedidos de loopback são permitidos internamente e se o nome do anfitrião é resolvido corretamente. Também olho para a opção „cron“ de wp_options para avaliar o tamanho e a idade da fila e identificar ganchos de função que falham repetidamente.
Configuração robusta do servidor cron: HTTP, WP-CLI e bloqueio
Para ambientes produtivos, prefiro um Calendário do servidor via WP-CLI em vez de uma chamada HTTP pura, porque inicio o PHP diretamente e dependo menos do servidor/proxy Web. Variantes exemplares que deram provas:
- Variável HTTP, com orçamento de tempo e paragem: curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI diretamente: cd /path/to/installation && /usr/bin/wp cron event run -due-now -quiet
- Evitar sobreposições: flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“
- Aumentar os recursos especificamente: php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Utilizo o flock para evitar arranques paralelos, que de outra forma levariam a execuções duplicadas e acessos concorrentes à base de dados. Com várias instâncias (por exemplo, Blue/Green, Container), só permito que um host execute o cron e desativo-o nos outros. Desta forma, evito condições de corrida na fila de espera.
Loopbacks, auth e firewalls: bloqueios típicos
Se os cronjobs ficarem pendentes, o cronjob interno é frequentemente bloqueado. Loopback. Verifico se o Basic-Auth, as restrições de IP ou um WAF impedem os pedidos para wp-cron.php. Em configurações de preparação seguras, excluo o wp-cron.php da autenticação ou permito loopbacks como uma exceção. Se as chamadas HTTP externas forem restringidas, certifico-me de que o meu próprio domínio não está na lista de bloqueio. O ALTERNATE_WP_CRON pode ajudar a curto prazo, mas só o utilizo temporariamente e volto a removê-lo assim que um cron de servidor limpo estiver ativo.
Sobreposições e idempotência: tornar as tarefas seguras
Muitos problemas surgem devido a Execuções simultâneas da mesma tarefa. Por isso, instalo bloqueios de tarefas (por exemplo, através de transientes/opções), verifico se uma execução já está ativa antes de começar e termino a segunda chamada mais cedo. Ao mesmo tempo, faço com que as tarefas sejam idempotentes: se um passo for iniciado duas vezes, isso não leva à duplicação de e-mails, ficheiros ou entradas na BD. Para tarefas em lote, guardo desvios/marcadores para controlar as continuações de forma limpa e intercetar repetições. Isto reduz os danos consequentes se uma execução cron parar inesperadamente e for reiniciada mais tarde.
Escalonamento: multiserver, contentor e multisite
Em ambientes distribuídos, eu opero exatamente um Cron runner. Este pode ser um contentor de trabalho separado ou um nó fixo que desencadeia todos os eventos devidos através do WP-CLI. Os sistemas de ficheiros partilhados ou caches distribuídos ajudam a manter os estados e bloqueios consistentes entre instâncias. Em configurações multi-site, verifico se o Cron está corretamente agendado para cada rede de sub-site e se os eventos de rede não estão a inundar a fila global de forma descontrolada. Também me certifico de que os fusos horários por site estão corretos para que as publicações e as janelas de tempo estejam corretas.
Horários e fusos horários: evitar „Falhas de horário“
Um fator subestimado são Fusos horários e a mudança da hora de verão. O WordPress programa as publicações no fuso horário do sítio, enquanto os servidores funcionam frequentemente em UTC. Sincronizo ambos, verifico as definições de fuso horário para as implementações e tenho em conta as alterações horárias no plano editorial. Se ocorrer um „Missed schedule“, verifico se a fila do cron está sobrecarregada, se os ganchos de publicação estão a falhar ou se a hora do servidor está a variar. Um subsequente „wp cron event run -due-now“ descarrega a fila enquanto eu corrijo a causa real (cache, timeout, fuso horário incorreto).
Desenvolvimento, preparação e implementações
Em ambientes de teste, desativo tarefas produtivas (e-mails, exportações, webhooks) para que nenhuma ação não intencional seja acionada. Defino DISABLE_WP_CRON como verdadeiro e executo o meu próprio cron de teste com intervalos longos. Antes do go-live, esvazio a fila, executo as tarefas críticas uma vez manualmente e monitorizo os registos de perto. Após as implementações, uma execução „due-now“ direcionada aciona os novos hooks antes que os caches se tornem agressivos novamente. Isto evita surpresas e mantém a fase de introdução tranquila.
Tratamento de erros, backoff e repetições
Os fracassos acontecem. Eu planeio-os Novas tentativas com backoff: tentar novamente apenas após um curto período de tempo, depois com uma distância crescente. Documentei os passos falhados com códigos e contexto claros (entrada, duração, memória, SQL, código HTTP). Após N tentativas falhadas, marco o evento como „bloqueado“ e informo-me através de um alerta. Esta separação evita ciclos intermináveis e dá-me tempo para retificar a causa real sem entupir a fila de espera.
Ferramentas: WP Crontrol e Action Scheduler
Para o diário Controlo Utilizo o WP Crontrol para ver, pausar ou reprogramar eventos diretamente no WordPress. Utilizo-o para reconhecer ganchos suspensos, entradas duplicadas ou intervalos incorrectos. Para processos grandes, utilizo o Action Scheduler, que divide as tarefas em pequenas acções e as regista de forma limpa. Se uma ação falhar, reinicio-a de forma orientada sem pôr em risco toda a cadeia. Isto minimiza os picos, porque não estou a fazer um monólito, mas sim Subtarefas taticamente. Isto mantém as implementações e as janelas de manutenção previsíveis.
Alojamento partilhado, armazenamento em cache e CDNs
Em ambientes partilhados, as chamadas cron colidem rapidamente com Limites, que eu não controlo diretamente. Se a CDN e a cache de página inteira tiverem efeito, nem um único pedido de página ativa o WP-Cron. Eu contorno isso com um cron do sistema e certifico-me de que os pedidos de loopback estão acessíveis. Quando o cron não dispara de forma fiável, verifico as políticas de rede, a autenticação básica e as firewalls. Um teste com uma chamada direta ao curl mostra se os pedidos estão a chegar tecnicamente. Para informações básicas e alternativas, consulte Tarefas cron em alojamento partilhado, porque os obstáculos típicos são aí descritos de forma compacta.
Monitorização e manutenção na vida quotidiana
Eu guardo o Site-SaúdeIsto deve-se ao facto de o WordPress reportar visivelmente as execuções cron atrasadas. Também escrevo registos para analisar estatisticamente a duração, os erros e as repetições. Isto revela anomalias que, de outra forma, passariam despercebidas no dia a dia. Elimino ou reponho eventos desactualizados ou que falham permanentemente para manter a fila de espera reduzida. Os alertas por correio eletrónico ou Slack informam-me se um trabalho falhar várias vezes. Isto permite-me intervir antes que consequências como actualizações perdidas ou e-mails não enviados causem danos.
Conclusão: A minha abordagem em resumo
Primeiro, separo o Cron das chamadas de página, defino um Calendário do servidor e verifico a acessibilidade através do curl. Em seguida, optimizo os intervalos, divido as tarefas longas em lotes e reduzo a carga da base de dados. Configuro o registo, olho para os caminhos de erro e ajusto os limites para que nenhuma tarefa falhe no tempo limite. Se necessário, utilizo o Action Scheduler porque divide de forma fiável os processos longos em partes controláveis. Depois, meço o efeito e simplifico a lista cron até que a fila permaneça limpa. Desta forma, as tarefas agendadas correm de forma fiável, mesmo que o Carga Os aumentos ou as caches funcionam de forma agressiva.
