Как проверить использование дискового ввода-вывода для каждого процесса

У меня проблема с зависающей системой Linux, и я обнаружил, что sysstat / sar сообщает об огромных пиках в использовании дискового ввода-вывода, среднем времени обслуживания, а также среднем времени ожидания во время остановки системы.

Как я могу определить, какой процесс вызывает эти пики в следующий раз, когда это произойдет?
Возможно ли это сделать с помощью sar (то есть: могу ли я найти эту информацию из уже записанных файлов sar?

Вывод для "sar -d", системный сбой произошел около 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

Это дополнительный вопрос к теме, которую я начал вчера: внезапные пики в загрузке и ожидании блокировки диска , я надеюсь, что все в порядке, что я создал новую тему / вопрос по этому вопросу, так как я еще не смог решить проблему.

Если вам посчастливилось поймать следующий пиковый период использования, вы можете в интерактивном режиме изучить статистику ввода-вывода для каждого процесса, используя iotop .

С помощью этой команды вы можете использовать pidstat для вывода совокупной статистики io для процесса каждые 20 секунд:

# pidstat -dl 20

Каждый ряд будет иметь следующие столбцы:

• PID - идентификатор процесса
• kB_rd / s - количество килобайт, которое задание выполнило для чтения с диска в секунду.
• kB_wr / s - количество килобайт, вызванных задачей или должно быть записано на диск в секунду.
• kB_ccwr / s - количество килобайт, запись которых на диск была отменена задачей. Это может произойти, когда задача обрезает грязный кеш страниц. В этом случае некоторые операции ввода-вывода, для которых была учтена другая задача, не будут выполняться.
• Команда - Имя команды задачи.

Вывод выглядит так:

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]              

Ничто не сравнится с текущим мониторингом, вы просто не сможете получить чувствительные ко времени данные после события ...

Однако есть пара вещей, которые вы можете проверить, чтобы скрыть или устранить - /procэто ваш друг.

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

Поля 10, 11 являются накопленными записанными секторами и накопленным временем (мс) записи. Это покажет ваши горячие разделы файловой системы.

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

Эти поля представляют собой PID, команду и кумулятивный тик IO-wait. Это покажет ваши горячие процессы, хотя только если они все еще работают . (Вы, вероятно, хотите игнорировать потоки журналирования своей файловой системы.)

Полезность вышеизложенного зависит от времени безотказной работы, характера ваших долго выполняющихся процессов и от того, как используются ваши файловые системы.

Предостережения: не относится к ядрам до 2.6, проверьте вашу документацию, если не уверены.

(Теперь иди и сделай одолжение самому себе, установи Munin / Nagios / Cacti / что угодно ;-)

Использование atop. ( http://www.atoptool.nl/ )

Запишите данные в сжатый файл, который atopможно прочитать позже, в интерактивном стиле. Возьмите чтение (дельта) каждые 10 секунд. сделайте это 1080 раз (3 часа; поэтому, если вы забудете об этом, выходной файл не выгонит вас с диска):

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

После того, как плохая вещь случается снова:

(даже если он все еще работает в фоновом режиме, он просто добавляется каждые 10 секунд)

% atop -r historical_everything.atop

Так как вы сказали IO, я бы нажал 3 клавиши: тдд

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

Использование btrace. Это легко использовать, например btrace /dev/sda. Если команда недоступна, она, вероятно, доступна в пакете blktrace .

РЕДАКТИРОВАТЬ : Так как debugfs не включен в ядре, вы можете попробовать date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfили подобное. Ведение журнала ошибок страницы, конечно же, совсем не то же самое, что использование btrace, но если вам повезет, это МОЖЕТ дать вам подсказку о большинстве процессов, требующих большого количества диска. Я только что попробовал один из моих наиболее интенсивных серверов ввода-вывода, и список включал процессы, которые, как я знаю, потребляют много ввода-вывода.