web-dev-qa-db-fra.com

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                                        ▒
23
user2383712

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).

5
sudo