☰

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

tag-icon • tag-icon linux storage io
Как проверить использование дискового ввода-вывода по процессам?

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

У меня также есть вопрос в продолжение другой темы, которую я начал вчера:

решение1

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

решение2

Вы можете использоватьпидстатдля вывода совокупной статистики ввода-вывода для каждого процесса каждые 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]

решение3

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

Есть пара вещей, которые вымощьбыть в состоянии проверить, чтобы вовлечь или устранить однако — /procваш друг.

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

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

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

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

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

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

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

решение4

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

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

Связанный контент