kworker consomme + 90% IO et zéro écriture sur disque
il s'agit d'un serveur Web Apache standard sur AWS Linux AMI + EBS. Nous constatons une charge moyenne élevée (+8) et iotop -a montre:
Total DISK READ: 0.00 B/s | Total DISK WRITE: 2.37 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
3730 be/4 root 0.00 B 0.00 B 0.00 % 91.98 % [kworker/u8:1]
774 be/3 root 0.00 B 1636.00 K 0.00 % 15.77 % [jbd2/xvda1-8]
3215 be/4 Apache 0.00 B 40.39 M 0.00 % 0.88 % httpd
3270 be/4 Apache 0.00 B 38.20 M 0.00 % 0.93 % httpd
2770 be/4 Apache 0.00 B 46.86 M 0.00 % 0.71 % httpd
Quand Apache est en panne, kworker et jbd2 sont également en panne.
Le serveur ne change pas car nous avons beaucoup de RAM disponible. J'ai vu ce problème lié aux serveurs de base de données, mais rien seulement isolé pour Apache.
Une idée sur la façon de diagnostiquer davantage cela et de l'empêcher?
MISE À JOUR 1: rapport de perf (dossier de perf -g -a sommeil 10)
Samples: 114K of event 'cpu-clock', Event count (approx.): 28728500000
- 83.58% swapper [kernel.kallsyms] [k] xen_hypercall_sched_op ◆
+ xen_hypercall_sched_op ▒
+ default_idle ▒
+ Arch_cpu_idle ▒
- cpu_startup_entry ▒
70.16% cpu_bringup_and_idle ▒
- 29.84% rest_init ▒
start_kernel ▒
x86_64_start_reservations ▒
xen_start_kernel ▒
+ 1.73% httpd [kernel.kallsyms] [k] __d_lookup_rcu ▒
+ 1.08% httpd [kernel.kallsyms] [k] xen_hypercall_xen_version ▒
+ 0.38% httpd [vdso] [.] 0x0000000000000d7c ▒
+ 0.36% httpd libphp5.so [.] zend_hash_find ▒
+ 0.33% httpd libphp5.so [.] _zend_hash_add_or_update ▒
+ 0.25% httpd libc-2.17.so [.] __memcpy_ssse3 ▒
+ 0.24% httpd libphp5.so [.] _zval_ptr_dtor ▒
+ 0.24% httpd [kernel.kallsyms] [k] __audit_syscall_entry ▒
+ 0.22% httpd [kernel.kallsyms] [k] pvclock_clocksource_read ▒
100% IO ne signifie pas qu'il utilise toutes vos opérations IO. Cela signifie qu'il ne fait rien d'autre que d'attendre les E/S. Par conséquent, un% IO élevé avec un niveau bas/une bande passante disque nulle peut être normale.
man iotop:
[...] Il affiche également le pourcentage de temps passé par le thread/processus lors de l'échange et de l'attente des E/S.
Ce peut être un problème différent si votre kworker attend sur IO pour toujours, mais je ne sais pas. Peut-être qu'il est censé attendre sur un tuyau ou quelque chose. Je vois kworker faisant parfois la même chose sur mon serveur, et cela ne semble pas être un problème (j'ai également paniqué la première fois que je l'ai vu).