kworker zużywa + 90% IO i zapis na dysku zerowym


22

jest to standardowy serwer WWW Apache na AWS Linux AMI + EBS. Zauważamy wysoką średnią obciążenia (+8) i iotop -apokazuje:

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

Gdy apache jest wyłączony, kworker i jbd2 również nie działają.

Serwer nie zamienia się, ponieważ mamy dużo dostępnej pamięci RAM. Widziałem ten problem związany z serwerami baz danych, ale nic nie odizolowało tylko Apache.

Masz pomysł, jak dalej to zdiagnozować i jak temu zapobiec?

AKTUALIZACJA 1: raport 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                                        ▒

3
Możesz użyć perf, aby dowiedzieć się, co robi kworker jako krok rozwiązywania problemów.
David Schwartz

Zachowanie kworkera jest technicznie interesujące, ale zastanawiam się, dlaczego wątki Apache zapisują megabajty na dysku. Zakładając, że to wyjaśnia 2 MB / s, czy to nie jest tak wysokie jak na serwer WWW? Następnie można zidentyfikować zapisywane pliki, np. strace -p(A może również lsof) i sprawdzić, czy to pokazuje coś interesującego.
sourcejedi

1
Czy to przypadkiem zamiana?
Grizly,

1
Spróbuj włączyć sendfilena Apache, aby skorzystać z zerowej kopii.
fgbreel

1
@ user2383712 Ten problem może dotyczyć twojego „sąsiada” w chmurze. Czy możesz skontaktować się z aws w sprawie tego problemu, jeśli nie spróbujesz zamknąć instancji aws w celu zmiany jej hiperwizora, miałem ten problem w przeszłości.
Alin Andrei

Odpowiedzi:


5

100% IO nie oznacza, że ​​wykorzystuje wszystkie twoje operacje IO. Oznacza to, że robi tylko czekanie na IO. Dlatego wysoki% IO przy niskiej / zerowej przepustowości dysku może być normalny.

man iotop:

[...] Wyświetla również procent czasu, jaki wątek / proces spędził podczas wymiany i oczekiwania na I / O.

To może być inny problem, jeśli kworkerczekasz na IO na zawsze, ale nie wiem. Może to powinno czekać na fajce czy coś takiego. kworkerCzasami widzę, że robię to samo na moim serwerze i nie wydaje się to być problemem. (Spanikowałem też po raz pierwszy.)


1
Dzieje się tak również we wspólnym środowisku, gdzie wszyscy mają dostęp do tych samych macierzy pamięci. Jest to znak zajętego dysku (o którym maszyna wirtualna może nic nie wiedzieć, ponieważ jest skutecznie izolowana). Na dedykowanym sprzęcie bardziej prawdopodobne byłoby uszkodzenie dysku z dużą ilością ponownych prób. W przypadku dostępu do sieci może to oznaczać złe połączenie, a także przeciążenie serwera NAS / celu.
Spooler,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.