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


45

У меня проблема с зависающей системой 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

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


Похоже, что проблема может быть не в особом процессе, а скорее в спорадически не отвечающем диске. Диски делают такие вещи, которые на системном уровне кажутся обрывами, которые ударила система. Если вы не нашли виновных, то пришло время исследовать дисковую подсистему.
slashdot



Использование htop serverfault.com/a/25034/373867
qwr

Ответы:


47

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


Эй спасибо Еще одна чудовищная игрушка для хранения в моем наборе инструментов. :-)
Янне Пиккарайнен

Запуск iotop в пакетном режиме может быть очень хорошим дополнением / заменой для решения "ps -eo", описанного выше. Спасибо!
Авада Кедавра

2
Круто, "iotop -n 1 -b -o" обеспечивает именно тот вывод, который мне нужен. Спасибо!
Авада Кедавра

Похоже, что для запуска требуется root-доступ к системе
user5359531

30

С помощью этой команды вы можете использовать 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]              

10

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

Однако есть пара вещей, которые вы можете проверить, чтобы скрыть или устранить - /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 / что угодно ;-)


10

Использование 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

5

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

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


Здравствуйте, Janne, ядро, к сожалению, не скомпилировано с файловой системой отладки, и это живая система, поэтому я не могу перекомпилировать ядро. Есть ли другой способ сделать это без перекомпиляции?
Авада Кедавра

Хорошо, я немного отредактировал свой ответ :)
Janne Pikkarainen

Отлично, теперь мы куда-то добираемся! Я подумываю о том, чтобы поместить это в cronjob и выполнить одновременно с заданием sar cron. Затем в следующий раз, когда сервер остановится, я смогу сравнить частоту отказов страниц, чтобы увидеть, какой процесс / процессы имеют повышенную частоту отказов страниц. Я полагаю, что мне может не повезти, и я вижу повышение скорости диска для всех процессов во время остановки, но это определенно стоит попробовать. Спасибо Янне! (я бы проголосовал за ваш ответ, если бы мог: S)
Авада Кедавра

Пожалуйста. Дайте мне знать, как все прошло, это была просто творческая попытка решения проблемы с моей стороны. :-)
Янне Пиккарайнен

Выходные данные iotop легче интерпретировать, поэтому я приму это решение. Я вернусь, чтобы проголосовать за ваш ответ, как только я заработаю достаточно репутации, чтобы сделать это. Спасибо за поддержку!
Авада Кедавра
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.