IOが+ 90％消費し、ディスク書き込みがゼロのkworker

これは、AWS Linux AMI + EBS上の標準のApacheウェブサーバーです。高負荷平均（+8）に気づいており、以下をiotop -a示しています。

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

Apacheがダウンすると、kworkerとjbd2もダウンします。

十分なRAMがあるため、サーバーはスワップしていません。データベースサーバーに関連するこの問題を見てきましたが、Apacheだけに孤立しているものはありません。

これをさらに診断して予防する方法についてのアイデアはありますか？

更新1：パフォーマンスレポート（パフォーマンスレコード-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
ソース

perfを使用して、トラブルシューティングの手順としてkworkerが何をしているかを調べることができます。

— デビッドシュワルツ

kworkerの動作は技術的に興味深いものですが、Apacheスレッドがディスクにメガバイトを書き込んでいるのはなぜでしょうか。それが2MB / sを説明していると仮定すると、Webサーバーにとってそれほど高くないですか？次に、書き込まれているファイル、たとえばstrace -p（おそらくlsof）を識別し、それが興味深いものを示すかどうかを確認できます。

— sourcejedi

万が一スワッピングですか？

— グリズリー

sendfileゼロコピーを利用するには、Apacheで有効にしてみてください。

— fgbreel

@ user2383712この問題は、クラウドの「隣接」に関連している可能性があります。awsインスタンスをシャットダウンしてハイパーバイザーを変更しようとしない場合、この問題についてAWSに連絡できます。

— アリンアンドレイ

100％IOは、すべてのIO操作を使用しているという意味ではありません。つまり、IOで待機する以外は何もしません。したがって、ディスク帯域幅が低い/ゼロの高い％IOは正常な場合があります。

man iotop：

[...]スワップイン中およびI / O待機中にスレッド/プロセスが費やした時間の割合も表示されます。

あなたkworkerがIOを永遠に待っているなら、それは別の問題かもしれませんが、私にはわかりません。たぶん、パイプか何かを待っているはずです。私は見kworker時々私のサーバー上で同じことをやって、問題ではないようです。（初めて見たときもパニックになりました。）

— 須藤
ソース

これは、すべてが同じストレージアレイにアクセスする共有環境にもあります。これは、ビジーディスクの兆候です（VMは事実上分離されているため、VMは何も知らないことがあります）。専用ハードウェアでは、多くの再試行を伴う障害のあるディスクである可能性が高くなります。ネットワークマウントアクセスでは、NAS /ターゲット側の輻輳だけでなく、不良リンクも意味します。

— スプーラー