Высокая загрузка сервера - [jbd2 / md1-8] с использованием 99,99% IO

У меня был всплеск нагрузки за последнюю неделю. Это обычно происходит один или два раза в день. Мне удалось определить из iotop, что [jbd2 / md1-8] использует 99,99% ввода-вывода. В периоды высокой нагрузки отсутствует высокий трафик на сервер.

Спецификации сервера:

• AMD Opteron 8 ядро
• 16 ГБ ОЗУ
• 2x2.000 ГБ 7.200 об / мин HDD Software Raid 1
• Cloudlinux + Cpanel
• Mysql правильно настроен

Помимо шипов, нагрузка обычно составляет около 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

Во время проблемы с высоким IO.

Я не знаю cloudlinux, но есть ли в нем инструмент blktrace.