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

9

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

Obciążenie i użycie pamięci

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

wprowadź opis zdjęcia tutaj

i

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj

iotop -a

wprowadź opis zdjęcia tutaj

Słomiany kapelusz
źródło
1
99% IOwait z 0 dyskami do odczytu i zapisu nie wygląda dobrze. Tutaj serverfault.com/questions/426181/... wspomniano, że operacje wejścia / wyjścia mogą być związane nie tylko z aktywnością dysku, ale także z siecią. Czy możesz to sprawdzić na przykład za pomocą iftop (i innych narzędzi)?
Andrey Sapegin,
@AndreySapegin dodał iftop
Straw Hat
Wydaje mi się, że problemem był dysk, na którym wdrożono instancję AWS. Utworzyłem AMI bieżącej instancji i uruchomiłem nową instancję za jej pomocą. Teraz nie ma dodatkowego obciążenia we / wy
Straw Hat
@StrawHat Czy to oznacza, że ​​uważasz, że coś było nie tak z dyskiem w pierwszej instancji?
sbrattla
@sbrattla Nie, myślę. po kilku dniach pojawił się ten sam problem
Straw Hat

Odpowiedzi:

2

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.

fgbreel
źródło
przeniesienie mysql do instancji RDS będzie działać?
Straw Hat
1
W pewnym sensie, głównym problemem jest duża liczba itenów w kolejce postfiksowej zjadających pliki Iops, które można zobaczyć za pomocą qshape deferredpolecenia.
fgbreel
postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf
Straw Hat
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1dostałem te błędyqshape deferred
Straw Hat
1
Myślę, że twój postfiks może być źle skonfigurowany, ale w przypadku obecnego problemu sprawdź, ile e-maili masz /var/lib/postfix/deferred. Przenieś je do holdkolejki w celu dalszego zbadania lub oczyszczenia.
fgbreel
1

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.
Shodanshok
źródło
iostat -x -k 5 2, a także dodał pytanie
Straw Hat
1

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.

ojovirtual
źródło
0

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 .

MrMajestyk
źródło
-3

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?

Overmind
źródło
EC2 jest platformą wirtualizacji i wykorzystuje dyski wirtualne. DMA nie jest tutaj winowajcą. W każdym razie burza IRQ stanowi żniwo dla procesora, a nie dysku.
shodanshok
Tak, a IRQ oznacza przerwanie.
Overmind
Powiedziałbym, że EC2 jest jak najdalej od tego rodzaju problemu. We / wy jest ograniczone przez typ instancji - a na koniec jakieś naprawdę drogie rozwiązanie SAN, które ma dużą pojemność.
MrMajestyk