На прошлой неделе у меня был всплеск нагрузки. Обычно это происходит один или два раза в день. Мне удалось определить по iotop, что [jbd2 / md1-8] использует 99,99% ввода-вывода. Во время высокой нагрузки на сервер отсутствует высокий трафик.
Характеристики сервера:
Не считая шипов, нагрузка обычно составляет максимум 0,80.
Я поискал, но не нашел, что именно делает [jbd2 / md1-8]. У кого-нибудь была такая проблема или кто-нибудь знает возможное решение?
Спасибо.
ОБНОВИТЬ:
TIME TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
16:05:36 399 be/3 root 0.00 B/s 38.76 K/s 0.00 % 99.99 % [jbd2/md1-8]
На самом деле это не ответ, поскольку не хватает контекста, чтобы указать точную причину, но это описание того, как мне удалось отследить это, когда это случилось со мной.
Я заметил свой jbd2/md0-8 продолжал появляться на вершине iotop. Я заглянул в /sys/kernel/debug/tracing/events/jbd2 чтобы увидеть, какие есть варианты, чтобы определить, что jbd2 делал.
ПРИМЕЧАНИЕ-1: Чтобы просмотреть выходные данные для событий трассировки отладки cat /sys/kernel/debug/tracing/trace_pipe - У меня это работало в терминале при включении / отключении трассировки.
ПРИМЕЧАНИЕ-2: Чтобы включить события для отслеживания, используйте, например, echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Отключить echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.
Я начал с включения /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable - но ничего особенно интересного в его выходе не было. Я пробовал отслеживать несколько других событий, и когда я включил /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable Я видел, как это происходило каждую секунду:
# cat /sys/kernel/debug/tracing/trace_pipe
...
jbd2/md0-8-2520 [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0
jbd2/md0-8-2520 [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0
jbd2/md0-8-2520 [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0
Похоже, это было связано с sync(2)/fsync(2)/msync(2), поэтому я искал способ связать это с процессом и нашел следующее:
# find /sys/kernel/debug/tracing/events/ | grep sync.*enable
...
/sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
...
Когда я включил его, я увидел следующий результат:
# cat /sys/kernel/debug/tracing/trace_pipe
...
nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1
jbd2/md0-8-2520 [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0
nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1
jbd2/md0-8-2520 [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0
nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1
jbd2/md0-8-2520 [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0
nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1
jbd2/md0-8-2520 [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0
Это дало мне имя / идентификатор процесса - и после дополнительной отладки этого процесса (nzbget) Я обнаружил, что это делает fsync(2) каждую секунду. После того, как я изменил его конфигурацию (FlushQueue=no, недокументированный, я думаю, нашел его в источнике), чтобы он не делал это в секунду fsync(2) проблема ушла.
Моя версия ядра 4.4.6-gentooЯ думаю, что я включил некоторые параметры (вручную или с помощью make oldconfig) в какой-то момент конфигурации ядра, чтобы получить /sys/kernel/debug с этими событиями - так что, если у вас его нет, возможно, просто поищите в Интернете дополнительную информацию о том, как его включить.
Кажется, это связано с обновлением журнала. Из скольких дисков состоит программный RAID. Вы можете показать мне команду, использованную для его создания.
Можете ли вы также вставить вывод dumpe2fs. Сначала определите физическое устройство, на котором вы видите нагрузку. Используйте df, чтобы узнать это. Затем,
dumpe2fs /dev/sdaX > /tmp/dump
В вашем случае это может быть / dev / md0.
Также запустите это.
iostat -xdk 1 25
Во время высокой проблемы ввода-вывода.
Я не знаю cloudlinux, но есть ли в нем инструмент blktrace.