Jak sprawdzić wykorzystanie dysku we / wy na proces

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.

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 .

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]              

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 ;-)

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

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.