kworker che consuma + 90% IO e zero disk write

questo è un server web apache standard su AWS Linux AMI + EBS. Stiamo notando una media del carico elevato (+8) e iotop -amostra:

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

Quando apache è inattivo, anche kworker e jbd2 sono inattivi.

Il server non si scambia perché abbiamo molta RAM disponibile. Ho visto questo problema relativo ai server di database, ma nulla è isolato solo da Apache.

Qualche idea su come diagnosticare ulteriormente e prevenirlo?

AGGIORNAMENTO 1: rapporto perf (perf record -g -a sleep 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
fonte

Potresti voler usare perf per scoprire cosa sta facendo kworker come fase di risoluzione dei problemi.

— David Schwartz,

il comportamento di kworker è tecnicamente interessante, ma mi chiedo perché i thread di Apache stiano scrivendo megabyte sul disco. Supponendo che spieghi i 2 MB / s, non è così alto per un server web? Quindi si potrebbero identificare i file in fase di scrittura, ad esempio strace -p(e forse lsof) e vedere se questo mostra qualcosa di interessante.

— FonteJedi

Si scambia per caso?

— Grizly,

Prova ad abilitare sendfilesu apache per sfruttare la copia zero.

— fgbreel,

@ user2383712 Questo problema potrebbe riguardare il tuo "vicino" cloud, puoi contattare aws per questo problema, se non provi a chiudere la tua istanza per cambiare l'hypervisor, ho avuto questo problema in passato.

— Alin Andrei,

100% IO non significa che sta usando tutte le tue operazioni IO. Significa che non sta facendo altro che aspettare IO. Pertanto, un alto% di I / O con larghezza di banda del disco bassa / zero può essere normale.

man iotop:

[...] Visualizza anche la percentuale di tempo trascorso dal thread / processo durante lo scambio e durante l'attesa dell'I / O.

Potrebbe essere un problema diverso se stai kworkeraspettando IO per sempre, ma non lo so. Forse dovrebbe essere in attesa su una pipa o qualcosa del genere. Vedo kworkerfare lo stesso sul mio server a volte, e non sembra essere un problema. (Ho anche preso il panico la prima volta che l'ho visto.)

— sudo
fonte

Questo è anche in un ambiente condiviso, in cui tutti accedono agli stessi array di archiviazione. Questo è un segno di un disco occupato (di cui la VM potrebbe non sapere nulla perché è effettivamente isolata). Su hardware dedicato, sarebbe più probabile che si tratti di un disco guasto con molti tentativi. In caso di accesso montato in rete, può significare un collegamento errato nonché una congestione lato NAS / target.

— Spooler,