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
źródło
Odpowiedzi:
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.
źródło
qshape deferredpolecenia.postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cfpostconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1dostałem te błędyqshape deferred/var/lib/postfix/deferred. Przenieś je doholdkolejki w celu dalszego zbadania lub oczyszczenia.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:
Proszę uruchomić następującą komendę:
iostat -x -k 5 2. Zgłoś oba zestawy wyników.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ę.
Uruchom
iotop -aprzez około minutę i wklej tutaj dane wyjściowe.źródło
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.źródło
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 .
źródło
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?
źródło