Passer au contenu 
Intervalles des tâches planifiées contrôlent directement la puissance de travail du CPU, de la RAM et des E/S, ainsi que la répartition uniforme de la charge tout au long de la journée. Ne définissez pas d'intervalles trop courts, sinon les exécutions parallèles augmenteront, des chevauchements apparaîtront et la Charge du serveur s'intensifie.
Points centraux
Je résume brièvement les principaux leviers et les classe de manière pratique dans la suite du texte.
- Fréquence Détermine le nombre d'exécutions et les exécutions parallèles
- timing lisse les pics de charge pendant les périodes creuses
- Optimisation des scripts réduit les besoins en ressources
- Suivi détecte les goulots d'étranglement et la gigue
- Alternatives Comment soulager les files d'attente ou le cron externe
Je classe les tâches par ordre de priorité en fonction de leur impact sur les utilisateurs et j'espace les tâches difficiles. Ensuite, je répartis les démarrages sur toute l'heure afin de ne pas tout concentrer à la minute 0 et ainsi collisions à éviter. Je mesure les durées d'exécution sur le serveur, et non localement, afin que la limitation du CPU soit visible. Si des pics persistent, je fixe des limites et déplace les tâches vers des plages horaires plus calmes. Cela me permet d'assurer la continuité dans le Version et garde des réserves disponibles.
Comment des intervalles courts génèrent des pics de charge
Si je lance souvent une tâche, la nombre d'exécutions linéaire, tandis que les E/S et le CPU ne se rétablissent pas de manière linéaire. Si une tâche dure 3 minutes et démarre toutes les 5 minutes, il ne reste que 2 minutes de marge – de petits retards entraînent immédiatement des chevauchements. Si plusieurs tâches cron se rencontrent, elles entrent en concurrence pour temps CPU, La file d'attente d'E/S s'allonge et les temps de réponse augmentent. Dans les environnements partagés, des limites de durée d'exécution et de processus s'ajoutent à cela, ce qui allonge encore la file d'attente. Il en résulte une réaction en chaîne : plus de temps d'attente, plus de processus parallèles, plus de Dernier.
Je calcule au préalable un parallélisme approximatif : la durée d'exécution divisée par l'intervalle donne le chevauchement attendu. Si la valeur est supérieure à 0,7, je prévois plus large ou je déplace vers les heures creuses. Le surcoût de démarrage d'un appel Cron est déjà perceptible lorsqu'il se produit plusieurs dizaines de fois par heure. Pour les tâches gourmandes en données, le Comportement du cache: les caches froids lors d'exécutions fréquentes augmentent les E/S, car le noyau conserve rarement les mêmes pages chaudes. C'est pourquoi je préfère des exécutions moins fréquentes, mais plus efficaces.
Choisir judicieusement les classes de fréquence
Pour une proximité en temps réel, je n'utilise un intervalle de 1 à 5 minutes que lorsque la tâche est facile et que j'ai besoin de temps de réponse courts. La maintenance, le nettoyage et les rapports s'effectuent chez moi selon un intervalle de 15 à 60 minutes, ce qui réduit les exécutions à un nombre raisonnable de 24 à 96 par jour et maintient la Taux d'occupation plus régulière. Je crée des sauvegardes, une rotation des journaux ou des piles d'images toutes les heures ou tous les jours, car la quantité de données est importante et la compression lie les E/S. Il est important que les tâches légères ne partagent pas la minute 0 : je répartis les démarrages sur 5, 17, 29, 41, afin que Cluster éviter. De plus, je crée une fenêtre distincte pour les processus très longs afin qu'ils n'empiètent pas sur les pics d'activité de la boutique.
Pour les boutiques, les API et les CMS, j'utilise une combinaison : synchronisation modérée de l'inventaire et préchauffage modéré du cache, indexation intensive la nuit. Cela réduit les saccades lors du trafic en direct et protège Transactions. Lorsque j'augmente les fréquences, je vérifie d'abord la durée d'exécution des tâches, sinon je ne fais que multiplier la charge. Pour les tâches courtes, je vérifie si les déclencheurs d'événements sont adaptés, par exemple les webhooks plutôt que les cron rigides. Cela permet de garder un cadencement léger et ciblé.
Comparaison des environnements d'hébergement
Dans les environnements partagés, les limites ont un impact immédiat Jitter par : intervalle à partir de 15 minutes, durées d'exécution courtes, processus limités. Je prévois des intervalles plus longs, sinon les threads s'attendent les uns les autres et les exécutions cron sont retardées. Sur un VPS ou mon propre serveur, je peux définir des heures de démarrage à la seconde près, une CPU/RAM dédiée et des priorités équitables. J'utilise ensuite des cgroups, nice/ionice et des files d'attente séparées afin que important Les tâches deviennent prioritaires. Les services Cron externes sont utiles lorsque le serveur d'applications doit faire face à des pics de charge.
| Type d'hébergement | Intervalles typiques | Ressources | limites de durée | Suivi |
|---|---|---|---|---|
| hébergement partagé | à partir de 15 minutes | divisé | court (par exemple 300 s) | limité |
| VPS | possible à chaque seconde | dédié | configurable | entièrement |
| Cron externe | à chaque minute | indépendant | pas de | avec alertes |
Je décide en fonction des besoins : si j'ai besoin de plages horaires strictes et d'un contrôle, j'utilise VPS ou Cron externe. Si je souhaite réduire les coûts, je privilégie les tâches partagées. mince et généreusement cadencé. Pour les scénarios mixtes, je combine les deux mondes : déclenchement externe, traitement interne en blocs modérés. Cela me permet de découpler proprement le trafic utilisateur et les traitements par lots. Le choix de la configuration influe directement sur la Planification des intervalles.
Dissocier WP-Cron et le déclencher correctement
WP-Cron s'accroche aux consultations de pages, vérifie les tâches en retard à chaque consultation et génère des Pointes. Je désactive le déclencheur interne avec define('DISABLE_WP_CRON', true) ; et j'appelle wp-cron.php via un vrai Cron toutes les 15 minutes. Ainsi, les tâches s'exécutent à intervalles réguliers, indépendamment du nombre de visiteurs, et la charge est répartie de manière plus équilibrée. Pour les sites très actifs, je règle l'intervalle sur 5 à 10 minutes, pour les sites plus petits, sur 15 à 30 minutes, en tenant toujours compte des durées d'exécution. Je vous explique ici les raisons de la charge CPU inégale due à WP-Cron : Charge CPU due à WP-Cron.
Pour les exécutions parallèles, j'utilise des fichiers de verrouillage : flock empêche le démarrage d'une nouvelle exécution tant que l'ancienne est encore en cours. Cela protège contre chevauchements, en particulier pour les importations et les index. De plus, je limite PHP avec memory_limit et max_execution_time, afin que les éléments détachés ne se coincent pas. Avec ionice Je réduis la priorité E/S des opérations de copie volumineuses afin que les requêtes frontales restent rapides. Ces petits réglages ont un effet plus important que la simple modification de l'intervalle, car ils Conflits minimiser.
Idempotence et répétabilité
Je conçois les tâches cron de manière idempotente afin que les répétitions ne causent aucun dommage. Je marque les tâches d'écriture avec Clés d'idempotence ou des contraintes claires (par exemple, sur la base d'un identifiant source) afin que les exécutions doubles ne créent pas de doublons. Les processus plus longs sont points de contrôle: un point de persistance par lot (par exemple, dernier ID/date traité) afin que les redémarrages puissent reprendre à partir de là et ne pas recommencer depuis le début. Pour les pipelines à plusieurs niveaux, j'utilise mesures compensatoires (par exemple, les écritures de réversion) lorsqu'une étape ultérieure échoue. Ainsi, les réessais restent sûrs et je n'ai pas besoin d'augmenter artificiellement les intervalles uniquement pour éviter les erreurs.
Fuseaux horaires, NTP et changement d'heure
Je pense toujours à Cron dans UTC, pour éviter les décalages dus au passage à l'heure d'été/d'hiver. Si la planification doit être effectuée en fonction de l'heure locale, je documente le fait que l'heure du changement est exécutée deux fois ou pas du tout. Je synchronise l'horloge système avec NTP/chrony. Sinon, le décalage horaire entre les hôtes entraîne un parallélisme indésirable, des fenêtres manquées ou des violations de la limite de débit pour les API externes. Dans les configurations globales, je crée des créneaux horaires distincts pour chaque région et je planifie des créneaux horaires opposés afin que Peaks Ne pas additionner.
Cron, systemd-timers et anacron
Outre le cron classique, j'utilise systemd-timers lorsque j'ai besoin d'un contrôle plus fin. Les avantages sont les suivants RandomizedDelaySec (gigue sans veille propre), AccuracySec (fenêtre de démarrage) et Persistant=vrai (Rattraper les courses manquées). Pour les ordinateurs portables ou les serveurs qui fonctionnent rarement, il est utile d'utiliser anacron, afin que les tâches quotidiennes soient rattrapées en toute sécurité malgré les temps d'arrêt. Je repousse les tâches ponctuelles avec at, au lieu de les laisser dans Cron.
Un exemple minimal avec des limites de ressources et du verrouillage :
[Unit] Description=Tâche de maintenance [Service] Type=oneshot ExecStart=/usr/bin/flock -n /var/lock/maint.lock /usr/bin/nice -n 10 /usr/bin/ionice -c2 -n7 /usr/local/bin/maint.sh
MemoryMax=512M CPUWeight=20 IOSchedulingClass=best-effort IOSchedulingPriority=7 [Install] WantedBy=multi-user.target
[Unit] Description=Minuterie de maintenance [Timer] OnCalendar=*:07,37 RandomizedDelaySec=30 Persistent=true AccuracySec=1min [Install] WantedBy=timers.target
Gigue, limites de débit et utilisation équitable
Je répartis délibérément les départs avec Jitter, pour éviter les effets de troupeau tonitruants. Dans le Cron classique, un court sommeil $((RANDOM)) l'égalisation, sous systemd, j'utilise RandomizedDelaySec. Si les tâches accèdent à des API externes, je respecte Cotes et intégrez une limitation du débit côté client. Ainsi, les exécutions restent constantes au lieu de générer des tempêtes de tentatives en cas d'erreur, qui dépassent à nouveau les limites.
Gestion des erreurs, délais d'attente et backoff
Chaque tâche est clairement définie. Timeouts et des codes de sortie propres. J'assigne des retry à Backoff exponentiel et une limite supérieure, plus une logique Dead Letter pour les cas persistants. Je protège les chemins critiques avec Casseurs de circuit: Si plusieurs appels consécutifs échouent, je fais une pause au lieu de continuer à courir de manière agressive. Dans les journaux, je note la cause, les personnes concernées et la prochaine action à entreprendre, et pas seulement “ failed ” (échec). Cela réduit les vols à l'aveugle et m'empêche d'allonger trop les intervalles par manque de certitude.
Hygiène de configuration et sécurité
J'écris des crontabs explicitement: chemins absolus, définis PATH-, LONG- et UMASKVariables, uniques MAILTO ou des cibles de journalisation. Les tâches s'exécutent sous least privilege avec vos propres utilisateurs Unix plutôt qu'en tant que root. Je conserve les données d'accès hors du crontab et les charge à partir de .envou le magasin secret. Je limite les droits d'accès aux fichiers et au réseau à l'aide d'un pare-feu et d'ulimit afin d'éviter que des erreurs de configuration n'ouvrent le système. Une brève section d'en-tête crontab permet d'éviter les surprises :
SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LANG=C.UTF-8 UMASK=027 [email protected]
Mise à l'échelle sur plusieurs hôtes
Dans les clusters, je veille à ce que seuls a Exécute des tâches singleton hôte. Je résous cela avec une base de données.Verrous consultatifs, le verrouillage distribué (par exemple via Redis) ou l'épinglage d'hôte. Je peux également choisir une procédure d'élection de leader et ne laisser démarrer que le leader. Pour la mise à l'échelle horizontale, je divise le travail en petites unités idempotentes que les travailleurs récupèrent en parallèle. Cela me permet d'augmenter la capacité de manière précise sans modifier la fréquence cron.
Exemples pratiques
Une entrée Cron classique simplifiée avec journalisation, verrouillage et priorisation :
7,37 * * * * flock -n /var/lock/report.lock nice -n 10 ionice -c2 -n7 /usr/local/bin/build_report.sh >> /var/log/cron/build_report.log 2>&1
Pour les tâches susceptibles d'interférer entre elles, je définis des fenêtres et utilise des gardes simples :
MINUTE=$(date +%M) if [[ " $MINUTE " -ge 0 && " $MINUTE " -le 10 ]]; then exit 0 # pas de démarrage dans la fenêtre de sauvegarde fi
Et si un processus ne doit démarrer que lorsque le backlog est vide, je vérifie d'abord la taille de la file d'attente, puis je décide si cela vaut la peine de le lancer. J'évite ainsi les démarrages “ à vide ” qui ne font que générer des frais généraux.
Efficacité énergétique et rentabilité
Je prends en compte les coûts : la compression consomme du CPU, mais économise de l'espace de stockage et de la bande passante ; un zstdLe niveau peut être plus avantageux que le niveau maximal. gzip-Pression. Je synchronise les exportations importantes avant les périodes favorables. Hors pointe-Tarifs afin de réduire les coûts liés à l'électricité ou au cloud. Je regroupe les tâches gourmandes en sortie afin de mieux planifier les quotas. En associant la capacité et les intervalles aux coûts, on évite à la fois le sous-approvisionnement et le surapprovisionnement.
Tester, évaluer et revenir en arrière
Je traite les modifications apportées à Cron comme du code : je les teste localement avec les volumes de données cibles, puis je les déploie dans marches (un hôte, puis plusieurs), je marque les fenêtres de démarrage dans les métriques et je surveille les taux d'erreur. Si l'effet ne me convient pas (plus de chevauchement, latence plus élevée), je reviens en arrière. Un petit Runbook aide l'équipe : que faire en cas de retard, comment résoudre les fichiers verrous, quand faire une pause ou établir des priorités ? Ainsi, les intervalles restent stables, même si le système change.
Files d'attente et cron externe pour alléger la charge
Si une tâche nécessite plus de travail qu'une seule exécution, je déplace les tâches vers une Queue et laisse les workers fonctionner en continu. Cela permet de mieux répartir le temps de calcul, et je n'utilise plus la fréquence cron que pour le démarrage ou le contrôle de santé. Les files d'attente Redis ou Database avec logique de réessai, limites de débit et gestion des lettres mortes empêchent les embouteillages. Un service Cron externe peut déclencher des URL de manière fiable, même lorsque le serveur d'application est saturé. Vous trouverez ici un bref aperçu pratique : Tâches PHP asynchrones.
Je dimensionne les travailleurs selon le SLA, et non selon mon intuition : je préfère un parallélisme constant et faible à de brèves exceptions. En cas de débordement, j'augmente temporairement le nombre de travailleurs, puis je le réduis à nouveau. J'applique un backoff aux retry afin que les vagues d'erreurs ne bloquent pas tout. J'assure la visibilité à l'aide de métriques par file d'attente, telles que le débit, le temps d'attente et Taux d'erreur. Cela me permet de garder le contrôle sans avoir à réduire artificiellement les intervalles Cron.
Hébergement mutualisé : obstacles typiques
Dans les environnements partagés, la limitation du CPU ralentit souvent les exécutions cron de manière imprévisible, et les intervalles courts aggravent ce phénomène. Je passe alors à des intervalles plus longs et vérifie si un cron externe peut se déclencher de manière fiable. Pour plus d'informations, je recommande cet aperçu des contextes et des alternatives : Tâches cron dans l'hébergement mutualisé. De plus, je divise les tâches difficiles en petites parties et je les planifie en dehors des heures de pointe. Si vous atteignez régulièrement vos limites, il est généralement plus avantageux d'utiliser un petit VPS plutôt que de perdre du temps à cause des restrictions.
J'évite d'utiliser le cron basé sur le Web dans le backend WordPress lorsque la plateforme a peu de trafic. Sinon, les tâches s'accumulent et démarrent plus tard de manière groupée. Un déclencheur externe clair ou un vrai cron résout ce problème. À cela s'ajoute le verrouillage, afin d'éviter les doubles démarrages. Ainsi, les temps de réponse pour Visiteurs fiable.
Surveillance et valeurs mesurées : ce que je regarde
Je mesure le CPU, la charge, l'attente E/S et la RAM, ainsi que les durées d'exécution par tâche et le arriéré au cours de la journée. Une carte thermique des heures de démarrage montre où les exécutions Cron s'accumulent. Pour les applications, je vérifie simultanément les latences, les taux d'erreur et les Core Web Vitals. Si des pics coïncident avec les exécutions Cron, je marque les plages horaires. Ensuite, j'ajuste les intervalles, je définis des priorités et je vérifie si le verrouillage fonctionne correctement. saisit.
Dans les journaux, j'affiche les codes de sortie, la durée, les tables ou les chemins concernés. Chaque tâche se voit attribuer une durée maximale et une gestion claire des erreurs. Si une exécution échoue, une alarme est déclenchée au lieu d'une répétition silencieuse. Pour les sauvegardes, j'enregistre la taille, le débit et la compression afin de mieux évaluer les E/S. Ce retour d'information rend la Planification beaucoup plus précis lors des nouvelles courses.
Penser en termes de capacité : petite formule, grand effet
J'estime la charge à l'aide d'un calcul simple : parallélisme attendu ≈ durée en minutes divisée par intervalle. Si la valeur est supérieure à 1, je prévois des chevauchements et j'agis en conséquence. J'allonge alors les intervalles, je raccourcis les Durée de validité ou déplacez le travail dans des files d'attente. Au niveau du stockage, je tiens compte des IOPS et du débit, car ce sont souvent eux qui fixent les véritables limites. Avec cette approche, je m'appuie moins sur mon intuition et davantage sur Données.
La formule est encore plus utile avec une marge d'erreur : je calcule 20 à 30 % supplémentaires pour amortir les fluctuations et les pics. Je prévois des plans alternatifs pour les effets saisonniers, par exemple pour les soldes ou les lancements. Cela m'évite de me retrouver dans une situation où les intervalles prévus ne sont soudainement plus adaptés à certains événements. En pensant ainsi, on intègre une mise à l'échelle automatique pour les travailleurs et les priorités. Cela permet de maintenir la taux de réponse cohérent.
Planification à long terme avec SLO et audits
Je fixe des objectifs de service, par exemple “ 95 % des tâches cron démarrent à l'heure prévue ” ou “ 99 % des exécutions durent moins de 2 minutes ”. Ces SLO guident les décisions concernant les intervalles, les priorités et Ressources. Des audits trimestriels permettent de supprimer les anciennes tâches et les démarrages en double – il est étonnant de constater à quelle fréquence des scripts orphelins continuent de fonctionner. En cas de pénurie persistante, je passe à un VPS et soulage le système grâce à des cœurs dédiés. Cela coûte peut-être quelques euros, mais permet d'économiser beaucoup plus grâce à une stabilité accrue. Temps de réaction.
Je documente chaque tâche cron : objectif, intervalle, durée moyenne, contact d'urgence. Je teste les modifications par étapes, j'observe les métriques et je les annule si nécessaire. Pour les équipes, un runbook avec des étapes claires est utile en cas de retards ou de pannes. Traiter les modifications cron comme du code permet d'éviter les effets secondaires. Avec des processus propres, les intervalles restent stables à long terme. approprié.
En bref
Je choisis CronjobLes intervalles ne doivent pas être déterminés selon votre intuition, mais en fonction de la durée d'exécution, du profil E/S et de l'impact sur l'utilisateur. Les tâches lourdes et cadencées de manière serrée entraînent des chevauchements et des pics précoces, tandis que des intervalles espacés et bien répartis lissent la courbe. L'optimisation des scripts, le verrouillage et les priorités ont souvent un effet plus important que le simple allongement du cycle. Les files d'attente, les cron externes et les vrais cron serveurs dissocient le travail du comportement des visiteurs. Grâce à la surveillance, aux SLO et aux audits réguliers, je maintiens la Charge du serveur Toujours dans le vert.
