none
SystemプロセスによってCPU使用率が80%以上になる事象について RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    お世話になります。

    Windows Storage Server 2012 R2のファイルサーバ(SMB)でCPU使用率が80％以上になっている事象が起きています。
    ファイルサーバは、Office系のデータを格納しています。
    事象は、ユーザが使用した場合に発生し、ユーザが使用しない場合は発生しないことは判明しています。
    この事象の影響として、ファイル操作が重く、場合によってはファイルサーバ自身がフリーズすることもありました。

    ファイルサーバ構成は以下の通りです。
    　・CPU　　：　Intel Atom Processor 2.13GHz （Dual Core）
    　・メモリ ：　4GB

    タスクマネージャとProcess Explorerで調査したところ、下記のことがわかっています。
    　・PID4の「System」プロセスがCPU使用率を80％使用している
    　・「System」プロセスのスレッドを見ると「ntoskrnl.exe!KeRemoveQueue+0x488」が大量にある

    私のほうでいろいろ調べているのですが、
    わからないことがあり、以下についてご助言いだたけますでしょうか。
    ①「KeRemoveQueue+0x488」が何をするものか教えてください。
    　Microsoftより、以下情報が出ていますが、どういったとき(ファイルを開いたときなのか、削除するときなのか)
    　に使うものかわからないが現状です。
    　https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-keremovequeue

    ②CPU使用率の上昇を抑止するために方法はありますでしょうか。
    　できれば、今のサーバを使用したく、できる限りの対処はしたいです。


    なにとぞ宜しくお願い致します。

    2018年9月3日 2:54
    |

回答

  • Question
    サインインして投票
    4
    サインインして投票

    ①
    その KeRemoveQueue のコールスタックには、SMB ドライバ (srv, srv2) が介在しているのでしょうか？
    もし SMB ドライバが介在しているなら、SMB 経由での File Access Request が System Worker Queue に Post され、それら処理が滞留しているんだと思います。
    私の知る限り、SMB v1,v2 (srv.sys, srv2.sys) 経由での File Access Request は System Worker Queue に Post され、System Worker Thread で処理されるはずです。
    この時、キューイングされた Work Item がキューから取り出されて Worker Thread で実行されるまでの間、つまり Dispatcher Object がシグナル状態になるまで、KeRemoveQueue で待たされることになります。
    ここら辺の挙動については、これ↓が参考になるかも。
    ----------------------------------------
    Work Queues and Dispatcher Headers
    https://blogs.msdn.microsoft.com/ntdebugging/2008/05/07/work-queues-and-dispatcher-headers/
    ----------------------------------------

    ②
    コールスタックに SMB ドライバが介在しているのであれば、SMB 経由での File I/O で deadlock 状態に陥っているのかも。
    この場合真っ先に考えられるのは、File System Filter Driver 間での整合性の問題です。
    問題が起きている Server に、複数の 3rd ベンダー製 File System Filter Driver がインストールされている場合、それら Filter Driver 間での整合性に起因して、今回のような問題を引き起こす可能性が考えられます。
    とりあえず、Windows Update を実施しシステムを最新の状態に更新した上で、使用しているセキュリティソフトも最新状態に更新して問題現象が改善されないか、確認されることをお勧めします。
    それでも改善されない場合は、fltmc コマンドで怪しい Filter Driver が介在しないか確認するとか、あるいは別のセキュリティソフト置き換えてどーなるか検証するとか。
    もっとも KeRemoveQueue のコールスタックに SMB ドライバが介在していないなら、File I/O 以外の別要因の可能性も考えられる。。。。ということになりますけど。

    • 回答としてマーク kkk-haruku 2018年9月10日 4:31
    2018年9月4日 2:10
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ①
    問題現象発生時の完全メモリ ダンプを採取して、それを解析する。

    ②
    そうです。
    ただし、私がその状態を直接調べたわけではないので、単なる可能性のお話です。

    先に提示した Blog にもコールスタックが提示されていますが、SMB アクセスの場合黒字のようなスタック フレームが介在してくるはずです。
    ------------------------------------------
    Priority 9 BasePriority 9 PriorityDecrement 0
     Child-SP          RetAddr           Call Site
     fffffadc`b053dab0 fffff800`01027752 nt!KiSwapContext+0x85
     fffffadc`b053dc30 fffff800`01024ef0 nt!KiSwapThread+0x3c9    ← Waits on the dispatcher object
     fffffadc`b053dc90 fffffadc`b9a380b0 nt!KeRemoveQueue+0x656
     fffffadc`b053dd10 fffff800`0124b972 srv!WorkerThread+0xb0
     fffffadc`b053dd70 fffff800`010202d6 nt!PspSystemThreadStartup+0x3e
     fffffadc`b053ddd0 00000000`00000000 nt!KxStartSystemThread+0x16
    ------------------------------------------

    • 回答としてマーク kkk-haruku 2018年9月19日 5:35
    2018年9月10日 5:58
    |

すべての返信

  • Question
    サインインして投票
    4
    サインインして投票

    ①
    その KeRemoveQueue のコールスタックには、SMB ドライバ (srv, srv2) が介在しているのでしょうか？
    もし SMB ドライバが介在しているなら、SMB 経由での File Access Request が System Worker Queue に Post され、それら処理が滞留しているんだと思います。
    私の知る限り、SMB v1,v2 (srv.sys, srv2.sys) 経由での File Access Request は System Worker Queue に Post され、System Worker Thread で処理されるはずです。
    この時、キューイングされた Work Item がキューから取り出されて Worker Thread で実行されるまでの間、つまり Dispatcher Object がシグナル状態になるまで、KeRemoveQueue で待たされることになります。
    ここら辺の挙動については、これ↓が参考になるかも。
    ----------------------------------------
    Work Queues and Dispatcher Headers
    https://blogs.msdn.microsoft.com/ntdebugging/2008/05/07/work-queues-and-dispatcher-headers/
    ----------------------------------------

    ②
    コールスタックに SMB ドライバが介在しているのであれば、SMB 経由での File I/O で deadlock 状態に陥っているのかも。
    この場合真っ先に考えられるのは、File System Filter Driver 間での整合性の問題です。
    問題が起きている Server に、複数の 3rd ベンダー製 File System Filter Driver がインストールされている場合、それら Filter Driver 間での整合性に起因して、今回のような問題を引き起こす可能性が考えられます。
    とりあえず、Windows Update を実施しシステムを最新の状態に更新した上で、使用しているセキュリティソフトも最新状態に更新して問題現象が改善されないか、確認されることをお勧めします。
    それでも改善されない場合は、fltmc コマンドで怪しい Filter Driver が介在しないか確認するとか、あるいは別のセキュリティソフト置き換えてどーなるか検証するとか。
    もっとも KeRemoveQueue のコールスタックに SMB ドライバが介在していないなら、File I/O 以外の別要因の可能性も考えられる。。。。ということになりますけど。

    • 回答としてマーク kkk-haruku 2018年9月10日 4:31
    2018年9月4日 2:10
    |
  • Question
    サインインして投票
    0
    サインインして投票

    回答ありがとうございます。


    ①Process Explorerで対象スレッドのスタックを確認したのですが、「Unable to access tread」エラーが出力され、

    　SMB ドライバ (srv, srv2) が介在しているか不明です。

    　KeRemoveQueue のコールスタックを確認する方法をご存じであれば、教えていただけますでしょうか。

    　※ファイルサーバの機能は、Windows標準のファイル共有を使っています。


    ②「 SMB ドライバが介在しているのであれば、SMB 経由での File I/O で deadlock 状態に陥っているのかも」とは、

    　ユーザからのSMB経由でのファイルの入出力処理で、スレッドが互いの処理の完了を待機しあうということでしょうか。

    　

    私の知識が追いつけておらず、大変申し訳ありませんが、ご助言のほど宜しくお願い致します。

    　



    2018年9月10日 4:28
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ①
    問題現象発生時の完全メモリ ダンプを採取して、それを解析する。

    ②
    そうです。
    ただし、私がその状態を直接調べたわけではないので、単なる可能性のお話です。

    先に提示した Blog にもコールスタックが提示されていますが、SMB アクセスの場合黒字のようなスタック フレームが介在してくるはずです。
    ------------------------------------------
    Priority 9 BasePriority 9 PriorityDecrement 0
     Child-SP          RetAddr           Call Site
     fffffadc`b053dab0 fffff800`01027752 nt!KiSwapContext+0x85
     fffffadc`b053dc30 fffff800`01024ef0 nt!KiSwapThread+0x3c9    ← Waits on the dispatcher object
     fffffadc`b053dc90 fffffadc`b9a380b0 nt!KeRemoveQueue+0x656
     fffffadc`b053dd10 fffff800`0124b972 srv!WorkerThread+0xb0
     fffffadc`b053dd70 fffff800`010202d6 nt!PspSystemThreadStartup+0x3e
     fffffadc`b053ddd0 00000000`00000000 nt!KxStartSystemThread+0x16
    ------------------------------------------

    • 回答としてマーク kkk-haruku 2018年9月19日 5:35
    2018年9月10日 5:58
    |