J'utilise un serveur Supermicro avec Ubuntu 14.04.4 LTS. Nous avons une application qui utilise au maximum le temps processeur du système, tout en touchant à peine l'espace utilisateur. J'exécute la même application sur un matériel plus ancien, avec Ubuntu 12.04.4 LTS et le cpu est beaucoup plus équilibré entre l'utilisateur et le système. J'ai utilisé strace pour obtenir des informations sur les performances du processus, et je vois que epoll_wait prend 98% du temps cpu du système. Je ne trouve pas beaucoup d'informations sur cet appel, et ce que je trouve, je ne le comprends pas. Quelqu'un peut-il m'éclairer à ce sujet ?
Réponses
Trop de publicités?
Colin Ian King
Points
16984
Vous pouvez voir où le CPU est consommé de manière encore plus détaillée en utilisant "perf" :
Installer perf :
sudo apt-get install linux-tools-$(uname -r)Ensuite, lancez le programme qui consomme toutes les ressources du CPU.
Ensuite, exécutez perf et capturez tous les événements de programmation pendant disons 60 secondes :
sudo perf record -a sleep 60Une fois cette opération terminée, vous pouvez obtenir un journal de tous les événements de perforation en utilisant :
sudo perf script > perf.loget vous pouvez regarder cela, ou mieux, on peut regarder interactivement les points chauds du CPU en utilisant :
sudo perf report
Colin Ian King
Points
16984
Si vous pouvez capturer la sortie du traçage du programme en utilisant l'option -e epoll_wait juste pour capturer l'appel syscall epoll, ajoutez cela à cette question et nous pourrons alors comprendre ce qui se passe.
L'appel système epoll_wait est essentiellement en attente d'événements epoll et une consommation élevée de CPU sur les appels système epoll_wait pourrait signifier soit que le délai d'attente fourni est trop petit et que cela provoque plusieurs dizaines de milliers d'appels epoll_wait s'ils sont en boucle, soit qu'il y a effectivement beaucoup d'événements qui se produisent et que l'epoll_wait attend et que le code traite. Ou encore, il peut s'agir d'un bogue dans le programme qui tourne sur une erreur quelconque. Les conditions d'erreur typiques sont EINVAL, où un paramètre invalide est passé à l'appel système, ou EBADF où un descripteur de fichier invalide est utilisé (peut-être suite à un échec d'ouverture).
Alors, remettez le programme à zéro :
strace -f -e epoll_wait program-name >& strace.loget voir quels types d'échecs epoll_wait se produisent (retour de -1). Si aucun échec ne se produit, alors vérifiez si un timeout se produit (0) ou si un descripteur de fichier devient prêt pour les E/S (retour > 0).
