kworker consomme + 90% d'E / S 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 -amontre:

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 n'est isolé que 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                                        ▒

— user2383712
source

Vous pouvez utiliser perf pour découvrir ce que kworker fait comme étape de dépannage.

— David Schwartz

Le comportement de kworker est techniquement intéressant, mais je me demande pourquoi les threads Apache écrivent des mégaoctets sur le disque. En supposant que cela explique les 2 Mo / s, n'est-ce pas élevé pour un serveur Web? Ensuite, on pourrait identifier les fichiers en cours d'écriture, par exemple strace -p(et peut-être lsof) et voir si cela montre quelque chose d'intéressant.

— sourcejedi

Échange-t-il par hasard?

— Grizly

Essayez d'activer sendfilesur apache pour profiter de zéro copie.

— fgbreel

@ user2383712 Ce problème peut être lié à votre "voisin" du cloud. Pouvez-vous contacter aws à propos de ce problème, sinon essayez d'arrêter votre instance aws pour changer son hyperviseur, j'ai eu ce problème dans le passé.

— Alin Andrei

100% d'E / S ne signifie pas qu'il utilise toutes vos opérations d'E / S. Cela signifie qu'il ne fait rien d'autre que d'attendre les E / S. Par conséquent, un% IO élevé avec une bande passante disque faible / nulle peut être normal.

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.

Cela peut être un problème différent si vous kworkerattendez IO pour toujours, mais je ne sais pas. Peut-être que c'est censé attendre sur une pipe ou quelque chose. Je vois kworkerparfois faire 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.)

— sudo
source

C'est également dans un environnement partagé, où ils accèdent tous aux mêmes baies de stockage. C'est le signe d'un disque occupé (dont la machine virtuelle peut ne rien savoir car elle est effectivement isolée). Sur du matériel dédié, il s'agirait plus probablement d'un disque défaillant avec beaucoup de nouvelles tentatives. Sur l'accès monté sur le réseau, cela peut signifier une mauvaise liaison ainsi qu'une congestion NAS / côté cible.

— Spooler