kworker consumindo + 90% de IO e zero de gravação em disco

este é um servidor web apache padrão no AWS Linux AMI + EBS. Percebemos alta média de carga (+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 o apache está inativo, o kworker e o jbd2 também estão inativos.

O servidor não está trocando, pois temos bastante RAM disponível. Eu já vi esse problema relacionado aos servidores de banco de dados, mas nada isolado apenas para o Apache.

Alguma idéia de como diagnosticar isso ainda mais e evitá-lo?

ATUALIZAÇÃO 1: relatório perf (registro perf -g -um sono 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

Você pode usar o perf para descobrir o que o kworker está fazendo como uma etapa de solução de problemas.

— David Schwartz

O comportamento do kworker é tecnicamente interessante, mas eu me pergunto por que os threads do Apache estão gravando megabytes no disco. Supondo que isso explique os 2 MB / s, não é tão alto para um servidor web? Então, pode-se identificar os arquivos que estão sendo gravados, por exemplo strace -p(e talvez lsof) e ver se isso mostra algo interessante.

— sourcejedi

Está trocando por acaso?

— Grizly

Tente ativar sendfileno apache para tirar vantagem da cópia zero.

— Fgbreel 01/06

@ user2383712 Esse problema pode estar relacionado ao seu "vizinho" da nuvem, você pode entrar em contato com a aws sobre esse problema, se não tentar desligar a instância do aws para mudar seu hypervisor, eu já tinha esse problema no passado.

— Alin Andrei

100% IO não significa que ele está usando todas as suas operações de IO. Isso significa que não está fazendo nada além de aguardar IO. Portanto,% IO alta com largura de banda de disco baixa / zero pode ser normal.

man iotop:

[...] Ele também exibe a porcentagem de tempo que o encadeamento / processo passou durante a troca e enquanto aguardava a E / S.

Pode ser um problema diferente se você kworkerestiver aguardando IO para sempre, mas não sei. Talvez devesse estar esperando em um cano ou algo assim. kworkerÀs vezes, vejo o mesmo fazendo no meu servidor, e isso não parece ser um problema. (Também entrei em pânico na primeira vez que o vi.)

— sudo
fonte

Isso também ocorre em um ambiente compartilhado, onde todos acessam as mesmas matrizes de armazenamento. Este é um sinal de um disco ocupado (sobre o qual a VM pode não saber nada porque está efetivamente isolada). Em hardware dedicado, seria mais provável que houvesse um disco com falha e com muitas tentativas. No acesso montado em rede, pode significar um link incorreto, além de congestionamento do lado do NAS / destino.

— Spooler