Vous pouvez le faire de différentes manières. Notez qu'il est tout à fait possible que ses nombreux processus soient provoqués par un scénario délirant, et non par un seul.
La première consiste à configurer pidstat pour qu'il s'exécute en arrière-plan et génère 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 toutes les dix minutes. Je suggérerais qu'il s'agisse de votre premier port d'escale, car il produit les données les plus précieuses / fiables pour travailler.
Il y a un problème avec cela, principalement si la boîte passe dans une boucle emballée d'un processeur et produit une charge énorme - vous n'êtes pas assuré que votre processus s'exécutera de manière ponctuelle pendant le chargement (le cas échéant), de sorte que vous risquez de manquer la sortie. !
La deuxième méthode consiste à activer la comptabilisation des processus. Peut-être plus d'une option à long terme.
accton on
Cela permettra la comptabilisation des processus (si elle n’a pas déjà été ajoutée). S'il ne fonctionnait pas avant, il vous faudra du temps pour le faire.
Après avoir été exécuté, par exemple, pendant 24 heures, vous pouvez alors exécuter une telle commande (qui produira une sortie comme celle-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 telles:
- Nombre d'appels
- Pourcentage d'appels
- Quantité de temps réel passé sur tous les processus de ce type.
- Pourcentage.
- Temps de calcul de l'utilisateur
- Pourcentage
- Temps CPU du système.
- Appels IO moyens.
- Pourcentage
- Nom de la commande
Ce que vous allez rechercher, ce sont les types de processus qui génèrent le plus de temps CPU par utilisateur / système.
Cela décompose les données en tant que quantité totale de temps CPU (la ligne du haut) et ensuite comment ce temps CPU a été fractionné. La comptabilité de processus ne se comptabilise que correctement lorsque les processus sont générés. Il est donc probablement préférable de redémarrer le système après lui avoir permis de s'assurer que tous les services sont comptabilisés.
Ceci, en aucun cas, ne vous donne réellement une idée précise du processus qui pourrait être la cause de ce problème, mais qui pourrait vous donner une bonne impression. Comme il pourrait s'agir d'un instantané de 24 heures, il y a une possibilité de résultats biaisés, alors gardez cela à l'esprit. Il devrait également toujours se connecter car c’est une fonctionnalité du noyau et contrairement à pidstat, elle produira toujours une sortie même lors de fortes charges.
La dernière option disponible utilise également la comptabilisation des processus afin que vous puissiez l'activer comme ci-dessus, mais utilisez ensuite le programme "lastcomm" pour générer des statistiques sur les processus exécutés à peu près au moment du problème, ainsi que sur les statistiques de l'unité centrale 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 indices quant à ce qui pourrait causer le problème.
