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