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

J'ai quelques processus qui consomment beaucoup de temps CPU système (comme déterminé en regardant vmstat). Existe-t-il un moyen simple de savoir quel type d'appels système sont effectués?

Je sais qu'il y a du strace, mais existe-t-il un moyen plus rapide et plus facile? Existe-t-il quelque chose comme un "top" pour les appels système?

Je pense que la confrontation avec le -cdrapeau est probablement la plus proche que je connaisse. Si vous n'avez pas utilisé le -cdrapeau, essayez ceci:

$  sudo strace -c -p 12345

Où 12345 est l'ID de processus (PID) du processus en question. Notez que le stracing d'un processus ajoute une surcharge supplémentaire, donc pendant que vous le tracez, le processus s'exécutera plus lentement.

Après avoir exécuté cela pendant aussi longtemps que vous souhaitez collecter des données, appuyez sur Ctrl-Cpour 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ée par durée totale et comprenant la durée moyenne par appel et le nombre d'appels pour chaque appel système. Si vous souhaitez les trier différemment, consultez la page de manuel pour strace, car il existe deux options.

Essayez peut-être l'un des profileurs d'échantillonnage, comme oprofile, ou pour les noyaux plus récents, perf. Si vous avez de la chance, "perf top" pourrait vous dire précisément ce que vous voulez. Voir ici pour quelques exemples

Le type de commutateurs strace que j'ai tendance à utiliser est le suivant.

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

Un exemple de cela 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 le décalage horaire sur le côté droit de l'appel système indiquant le temps qu'il a fallu pour passer d'un appel système à un autre.

Il vous rattrapera le décalage horaire entre les appels système. Ainsi, lorsque vous voyez qu'un appel système a un écart de quelques secondes avec le prochain appel système, il fait du bruit.

Une autre méthode consiste à le coredump avec gcore. Cependant, cela nécessite un peu d'expérience pour naviguer dans gdb.

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

Avec un test de perf, je vois ça.

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 du noyau 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 censée faire.

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