Dépannage de l'utilisation élevée du processeur Sy
J'utilise un serveur Supermicro avec Ubuntu 14.04.4 LTS. Nous avons une application qui optimise le temps système, tout en touchant à peine l'espace utilisateur. Je lance la même application sur du matériel ancien, avec Ubuntu 12.04.4 LTS et le processeur est beaucoup plus équilibré entre utilisateur et système. J'ai utilisé strace pour obtenir des informations sur les performances du processus et je vois que epoll_wait occupe 98% du temps CPU du système. Je ne trouve pas beaucoup d'informations sur cet appel et je ne comprends pas ce que je trouve. Quelqu'un peut-il nous éclairer s'il vous plaît?
Vous pouvez voir où le processeur est consommé de manière encore plus détaillée en utilisant "perf":
Installer perf:
Sudo apt-get install linux-tools-$(uname -r)
Ensuite, démarrez le programme qui consomme toutes les ressources de la CPU
Ensuite, exécutez perf et capturez tous les événements de planification pendant environ 60 secondes:
Sudo perf record -a sleep 60
Une fois que cela est terminé, vous pouvez obtenir un journal de tous les événements perf en utilisant:
Sudo perf script > perf.log
et vous pouvez regarder cela, ou mieux, on peut regarder interactivement les points chauds du processeur en utilisant:
Sudo perf report
Si vous pouvez capturer la sortie du traçage du programme en utilisant l'option -e epoll_wait uniquement pour capturer l'appel système epoll, ajoutez-le à cette question, nous pourrons alors comprendre ce qui se passe.
En règle générale, l'appel système epoll_wait attend certains événements epoll et une consommation de processeur élevée sur les appels système epoll_wait peut signifier qu'un délai d'attente donné est trop court et que cela provoque plusieurs dizaines de milliers d'appels epoll_wait dans une boucle ou qu'il y en a En effet, de nombreux événements se produisent, que epoll_wait attend et que le code gère. Alternativement, cela pourrait être un bogue dans le programme et il tourne sur une sorte d'erreur. Les conditions d'erreur typiques sont EINVAL, lorsqu'un paramètre non valide est transmis à l'appel système, ou EBADF, où un descripteur de fichier non valide est utilisé (éventuellement à partir d'une ouverture ayant échoué).
Alors, recommencez le programme:
strace -f -e epoll_wait program-name >& strace.log
et voyez quel type d’échec epoll_wait se produit (retour de -1). Si aucune défaillance ne se produit, vérifiez ensuite si un délai d'attente s'est écoulé (0) ou si un descripteur de fichier est prêt pour les E/S (retour> 0).