Il y a quelques façons possibles de faire cela. Notez qu'il est tout à fait possible que ce soit de nombreux processus dans un scénario de fuite qui causent cela, pas seulement un.
La première façon est de configurer pidstat pour s'exécuter en arrière-plan et produire des données.
pidstat -u 600 >/var/log/pidstats.log & disown $!
Cela vous donnera un aperçu assez détaillé du fonctionnement du système à intervalles de dix minutes. Je vous suggère de commencer par là car cela produit les données les plus précieuses/fiables avec lesquelles travailler.
Il y a un problème avec cela, principalement si la box entre dans une boucle CPU en fuite et produit une charge élevée - vous n'êtes pas garanti que votre processus réel s'exécutera en temps voulu pendant la charge (si jamais) donc vous pourriez en fait manquer la sortie!
La deuxième façon de chercher cela est d'activer la comptabilité des processus. Peut-être plus une option à long terme.
accton on
Cela activera la comptabilité des processus (si ce n'était pas déjà ajouté). S'il ne fonctionnait pas avant, cela prendra du temps pour s'exécuter.
Ayant été exécuté, par exemple 24 heures - vous pouvez ensuite exécuter une commande telle que celle-ci (qui produira une sortie comme ceci)
# sa --percentages --separate-times
108 100.00% 7.84re 100.00% 0.00u 100.00% 0.00s 100.00% 0avio 19803k
2 1.85% 0.00re 0.05% 0.00u 75.00% 0.00s 0.00% 0avio 29328k troff
2 1.85% 0.37re 4.73% 0.00u 25.00% 0.00s 44.44% 0avio 29632k man
7 6.48% 0.00re 0.01% 0.00u 0.00% 0.00s 44.44% 0avio 28400k ps
4 3.70% 0.00re 0.02% 0.00u 0.00% 0.00s 11.11% 0avio 9753k ***other*
26 24.07% 0.08re 1.01% 0.00u 0.00% 0.00s 0.00% 0avio 1130k sa
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28544k ksmtuned*
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28096k awk
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 29623k man*
7 6.48% 7.00re 89.26% 0.00u 0.00% 0.00s
Les colonnes sont commandées comme suit:
- Nombre d'appels
- Pourcentage d'appels
- Montant du temps réel passé sur tous les processus de ce type.
- Pourcentage.
- Temps d'UC utilisateur
- Pourcentage
- Temps CPU système.
- Appels IO moyens.
- Pourcentage
- Nom de la commande
Vous chercherez les types de processus qui génèrent le plus de temps CPU utilisateur/système.
Cela décompose les données en fonction de la quantité totale de temps CPU (la ligne supérieure) puis comment ce temps CPU a été réparti. La comptabilité des processus ne fonctionne correctement que lorsqu'elle est activée au moment où les processus sont générés, il est donc probablement préférable de redémarrer le système après l'avoir activée pour s'assurer que tous les services sont pris en compte.
Cela ne vous donne en aucun cas une idée définitive de quel processus pourrait être la cause de ce problème, mais cela pourrait vous donner une bonne idée. Comme il pourrait s'agir d'un instantané de 24 heures, il est possible d'obtenir des résultats biaisés, donc gardez cela à l'esprit. De plus, il devrait toujours se connecter car il s'agit d'une fonction du noyau et contrairement à pidstat produira toujours des sorties même en cas de charge importante.
La dernière option disponible utilise également la comptabilité des processus, vous pouvez donc l'activer comme ci-dessus, puis utiliser le programme "lastcomm" pour produire des statistiques sur les processus exécutés autour du moment du problème ainsi que des statistiques CPU pour chaque processus.
lastcomm | grep "May 8 22:[01234]"
kworker/1:0 F root __ 0.00 secs Tue May 8 22:20
sleep root __ 0.00 secs Tue May 8 22:49
sa root __ 0.00 secs Tue May 8 22:49
sa root __ 0.00 secs Tue May 8 22:49
sa X root __ 0.00 secs Tue May 8 22:49
ksmtuned F root __ 0.00 secs Tue May 8 22:49
awk root __ 0.00 secs Tue May 8 22:49
Cela pourrait également vous donner des indices sur ce qui pourrait causer le problème.
