web-dev-qa-db-ja.com

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

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

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

  • AMD Opteron 8コア
  • 16 GB RAM
  • 2x2.000 GB 7.200 RPM HDDソフトウェア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]
linuxsoftware-raidhigh-load
12
Alex

正確な原因を示すのに十分なコンテキストがないので、これは実際には答えではありませんが、それが私に起こったときにこれを追跡する方法を説明したものです。

_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_で）有効にしたオプションがいくつかあると思います-そうしない場合それを有効にする方法の詳細については、インターネットを見回す必要はありません。

18
Iwan Aucamp

これは、ジャーナルの更新に関連するもののようです。ソフトウェアRAIDで構成されるディスクの数。作成に使用したコマンドを見せてください。

また、dumpe2fsの出力をPastebinできますか。まず、負荷がかかる物理デバイスを特定します。これを知るにはdfを使用してください。そして、

dumpe2fs /dev/sdaX > /tmp/dump

あなたの場合、それは/ dev/md0かもしれません。

また、これを実行します。

iostat -xdk 1 25

最高の時にIO問題。

私はcloudlinuxを知りませんが、その下で使用できるツールblktraceです。

1
Soham Chakraborty