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.

  • Peut-être me montrer le nom du fichier / chemin pour syscalls lecture / écriture
  • Serveur Web Apache maximisé en raison de process bloqués à l'état D
  • La sortie du process Strace Apache montre 24 secondes d'attente? Quelle en est la raison?
  • upstart - countur de la fourchette de controller> 2 (peut; t get le controller pour commencer à démarrer)
  • WSGI ne peut pas accéder à un file, mais les permissions sont correctes
  • Peut-être me montrer le nom du file / path pour syscalls de lecture / écriture
  • MySQL se bloque si la connection provient de l'extérieur du LAN
  • Comment get des PID en attente d'un sémaphore
  • Arrêter intentionnellement un process de répondre
  • Mysql tue la CPU avec gettimeofday
  • ouverture de trace sur un certain file
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.