Як перевірити використання вводу / виводу диска за процес

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

Як я міг би визначити, який процес викликає ці піки наступного разу?
Чи можливо це зробити з sar (тобто: чи можу я знайти цю інформацію з файлів sar, записаних у alreade?

Вихід для "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, перевірте свою документацію, якщо не впевнені.

.

Використовуйте 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 клавіші: 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

Використовуйте btrace. Це просте у використанні, наприклад btrace /dev/sda. Якщо команда недоступна, вона, ймовірно, доступна в пакеті blktrace .

EDIT : Оскільки налагодження не включено в ядрі, ви можете спробувати date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfабо подібне. Зрозуміння помилок сторінки - це, звичайно, не те саме, що використання btrace, але якщо вам пощастить, МОЖЕ дати вам підказку про найбільш голодні на диску процеси. Я просто спробував, що один з моїх найбільш інтенсивних серверів вводу / виводу та список включав процеси, які я знаю, що споживають багато вводу-виводу.