Debugowanie opóźnień we / wy systemu Linux

Mam kilka problemów we / wy na kilku systemach Linux, którymi administruję. Przejawiają się one w tym, że procesy często blokują do kilku sekund w tak prostych wywołaniach systemowych, jak open (), unlink () lub close () w plikach (co jest problemem, ponieważ niektóre z zaangażowanych programów potrzebują raczej niskiego opóźnienia we / wy do działania prawidłowo). Prawdą jest, że omawiane systemy doświadczają umiarkowanego obciążenia we / wy, ale trudno mi pomyśleć, że wystarczyłoby to, aby uzasadnić tak ogromne czasy oczekiwania. Czasami wykonanie połączenia może potrwać dłużej niż 15 sekund (choć częściej może to potrwać 1 lub 2 lub 3 sekundy).

Moje pytanie brzmi: jak mogę dowiedzieć się, dlaczego tak się dzieje? To, czego chciałbym, to jakieś narzędzie, które mogłoby mi powiedzieć, jakie procesy są blokowane w jądrze i dlaczego to, na czym śpią, jest zajęte, co się z tym dzieje i tak dalej. Czy istnieje takie narzędzie lub istnieje inny sposób próby debugowania tego, co się dzieje?

Alternatywnie, oczywiście, jeśli masz pojęcia, co właściwie się dzieje, jak można go uniknąć?

Dla przypomnienia używam systemu plików XFS.

Teraz we właściwym czasie udało mi się rozwiązać ten problem, więc mogę przynajmniej sam się tym zająć dla potomności.

Niestety straciłem pierwotny problem z aktualizacją jądra, ale zamiast tego zyskałem nowy, jeszcze gorzej działający i równie trudny do wyśledzenia. Znalazłem następujące techniki:

Po pierwsze, blktrace/ blkparsejest narzędziem, które uważam za bardzo pomocne. Umożliwia śledzenie postępu poszczególnych żądań We / Wy z wieloma pomocnymi szczegółami, takimi jak proces, który przesłał żądanie. Pomocne jest włączenie danych wyjściowych tmpfs, aby obsługa przechowywania śledzenia nie zaczęła się sama.

Pomogło to jednak tylko do tej pory, więc skompilowałem jądro z większą funkcjonalnością debugowania. W szczególności znalazłem ftracebardzo pomocne, ponieważ pozwoliło mi to prześledzić słabo działający proces w przestrzeni jądra, zobaczyć, co zrobił i gdzie został zablokowany. Kompilacja jądra debugowania zapewnia również działające WCHANdane wyjściowe ps, co może działać jako łatwiejszy sposób na sprawdzenie, co robi proces w jądrze, przynajmniej w prostszych przypadkach.

Miałem również nadzieję, że LatencyTop będzie użyteczny, ale uznałem, że jest dość błędny, a także, że wyświetlał tylko przyczyny opóźnień, które były zbyt „na wysokim poziomie”, aby niestety były naprawdę użyteczne.

Uważam też, że jest to bardziej pomocne niż iostatprzeglądanie zawartości /sys/block/$DEVICE/statw bardzo krótkich odstępach czasu, po prostu tak:

while :; do cat /sys/block/sda/stat; sleep .1; done

Zobacz Documentation/iostats.txtw drzewie źródeł jądra format statpliku. Oglądanie go w krótkich odstępach czasu pozwoliło mi zobaczyć dokładny czas i rozmiar serii wejść / wyjść i tym podobne rzeczy.

W końcu dowiedziałem się, że problem, który miałem po aktualizacji jądra, był spowodowany przez stabilne strony , funkcję wprowadzoną w Linuksie 3.0, powodującą, w moim przypadku, Berkeley DB zatrzymał się na dłuższy czas, gdy brudne strony zostały zmapowane pliki regionu. Chociaż wydaje się, że możliwe jest załatanie tej funkcji, a także to, że problemy, które ona powoduje, mogą zostać naprawione w Linuksie 3.9, rozwiązałem najgorszy problem, na jaki miałem teraz, łatając Berkeley DB, aby umożliwić mi umieszczenie plików regionu w innym katalogu (w moim przypadku /dev/shm), co pozwala mi całkowicie uniknąć problemu.

Z mojego doświadczenia wynika, że ​​najprostszym i najbardziej szczegółowym narzędziem statystycznym, które można zainstalować w celu śledzenia tajemniczych problemów z wydajnością systemu, jest http://freecode.com/projects/sysstat aka. sar

na pewno chcesz również przyjrzeć się wynikom poleceń iostat, a zwłaszcza, ile wynosi twój% iowait poniżej 5-10% przy normalnym obciążeniu systemu (poniżej 1,0 lub więcej).

spójrz na dane wyjściowe ps, jeśli w kolumnie STAT zobaczysz statusy D, co oznacza, że ​​procesy te są zablokowane i czekają na IO, najprawdopodobniej problem sprzętowy ze sterownikiem lub dyskiem, sprawdź statystyki SMART, a także dmesg i syslog w poszukiwaniu wskazówek

sprawdź dziennik sar i określ czasy szczytu, jeśli kiedykolwiek tak się stanie, i spróbuj dopasować ten czas do zadań CRON intensywnie korzystających z dysku, np. kopii zapasowych przez sieć

możesz porównać wydajność dysku z bonnie ++

Pomyślałem, że wspomnę o strace, chociaż to pytanie ma już miesiące. Może pomóc komuś z podobnym problemem, który znajdzie tę stronę.

próbować.

strace "application"

możesz też zrobić

strace -e read,write "application"

aby po prostu pokazać zdarzenia odczytu / zapisu.

Aplikacja załaduje się normalnie (choć nieco wolniej, aby uruchomić) i możesz użyć jej normalnie, aby wywołać problem. Dane wyjściowe pojawią się w powłoce użytej do uruchomienia strace.

Zaletą strace jest to, że możesz zobaczyć najnowsze wywołanie funkcji / jądra w momencie, gdy aplikacja wyzwala spowolnienie. Może się okazać, że jeśli Twoje /homekonta są w systemie plików NFS, aplikacja z jakiegoś powodu ma problemy z we / wy pliku w systemie plików NFS.