Utilisation du processeur Linux et historique d'exécution des processus
Existe-t-il un moyen de voir quel (s) processus a causé le plus d’utilisation du processeur?
J'ai Amazon EC2 Linux dont l'utilisation du processeur atteint 100% et me fait redémarrer le système. Je ne peux même pas me connecter via SSH (en utilisant PuTTY).
Existe-t-il un moyen de voir ce qui cause une telle utilisation élevée du processeur et quel processus a causé cela?
Je connais la commande sar et top mais je n'ai pu trouver l'historique d'exécution des processus nulle part. Voici l'image de l'outil de surveillance Amazon EC2, mais je voudrais savoir quel processus a causé cela:
J'ai aussi essayé ps -eo pcpu,args | sort -k 1 -r | head -100 mais pas de chance de trouver une utilisation aussi élevée du CPU.
Il existe plusieurs façons possibles de procéder. Notez que c'est tout à fait possible ses nombreux processus dans un scénario d'emballement provoquant cela, pas seulement un.
La première 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 $!
Cela vous donnera un aperçu assez détaillé du fonctionnement du système à dix minutes d'intervalle. Je suggère que ce soit votre premier port d'escale car il produit les données les plus précieuses/fiables avec lesquelles travailler.
Il y a un problème avec cela, principalement si la boîte entre dans une boucle de CPU incontrôlée et produit une charge énorme - vous n'êtes pas assuré que votre processus réel s'exécutera en temps opportun pendant le chargement (le cas échéant) afin que vous puissiez réellement manquer la sortie !
La deuxième façon de rechercher cela consiste à activer la comptabilité des processus. Peut-être plus d'une option à long terme.
accton on
Cela permettra la comptabilité des processus (si ce n'est déjà fait). S'il ne fonctionnait pas auparavant, cela aura besoin de temps pour s'exécuter.
Après avoir été exécuté, disons 24 heures - vous pouvez ensuite 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
- Temps réel consacré à tous les processus de ce type.
- Pourcentage.
- Temps CPU utilisateur
- Pourcentage
- Temps CPU du système.
- Moyenne IO appels.
- Pourcentage
- Nom de la commande
Vous rechercherez les types de processus qui génèrent le plus de temps CPU utilisateur/système.
Cela décompose les données comme la quantité totale de temps CPU (la ligne du haut) et ensuite comment ce temps CPU a été divisé. La comptabilité des processus ne rend compte correctement que lorsqu'elle est activée lorsque les processus apparaissent, il est donc préférable de redémarrer le système après lui avoir permis 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 pourrait vous donner une bonne idée. Comme il pourrait s'agir d'un instantané de 24 heures, il est possible que les résultats soient biaisés, alors gardez cela à l'esprit. Il devrait également toujours se connecter car c'est une fonctionnalité du noyau et contrairement à pidstat, il produira toujours une sortie même pendant une charge élevée.
La dernière option disponible utilise également la comptabilité des processus afin que vous puissiez l'activer comme ci-dessus, mais utilisez ensuite le programme "lastcomm" pour produire des statistiques sur les processus exécutés au moment du problème ainsi que des statistiques de 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.
Atop est un démon particulièrement pratique pour regarder les hiérarchies au niveau du processus et archiver par défaut ces données pendant 28 jours. En plus de présenter une superbe interface de surveillance en temps réel, vous pouvez spécifier ces fichiers journaux à ouvrir et les parcourir.
Le article donne une idée des capacités, et vous pouvez en trouver plus dans le manpage .
C'est vraiment un merveilleux logiciel.
Des programmes tels que psmon et monit peuvent vous être utiles. Ceux-ci peuvent surveiller les processus en cours d'exécution sur votre système et si un seuil (utilisation du processeur, utilisation de la mémoire ...) est dépassé, vous pouvez les configurer pour vous envoyer un rapport par e-mail sur ce qui se passe.
Il est également possible de redémarrer automatiquement les processus qui se comportent mal.
Une solution consiste à écrire un script qui s'exécute via une minute cron ou dans une boucle de sommeil, et vous envoie un e-mail/scp job/dump vers un volume ebs ... avec une sortie pertinente (dmesg, pstree -pa et ps aux, probablement vmstat) l'instant où il trouve la moyenne de charge au-dessus d'une certaine limite ...