Surveiller les appels du système CPU / système sous Linux

J'ai quelques processus qui gaspillent beaucoup de temps CPU CPU (comme cela a été déterminé en regardant vmstat). Existe-t-il un moyen simple de savoir quel type d'appels système est en cours?

Je sais qu'il y a une contrainte, mais y a-t-il un moyen plus rapide et plus facile? Existe-t-il un "top" pour les appels système?

3 Solutions collect form web for “Surveiller les appels du système CPU / système sous Linux”

Je pense que Strace avec le drapeau -c est probablement le plus proche que je connaisse. Si vous n'avez pas utilisé l'indicateur -c , essayez ceci:

 $ sudo strace -c -p 12345 

Lorsque 12345 est l'ID de processus (PID) du processus en question. Notez que l'élimination d'un processus ajoute des frais généraux supplémentaires, alors pendant que vous le tracerez, le processus fonctionnera plus lentement.

Après avoir fonctionné pendant longtemps, vous souhaitez collecter des données, appuyez sur Ctrl-C pour arrêter votre collecte de données et produire les résultats. Cela produira quelque chose comme ceci:

 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 31.88 0.001738 145 12 futex 16.79 0.000915 11 80 tgkill 12.36 0.000674 34 20 read 9.76 0.000532 266 2 statfs 8.42 0.000459 13 35 time 4.38 0.000239 6 40 gettimeofday 3.65 0.000199 4 48 sigprocmask 2.94 0.000160 18 9 open 2.88 0.000157 12 13 stat64 1.32 0.000072 9 8 munmap 0.90 0.000049 6 8 mmap2 0.88 0.000048 3 14 7 sigreturn 0.79 0.000043 5 9 close 0.77 0.000042 4 10 rt_sigprocmask 0.64 0.000035 3 12 setitimer 0.55 0.000030 5 6 6 rt_sigsuspend 0.53 0.000029 4 8 fstat64 0.29 0.000016 8 2 setresuid32 0.13 0.000007 4 2 _llseek 0.09 0.000005 3 2 prctl 0.04 0.000002 2 1 geteuid32 ------ ----------- ----------- --------- --------- ---------------- 100.00 0.005451 341 13 total 

Comme vous pouvez le voir, il s'agit d'une ventilation de tous les appels système effectués par l'application, triés par temps total, y compris le temps moyen par appel et le nombre d'appels pour chaque syscall. Si vous souhaitez les trier différemment, consultez la page du manuel pour Strace, car il y a quelques options.

Peut-être essayer un des profileurs d'échantillonnage, tels que oprofile, ou pour les noyaux plus récents, perf. Si vous êtes chanceux, "perf top" pourrait vous dire précisément ce que vous voulez. Voir ici quelques exemples

Le type de commutateurs Strace que j'ai tendance à utiliser est celui-ci.

Strace -ffttT -p pid -o /tmp/strace.out

Un exemple de ceci ressemblerait,

 19:35:57.485493 mprotect(0x7f35e7472000, 16384, PROT_READ) = 0 <0.000037> 19:35:57.485599 mprotect(0x7f35e7692000, 4096, PROT_READ) = 0 <0.000030> 19:35:57.485697 mprotect(0x7f35e78b7000, 4096, PROT_READ) = 0 <0.000030> 19:35:57.485782 munmap(0x7f35e7896000, 129588) = 0 <0.000037> 19:35:57.485875 set_tid_address(0x7f35e78949d0) = 10730 <0.000029> 19:35:57.485960 set_robust_list(0x7f35e78949e0, 0x18) = 0 <0.000024> 19:35:57.486048 futex(0x7fff8f58628c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000025> 19:35:57.486131 futex(0x7fff8f58628c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f35e7894700) = -1 EAGAIN (Resource temporarily unavailable) <0.000024> 

Vous voyez la différence de temps sur le côté droit de l'appel système indiquant combien de temps il a fallu pour passer d'un appel système à un autre.

Il vous prendra compte de la différence de temps entre les appels système. Donc, lorsque vous voyez qu'un appel système a un espace de quelques secondes avec le prochain appel système, alors il y a du bruit.

Une autre méthode consiste à corardigner avec gcore. Cependant, cela nécessite un peu d'expérience dans la navigation par gdb.

Mais, si le thread est un fil de noyau, alors vous ne pouvez pas le forcer ou le coronger. Dans ce cas, nous devons utiliser quelque chose de plus complexe. Dans le noyau RHEL5, nous utilisons oprofile. Chez RHEL6, nous utilisons perf. Je préfère la performance sur oprofile. Les données de Perf peuvent être collectées avec un format de graphique comme le montrant l'appel système où le pourcentage maximum de CPU est utilisé.

Avec une performance de test, je vois cela.

 38.06% swapper [kernel.kallsyms] [k] mwait_idle_with_hints ↑ 29.45% swapper [kernel.kallsyms] [k] read_hpet 4.90% swapper [kernel.kallsyms] [k] acpi_os_read_port ▒ 4.74% swapper [kernel.kallsyms] [k] hpet_next_event 

Il montre la fonction kernel où 38% du temps CPU est dépensé. Maintenant, nous pouvons vérifier la fonction et voir ce qu'elle fait et ce qu'elle est supposée faire.

Avec quelques exemples, ce n'est pas tellement difficile.

  • Performances d'access aux files Centos 6 vs Centos 7
  • Fixation de strace à 100% process CPU Apache - sortie
  • Comment parsingr les appels système lorsque votre disque est en lecture seule et la sortie strace est "Erreur de bus"?
  • Charges de pages longues - problèmes de search DNS?
  • Surveiller tous les process nouvellement engendrés sur une machine Linux
  • Le process Apache consum trop de CPU
  • Comment définir la longueur de string de caractères de sortie strace pour être plus longue?
  • MySQL se bloque si la connection provient de l'extérieur du LAN
  • Sortie étrange du process httpd d'apache exécutant django avec mod_wsgi
  • La sortie du process Strace Apache montre 24 secondes d'attente? Quelle en est la raison?
  • Déboguer irssi en utilisant 100% de processeur
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.