Il y a plusieurs façons de procéder. Notez qu'il est tout à fait possible que ce soit plusieurs processus dans un scénario d'emballement qui soient à l'origine de ce problème, et non un seul.
La première méthode consiste à configurer pidstat pour qu'il s'exécute en arrière-plan et produise des données.
pidstat -u 600 >/var/log/pidstats.log & disown $!
Vous obtiendrez ainsi un aperçu assez détaillé du fonctionnement du système à intervalles de dix minutes. Je vous suggère de l'utiliser en premier lieu, car il produit les données les plus précieuses et les plus fiables.
Il y a un problème avec cela, principalement si la boîte entre dans une boucle de processeur et produit une charge énorme - vous n'avez pas la garantie que votre processus réel s'exécutera de manière opportune pendant la charge (voire pas du tout), de sorte que vous pourriez manquer la sortie !
La deuxième façon de procéder consiste à activer la comptabilité des processus. Il s'agit peut-être d'une option à plus long terme.
accton on
Cela permettra d'activer la comptabilité des processus (si elle n'a pas déjà été ajoutée). Si ce n'était pas le cas auparavant, il faudra un certain temps pour que cela fonctionne.
Après avoir été exécuté, par exemple pendant 24 heures, vous pouvez exécuter une commande de ce type (qui produira un résultat comme celui-ci).
# 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 classées comme suit :
- Nombre d'appels
- Pourcentage d'appels
- Temps réel consacré à l'ensemble des processus de ce type.
- Pourcentage.
- Temps CPU de l'utilisateur
- Pourcentage
- Temps CPU du système.
- Moyenne des appels IO.
- Pourcentage
- Nom de la commande
Ce que vous recherchez, ce sont les types de processus qui génèrent le plus de temps CPU utilisateur/système.
Elle décompose les données en temps total de CPU (ligne supérieure) et en répartition de ce temps de CPU. La comptabilité des processus n'est correctement prise en compte que lorsqu'elle est activée au moment où les processus se lancent. Il est donc préférable de redémarrer le système après l'avoir activée afin de s'assurer que tous les services sont pris en compte.
Cela ne vous donne en aucun cas une idée précise du processus qui pourrait être à l'origine de ce problème, mais cela peut vous donner une bonne idée. Comme il s'agit d'un instantané de 24 heures, il est possible que les résultats soient faussés, gardez cela à l'esprit. Il devrait également toujours enregistrer puisqu'il s'agit d'une fonctionnalité du noyau et que, contrairement à pidstat, il produira toujours des résultats, même en cas de forte charge.
La dernière option disponible utilise également la comptabilité des processus. Vous pouvez donc l'activer comme indiqué ci-dessus, puis utiliser le programme "lastcomm" pour produire des statistiques sur les processus exécutés à l'époque du problème, ainsi que des statistiques sur le processeur 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 pts/0 0.00 secs Tue May 8 22:49
sa root pts/0 0.00 secs Tue May 8 22:49
sa X root pts/0 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 indications sur la cause du problème.
