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ść?

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.

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.