サーバー負荷が高い-[jbd2 / md1-8] 99.99％IOを使用

先週、負荷が急上昇しています。これは通常、1日に1回または2回発生します。[jbd2 / md1-8]が99.99％のIOを使用していることをiotopから特定できました。高負荷時には、サーバーへの高トラフィックはありません。

サーバーの仕様は次のとおりです。

• AMD Opteron 8コア
• 16 GB RAM
• 2x2.000 GB 7.200 RPM HDDソフトウェアレイド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

これによりプロセス名/ IDが得られました-このプロセスのデバッグをさらに行った後（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です。