kworker consume + 90% IO y cero escritura en disco

Este es un servidor web Apache estándar en AWS Linux AMI + EBS. Estamos notando un alto promedio de carga (+8) y iotop -amuestra:

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

Cuando apache está inactivo, kworker y jbd2 también están inactivos.

El servidor no se intercambia ya que tenemos mucha RAM disponible. He visto este problema relacionado con los servidores de bases de datos, pero nada solo está aislado de Apache.

¿Alguna idea sobre cómo diagnosticar esto más a fondo y prevenirlo?

ACTUALIZACIÓN 1: informe de rendimiento (registro de rendimiento -g -a sueño 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                                        ▒

— usuario2383712
fuente

Es posible que desee utilizar perf para averiguar qué está haciendo kworker como un paso de solución de problemas.

— David Schwartz

El comportamiento de kworker es técnicamente interesante, pero me pregunto por qué los hilos de Apache escriben megabytes en el disco. Suponiendo que eso explica los 2 MB / s, ¿no es tan alto para un servidor web? Entonces uno podría identificar los archivos que se están escribiendo, por ejemplo strace -p(y tal vez lsof) y ver si eso muestra algo interesante.

— sourcejedi

¿Está cambiando por casualidad?

— Grizly

Intente habilitar sendfileen apache para aprovechar la copia cero.

— fgbreel 01 de

@ user2383712 Este problema puede estar relacionado con su "vecino" en la nube. ¿Puede ponerse en contacto con aws sobre este problema? Si no intenta cerrar su instancia de aws para cambiar su hipervisor, tuve este problema en el pasado.

— Alin Andrei

100% IO no significa que esté usando todas sus operaciones IO. Significa que no está haciendo nada más que esperar a IO. Por lo tanto, un alto% IO con ancho de banda de disco bajo / cero puede ser normal.

man iotop:

[...] También muestra el porcentaje de tiempo que el subproceso / proceso pasó mientras intercambiaba y mientras esperaba E / S.

Puede ser un problema diferente si kworkerestá esperando IO para siempre, pero no lo sé. Tal vez se supone que debe estar esperando en una tubería o algo así. Veo kworkerhacer lo mismo en mi servidor a veces, y no parece ser un problema. (También entré en pánico la primera vez que lo vi).

— sudo
fuente

Esto también se encuentra en un entorno compartido, donde todos acceden a las mismas matrices de almacenamiento. Esta es una señal de un disco ocupado (del cual la VM puede no saber nada porque está efectivamente aislado). En hardware dedicado, es más probable que sea un disco defectuoso con muchos reintentos. En el acceso montado en la red, puede significar un enlace defectuoso, así como una congestión lateral NAS / objetivo.

— Spooler