CPU bloqué à 99% pendant quelques heures: comprendre les journaux

extrait de syslog:

CRON[pid]: (user) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -
execdir fuser -s {} 2>/dev/null \; -delete)

Mon processeur est bloqué à 99% depuis quelques heures maintenant, et je suppose que c'est à cause de cela. Est-ce que quelqu'un pourrait savoir ce que c'est, comment cela a commencé et comment l'arrêter?

EDIT: J'ai essayé top -n1et je vois cela en retour plusieurs fois:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
PID user      20   0     0    0    0 Z 99.9  0.0   0:00.00 fuser <defunct>

cette ligne se répète environ 8 fois.

EDIT2:

uname-a:

user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux`
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:    11.10
Codename:   code

EDIT 3:

Après le redémarrage, le système est revenu au même 99% cpu usageet au même top -n1résultat.

linux ubuntu logs

— Jack
source

Il y a un bug dans cette commande. La sortie stderr de l'unité de fusion est envoyée à / dev / null, comme prévu. Mais la sortie stderr de find l'est aussi, ce qui n'était probablement pas le cas. (Parce que -execdir ne lance pas la commande via le shell, donc le 2> / dev / null est traité par le shell directement appelé par cron). Cependant, bien que cela puisse masquer des symptômes pertinents, le positionnement de 2> / dev / null n'est pas la cause de l'utilisation de votre processeur.

— James Youngman

C'est très bizarre: un processus zombie ne devrait pas utiliser le temps CPU (il n'a même pas de code à exécuter). Vous avez soit un bogue dans les outils de génération de rapports de processus, soit dans votre noyau. De quel OS s'agit-il (version, noyau, etc.)? Existe-t-il une virtualisation? Quelle est la sortie de uname -aet lsb_release -a?

— Gilles 'SO- arrête d'être méchant'

La fusercommande est probablement de très courte durée. Il passe son temps à utiliser le temps CPU (temps système, pas le temps utilisateur) pour générer / traiter des données qu'il consomme (trivialement). Chaque instance de se fusertermine probablement très rapidement. Mais il est probablement exécuté plusieurs fois car il contient, je suppose, de nombreux fichiers de session. Le chiffre de 99,9% signifie probablement que cette instance de fuserCPU utilisé intensivement avant sa mort. findn'est probablement pas très agressif pour récolter des enfants; il n'appellera probablement à waitpidnouveau que lorsque vous quittez un répertoire ou que vous l'exécutez à fusernouveau.

— James Youngman

uname-a: user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a: Aucun module LSB n'est disponible. ID du distributeur: Ubuntu Description: Ubuntu 11.10 Version: 11.10 Nom de code: code

— Jack

Oups, correction: -execdir ... \;l'attente doit être immédiate, car le code retour est nécessaire à la suite du prédicat (je mélangeais cela avec -execdir ...+lequel renvoie toujours vrai, je pense).

— James Youngman

Réponses:

Il s'agit d'un travail cron qui nettoie les anciens fichiers de session de / var / lib / php5 /. S'il se bloque à 99%, vous devriez peut-être consulter le dossier de destination (/ var / lib / php5 /) pour une quantité excessive de fichiers ou peut-être même une corruption du système de fichiers.

Le processus est démarré à partir de crontab. Voir les listes crontab (décrites ici ). Vous pouvez tuer le processus et le supprimer de crontab, mais il est plus probable que vous ayez un problème sous-jacent tel qu'une quantité excessive de fichiers qui doivent être corrigés.

— Tommy
source

Si vous vous retrouvez avec plusieurs processus de nettoyage en cours d'exécution, ils peuvent interférer les uns avec les autres en générant des verrous sur le répertoire lorsqu'ils suppriment des fichiers. Essayez de le retirer temporairement de la crontab jusqu'à ce que la charge disparaisse. Ajoutez-le ensuite avec un intervalle plus long entre les exécutions. Vous souhaiterez peut-être le déplacer vers un script avec un mécanisme de verrouillage pour vous assurer qu'une seule instance est en cours d'exécution. Supprimez toutes les instances multiples de la commande pour l'instant.

— BillThor

Trouvé la réponse ici: http://www.flynsarmy.com/2011/11/fuser-using-100-cpu-in-ubuntu-11-10/

dans /etc/cron.d/php5 on Ubuntu 11.10:

Remplacer
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Avec
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

— Jack
source

Cela a fonctionné, le problème semble être résolu.

— Jack