kworker verbraucht + 90% IO und kein Plattenschreiben

Dies ist ein Standard-Apache-Webserver unter AWS Linux AMI + EBS. Wir bemerken einen hohen Lastdurchschnitt (+8) und iotop -azeigen:

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

Wenn Apache ausgefallen ist, ist auch kworker und jbd2 ausgefallen.

Der Server tauscht nicht aus, da genügend RAM verfügbar ist. Ich habe gesehen, dass dieses Problem mit Datenbankservern zusammenhängt, aber nichts, was nur auf Apache beschränkt ist.

Haben Sie eine Idee, wie Sie dies weiter diagnostizieren und verhindern können?

UPDATE 1: Leistungsbericht (Leistungsnachweis -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
quelle

Sie können perf verwenden, um herauszufinden, was kworker zur Fehlerbehebung unternimmt .

— David Schwartz

Das Verhalten von kworker ist technisch interessant, aber ich frage mich, warum Apache-Threads Megabyte auf die Festplatte schreiben. Angenommen, das erklärt die 2MB / s, ist das nicht hoch für einen Webserver? Dann könnte man die Dateien identifizieren, die geschrieben werden, zB strace -p(und vielleicht auch lsof) und sehen, ob das etwas Interessantes zeigt.

— Sourcejedi

Tauscht es zufällig?

— Grizly

Versuchen Sie, sendfileauf Apache zu aktivieren , um die Nullkopie zu nutzen.

— fgbreel

@ user2383712 Dieses Problem hat möglicherweise mit Ihrem Cloud- "Nachbarn" zu tun. Können Sie aws zu diesem Problem kontaktieren? Wenn Sie nicht versuchen, Ihre aws-Instanz herunterzufahren, um den Hypervisor zu ändern, hatte ich dieses Problem in der Vergangenheit.

— Alin Andrei

100% IO bedeutet nicht, dass alle Ihre IO-Vorgänge verwendet werden. Es bedeutet, dass es nichts anderes tut, als auf IO zu warten. Daher kann ein hoher Prozentsatz von E / A bei geringer / null Festplattenbandbreite normal sein.

man iotop:

[...] Es wird auch der Prozentsatz der Zeit angezeigt, die der Thread / Prozess beim Einlagern und Warten auf E / A verbracht hat.

Es mag ein anderes Problem sein, wenn Sie kworkerewig auf IO warten, aber ich weiß es nicht. Vielleicht soll es auf eine Pfeife warten oder so. Ich sehe kworkermanchmal dasselbe auf meinem Server und es scheint kein Problem zu sein. (Ich geriet auch in Panik, als ich es zum ersten Mal sah.)

— sudo
quelle

Dies erfolgt auch in einer gemeinsam genutzten Umgebung, in der alle auf dieselben Speicher-Arrays zugreifen. Dies ist ein Zeichen für eine ausgelastete Festplatte (von der die VM möglicherweise nichts weiß, weil sie effektiv isoliert ist). Bei dedizierter Hardware handelt es sich eher um eine fehlerhafte Festplatte mit vielen Wiederholungsversuchen. Beim Zugriff über das Netzwerk kann dies eine fehlerhafte Verbindung sowie eine Überlastung der NAS- / Zielseite bedeuten.

— Spooler