Duże obciążenie spowodowane oczekiwaniem we / wy w systemie Ubuntu 12.04 w instancji EC2

Używam serwera Ubuntu 12.04, mam problem ze znalezieniem przyczyny obciążenia, widziałem zmianę w czasie odpowiedzi serwera z ostatniego tygodnia

po przeczytaniu Rozwiązywanie problemów z systemem Linux, część I: Wysokie obciążenie

Wygląda na to, że nie ma problemu z procesorem i pamięcią RAM, a to obciążenie może być powiązane z obciążeniem związanym z We / Wy za pomocą toppolecenia, które otrzymałem po wyjściu

Tutaj jest 97.6%wa, pamięć RAM jest bezpłatna i nie jest używana zamiana.

Poniżej znajduje się wynik polecenia, iostatktóre sieje89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

Użyłem również, iotopktóry po okresie naprawy pokazuje 99% We / Wy, Dysk zapisuje I obserwator jako1266 KB/s

i

Czy jest źle? w miarę zmniejszania się czasu odpowiedzi. co to powoduje?

EDYCJE, o które proszą inni

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

wyjście z iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok punkt 2

iotop -a

Dostrój usługę mysql, aby uniknąć dotykania dysku i uważaj w kolejce postfiksów, możesz mieć wiele wiadomości e-mail w kolejce wrażliwej na operacje we / wy (tj. Odroczone, małe znaki z losowym odczytem).

Twój system e-mail został wykorzystany jako przekaźnik dla spamerów.

Zajrzyj do dokumentacji Postfiksa i ogranicz dostęp przekaźnika do swojego MTA.

Edytowane po dodatkowych informacjach zebranych przy użyciu iostat i iotop
Dysk jest w 100% ładowany, ponieważ kończy się na nim dostępny IOPS: zgodnie z Iostatem masz stałe 50+ IOPS (85 w / s - 35 scalonych w / s). Instancje EC2, szczególnie tanie, mają silne ograniczenie trwałego IOPS (w zakresie 30-50 IOPS).

Zgodnie z nowym wyjściem iotop, zarówno mysql, jak i bounce zjadają znaczną ilość IOPS. Wydaje się jednak, że wyniki iotop nie są kompletne lub przynajmniej źle posortowane. Czy możesz ponownie uruchomić sortowanie „iotop -a” jeden raz według IOPS, a drugi raz według zapisu na dysku?

Oryginalna odpowiedź
Mój zakład: proces „odbicia” powoduje wiele zsynchronizowanych zapisów, które dławią wirtualne urządzenie dyskowe oferowane przez Amazon (a propos, jakiego profilu używasz? Dyski EC2 mają dość surowe reguły dla operacji we / wy podtrzymywanych vs.

W każdym razie określenie, co płonie przepustowość we / wy, może być czasami nieco trudne. Chociaż iotop jest bardzo dobrym narzędziem, czasami nie zapewnia wymaganych informacji. Musimy zejść głębiej. Postępuj zgodnie z tymi wskazówkami:

1. Najpierw musimy zidentyfikować typ przetwarzanego We / Wy i urządzenie blokujące, którego dotyczy problem.
   Proszę uruchomić następującą komendę: iostat -x -k 5 2. Zgłoś oba zestawy wyników.
2. Następnie musimy zidentyfikować procesy oczekujące na We / Wy .
   Kiedy można do tego użyć „góry”: uruchom go, naciśnij shift + f (F), następnie w, następnie wprowadź, a następnie shift + r (R). Pierwszymi procesami będą procesy w stanie D lub D + (tj. Oczekiwanie na dysk / sieć). Zgłoś ponownie listę.
3. Użyj iotop, aby wyświetlić skumulowane wartości We / Wy dla procesów .
   Uruchom iotop -aprzez około minutę i wklej tutaj dane wyjściowe.

Trochę późno, ale miałem ten sam problem na podobnej maszynie i dowiedziałem się, że problemem była wiązka uszkodzonych tabel MySQL. Ponieważ niektóre z tych tabel zawierały dużo danych, generowało dużo czasu oczekiwania na operacje we / wy.

Sprawdź /var/log/mysql/error.loglub użyj, mysqlcheckaby znaleźć i naprawić uszkodzone dane.

Jak wspomniano powyżej, jest całkiem prawdopodobne, że twoja instancja EC2 ma limit IO, a może jest oparta na standardowym wolumenie Amazon EBS, który po prostu nie zapewnia zbyt dużej ilości IO. Spójrz, że ta strona - opisuje różne typy woluminów oferowanych przez Amazon.

Nawet jeśli masz wolniejszy wolumin, powinieneś być w stanie pisać na nim dość szybko, ale jeśli twoje obciążenie jest z natury losowe, jak się wydaje, może być (SQL), możesz chcieć zaktualizować IOPS pojemność, ponieważ zwykle ogranicza to wydajność SQL.

Więc - z twoich liczb mogłoby się wydawać, że zabrakło Ci IOPS przy użyciu standardowej pamięci. Kupowanie szybszego miejsca do przechowywania nie jest tak drogie. Spójrz na to .

Dysk może być w trybie innym niż DMA. Sprawdź status DMA napędu. (polecenie hdparm)

Jeśli tak nie jest, coś innego może generować wiele przerwań. Czy ktoś pamięta te z dawnych dobrych czasów DOS?