Jak sprawdzić wykorzystanie dysku we / wy na proces

45

Mam problem z utknięciem systemu Linux i znalazłem sysstat / sar, który zgłasza ogromne szczyty wykorzystania I / O dysku, średni czas obsługi, a także średni czas oczekiwania w czasie utknięcia systemu.

Jak mogłem ustalić, który proces powoduje te szczyty, gdy następnym razem się to stanie?
Czy można to zrobić z sar (tj .: czy mogę znaleźć te informacje z plików sar zarejestrowanych w alreade?

Wyjście dla „sar -d”, przeciągnięcie systemu nastąpiło około 12.58–13.01.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

To jest pytanie uzupełniające do wątku, który rozpocząłem wczoraj: Nagłe szczyty w obciążeniu i blokada dysku czekają , mam nadzieję, że jest ok, że stworzyłem nowy temat / pytanie w tej sprawie, ponieważ nie byłem jeszcze w stanie rozwiązać problemu.

Avada Kedavra
źródło
Wygląda na to, że problem może być mniej konkretnym procesem, a bardziej sporadycznie niereagującym dyskiem. Dyski wykonują tego rodzaju rzeczy, które na poziomie systemu wydają się być klifami, które uderzył system. Jeśli nie znajdziesz żadnych sprawców, nadszedł czas, aby zbadać podsystem dyskowy.
slashdot
unix.stackexchange.com/questions/21295/… || stackoverflow.com/questions/14021810/…
Ciro Santilli 18 改造 中心 法轮功 六四 事件
Korzystanie z htop serverfault.com/a/25034/373867
qwr

Odpowiedzi:

46

Jeśli masz szczęście, aby złapać następny okres szczytowego wykorzystania, możesz interaktywnie badać statystyki operacji we / wy dla poszczególnych procesów za pomocą iotop .

halp
źródło
Hej dzięki! Jeszcze jedna fajna zabawka do przechowywania w moim zestawie narzędzi. :-)
Janne Pikkarainen,
Uruchomienie iotop w trybie wsadowym może być bardzo dobrym uzupełnieniem / zamiennikiem powyższego rozwiązania „ps -eo”. Dzięki!
Avada Kedavra,
2
Niesamowite, „iotop -n 1 -b -o” zapewnia dokładnie to, czego potrzebuję. Dzięki!
Avada Kedavra,
wygląda na to, że wymaga to dostępu roota do systemu
user5359531
29

Możesz użyć pidstat do drukowania skumulowanych statystyk IO na proces co 20 sekund za pomocą tego polecenia:

# pidstat -dl 20

Każdy wiersz będzie miał następujące kolumny:

  • PID - identyfikator procesu
  • kB_rd / s - Liczba kilobajtów, które zadanie spowodowało odczytaniem z dysku na sekundę.
  • kB_wr / s - Liczba kilobajtów, które zadanie spowodowało lub spowoduje zapis na dysk na sekundę.
  • kB_ccwr / s - Liczba kilobajtów, których zapis na dysk został anulowany przez zadanie. Może się to zdarzyć, gdy zadanie obetnie trochę brudnego pagecache. W takim przypadku niektóre operacje zamówienia, które zostały rozliczone z innego zadania, nie będą miały miejsca.
  • Command - nazwa polecenia zadania.

Dane wyjściowe wyglądają następująco:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              
użytkownik920391
źródło
10

Nic nie przebije ciągłego monitorowania, po prostu nie możesz odzyskać danych wrażliwych na czas po wydarzeniu ...

Istnieje kilka rzeczy, które mogą być w stanie sprawdzić się wplątać lub wyeliminowania jednak - /procjest twoim przyjacielem.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Pola 10, 11 to skumulowane sektory zapisu i zapis skumulowanego czasu (ms). To pokaże twoje gorące partycje systemu plików.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

Te pola to PID, polecenia i skumulowane znaczniki IO-wait. Spowoduje to wyświetlenie twoich gorących procesów, choć tylko wtedy, gdy nadal działają . (Prawdopodobnie chcesz zignorować wątki dziennika systemu plików).

Przydatność powyższego zależy od czasu bezczynności, charakteru twoich długotrwałych procesów i sposobu użytkowania systemów plików.

Ostrzeżenia: nie dotyczy jąder starszych niż 2.6, sprawdź dokumentację, jeśli nie jesteś pewien.

(Teraz idź i zrób sobie przysługę dla siebie, zainstaluj Munin / Nagios / Cacti / cokolwiek ;-)

pan. spuratic
źródło
10

Zastosowanie atop. ( http://www.atoptool.nl/ )

Zapisz dane do skompresowanego pliku, który atopmożna później odczytać w interaktywnym stylu. Odczytaj (delta) co 10 sekund. zrób to 1080 razy (3 godziny; więc jeśli o tym zapomnisz, plik wyjściowy nie zabraknie Ci dysku):

$ atop -a -w historical_everything.atop 10 1080 &

Gdy coś złego się powtórzy:

(nawet jeśli nadal działa w tle, dodaje tylko co 10 sekund)

% atop -r historical_everything.atop

Odkąd powiedziałeś IO, uderzyłbym 3 klawisze: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display
Wayne Walker
źródło
4

Zastosowanie btrace. Na przykład jest łatwy w użyciu btrace /dev/sda. Jeśli polecenie nie jest dostępne, prawdopodobnie jest dostępne w pakiecie blktrace .

EDYCJA : Ponieważ debugfs nie jest włączony w jądrze, możesz spróbować date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtflub podobnie. Rejestrowanie błędów stron nie jest oczywiście tym samym, co używanie btrace, ale jeśli masz szczęście, MOŻE dać ci wskazówki na temat najbardziej wymagających procesów na dysku. Właśnie wypróbowałem ten jeden z moich najbardziej intensywnych serwerów we / wy, a na liście znalazły się procesy, o których wiem, że zużywają dużo we / wy.

Janne Pikkarainen
źródło
Witaj Janne, jądro nie jest niestety skompilowane z systemem plików debugowania i jest to system działający na żywo, więc nie mogę ponownie skompilować jądra. Czy istnieje inny sposób, aby to zrobić bez ponownej kompilacji?
Avada Kedavra,
OK, trochę zredagowałem swoją odpowiedź :)
Janne Pikkarainen,
Świetnie, teraz gdzieś idziemy! Zastanawiam się nad tym, aby umieścić to w cronjob i wykonać to jednocześnie z zadaniem sar cron. Następnie następnym razem, gdy serwer utknie, powinienem być w stanie porównać częstość błędów strony, aby zobaczyć, który proces / procesy ma zwiększoną częstość błędów strony. Myślę, że mógłbym mieć pecha i zobaczyć wzrost dysku io dla wszystkich procesów podczas przeciągnięcia, ale zdecydowanie warto spróbować. Dzięki Janne! (oddałbym głos na twoją odpowiedź, gdybym mógł: S)
Avada Kedavra
Nie ma za co. Daj mi znać, jak poszło, to była tylko twórcza próba rozwiązania problemu ode mnie. :-)
Janne Pikkarainen,
Wyjście iotop jest łatwiejsze do interpretacji, więc źle akceptuję to rozwiązanie. Wrócę, aby zagłosować na twoją odpowiedź, gdy tylko zdobędę wystarczającą liczbę przedstawicieli, aby to zrobić. Dziękuję za wsparcie!
Avada Kedavra,