Question Comment empêcher les tâches utilisateur cron d’écraser les serveurs?


Il arrive assez souvent que des tâches utilisateur sur des serveurs partagés s'exécutent toutes en même temps et se retrouvent en conflit (presque à ma connaissance). Alors la charge explose, Nagios est en colère, Apache cesse de répondre, vous ne pouvez pas entrer SSH parce que le délai est expiré, etc. Je ne peux pas décider unilatéralement que les utilisateurs ne peuvent pas exécuter Crons, mais j'aimerais pour combattre ce problème où pgrep crond | wc -l renvoie> 50.

Il semble qu'il devrait être possible de les étaler en limitant le nombre de processus crond exécutés à un moment donné ou similaire (comme l'envoi de SIGSTOP jusqu'à ce que certains d'entre eux clarifient moins le problème), mais je n'ai pas encore trouvé de bonne piste.

Le matériel: 4 processeurs et plus, bas de gamme: Dell 1435 avec ~ 8 Go de mémoire, RAID 10 WD EADS Principalement Plesk et cPanel, mais aussi certains systèmes Sphera diaboliques.

Comment gérez-vous ce problème, sf?


7
2017-10-16 02:16


origine




Réponses:


Vous pouvez utiliser cron.allow et cron.deny limiter l'accès des utilisateurs à cron, ou vous pouvez utiliser Limites de PAM pour limiter l'utilisation du processeur, le nombre de processus, etc. En dehors de cela, la solution consiste à créer quelque chose à surveiller et à traiter cron travaux par utilisateurs, car cron n’a pas vraiment de limite sur le nombre de travaux à exécuter.

Je pense que CPanel a quelque chose sur le nombre de tâches cron en cours d'exécution en même temps, mais c'est un outil spécifique (pas sûr).


5
2017-10-16 02:43



Ooh, merci, je vais devoir examiner les limites de PAM. Cela pourrait au moins aider à atténuer le problème, sinon à le résoudre. - Wyatt


Je pense que vous avez l'un de ces problèmes:

  • pas assez de mémoire pour exécuter les crontabs en même temps. Vous pouvez réparer par:

    • ajouter plus de RAM
    • limiter la mémoire maximale qu'un utilisateur peut allouer
    • replanifier les travaux pour réduire le nombre de travaux simultanés - vous devrez peut-être remplacer crond et utiliser un autre planificateur
  • haut I / O. Vous pouvez réparer par:

    • abaissement de la priorité E / S avec ionice
    • replanifier les travaux pour réduire le nombre de travaux simultanés

Essayez de savoir si la machine est en train de permuter, et si elle ne change pas pendant la nuit, changez la classe de priorité d'entrée / sortie cron en veille:

sudo ionice -c 3 -p $(pgrep cron)

2
2017-10-16 03:26



Ce n'est certainement pas la mémoire; la plupart de ces boîtes ont environ 28 Go et aucune en a moins de 8. L'utilisation d'un autre planificateur prendrait beaucoup de temps à tester et à évaluer. Ionice m’était venu à l’esprit, mais pour deux problèmes: 1) certains d’entre eux contiennent des noyaux antérieurs à 2.6.13 et 2) cela ne peut pas être quelque chose qui nous oblige à le prendre dans la loi pour le réparer. (D'une part, il y a plus de 100 serveurs) - Wyatt


J'ai toujours programmé des tâches cron à des heures aléatoires (surtout des minutes). Je vois couramment des exemples cron qui fonctionnent à minuit comme:

0 0 * * *  /usr/bin/echo "Job ran"

Si vous avez beaucoup d'emplois définis comme cela, vous posez des problèmes. Malheureusement, ces tâches sont souvent longues. J'ai aussi tendance à planifier des tâches à différentes heures au cours d'une fenêtre de traitement par lots. (23 à 05) heures.

J'aime la nouvelle spécification cron utilisée sur Ubuntu. Cela a plusieurs /etc/cron.* répertoires pour spécifier les travaux à exécuter. Ils sont exécutés en séquence plutôt que parallèlement, limitant la charge.

Vous devriez pouvoir voir ce qui est planifié dans les fichiers situés dans /etc/spool/cron/crontabs. La lecture de ces fichiers nécessite un accès root. Si ce sont les utilisateurs qui causent les problèmes, discutez-en avec eux.

Vous pouvez aussi vérifier /var/log/syslog pour les entrées CRON pour voir ce qui est exécuté quand.


1
2017-10-16 14:59