High IO wait - Jak ustalić pierwotną przyczynę?

10

Mam instancję MySQL na dwóch dedykowanych serwerach. Jeden do produkcji, drugi do platformy testowej.

Dwa serwery są prawie takie same, jedyną różnicą jest kontroler RAID i wolumin wirtualny (HD są takie same). Na produkcji znajduje się dedykowany kontroler RAID HW i wolumin RAID 10. Z drugiej strony kontroler RAID wydaje się być oprogramowaniem (Lenovo ThinkServer RAID 110i), a wolumin ma RAID 5.

Zauważyliśmy, że podczas zatwierdzeń MySQL mamy wysoki iowait:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 i dm-14-8 są powiązane z partycjami bazy danych.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Podejrzewam kontroler nalotów, skąd mogę mieć pewność?

Bob Sauvage
źródło
Może nie na temat: Ale dlaczego RAID5 w bazie danych? Zły pomysł z powodu luki w zapisie. HW z BBU nieco to łagodzi, ale RAID 5 jest zasadniczo dobry do czytania, a nie do pisania małych transakcji.
Hennes,
Ponieważ nie miałem wyboru ... RAID 10 nie był obsługiwany na tym kontrolerze RAID (z moją wersją RHEL) ...
Bob Sauvage
@BobSauvage jakiś postęp?
Huygens,
dla jasności: czy io-wait obejmuje również czekanie na deskryptory plików nie dostarczane przez pamięć masową? jak gniazda ...
Massimo,

Odpowiedzi:

7

Moja odpowiedź składała się z 2 części: badanie sterownika urządzenia blokowego; i optymalizację, na którą warto spojrzeć w przypadku użycia. Ale usunąłem ostatnią część, ponieważ zgłoszono, że może to prowadzić do utraty danych. Zobacz komentarze.

Badanie sprzętu

Zrozumiałem, że dla tej samej aplikacji, ale na 2 różnych zestawach sprzętu wydajność jest bardzo różna i chciałbyś zrozumieć, dlaczego. Dlatego proponuję najpierw środek, który pomoże ci znaleźć odpowiedź na pytanie „dlaczego”.

Jeśli chodzi o wydajność, często odnoszę się do mapy wydajności Linuksa udostępnionej przez Brendana Gregga na jego blogu. Widać, że na niskim poziomie (najbliżej sprzętu) takie narzędzie blktracebyłoby idealne.

Nie bardzo znając to narzędzie, rozglądam się i znalazłem ten interesujący artykuł dotyczący blktrace autorstwa Marca Brookera. Zasadniczo sugeruje to: wykonanie śledzenia we / wy za pomocą blktrace; za pomocą narzędzia btt w celu wyodrębnienia informacji z tego śladu. To byłoby coś takiego (dla 30 s śledzenia):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

Dane wyjściowe mogą być dość długie, ale poszukaj wpisów D2C. Daje to wyobrażenie o tym, ile czasu zajmuje we / wy dostarczone do sterownika urządzenia, aby zostało zgłoszone jako ukończone przez ten sterownik.

Przykładowe dane wyjściowe ( dnf upgradeuruchomione na maszynie wirtualnej VirtualBox na moim zajętym laptopie):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Pokazuje rozczarowującą średnią wynoszącą 45 ms na I / O z maksymalnie 3,94 s dla najgorszego przypadku !!

Aby dowiedzieć się więcej na temat korzystania z blktrace do przeprowadzenia tego dochodzenia, przeczytaj artykuł Marca Brookera, bardzo pouczający.

Huygens
źródło
W blogu Percona, do którego odwołuje się poprawka w odpowiedzi w celu poprawy wydajności innodb , zaktualizowano: Aktualizacja: nie rób tego, udowodniono, że powoduje to uszkodzenie danych!
vkats
@vkats wielkie dzięki. Zaktualizowałem odpowiedź, aby usunąć sugestię i artykuł.
Huygens
1

Proces jbd2 służy do rejestrowania w ext4. Logiczne jest, że system plików musi zapisywać do dziennika podczas zatwierdzeń mysql, nie powinno to być powodem do zmartwień. Na wielkość obciążenia spowodowanego przez JBD wpływ mają parametry montowania dla partycji DM-10-8 i DM-14-8. Prawdopodobnie pożądane jest bardzo konserwatywne dziennikowanie na partycji bazy danych, aby upewnić się, że baza danych nie ulegnie uszkodzeniu, jeśli coś się stanie, a serwer przypadkowo uruchomi się ponownie. Możesz wybrać inne opcje montowania dziennika w środowisku testowym tylko dla porównania.

ludvik02
źródło
mój jbd2 / dm-2-8 wydaje się cały czas około 8,5% w iotop, ale .. Nie sądzę, że jest to problematyczne, ponieważ nie ma odczytu dysku, a całkowity zapis dysku wynosi 35 MB po 1 godzinie. btw, w / dev jest co najwyżej dm-2 (że -8 nie mam pojęcia, skąd to jest ..)
Aquarius Power