ドメインコントローラーでの「ピーク」CPU使用率

非常に「ピーク」CPU使用率を示している小さな150クライアントドメインに2つのWindows Server 2008 SP2（残念ながら2008 R2ではありません）ドメインコントローラーがあります。ドメインコントローラーは両方とも同じ動作を示し、vSphere 5.5.0、1331820でホストされます。CPU使用率は2〜3秒ごとに80〜100％に跳ね上がり、その後すぐに低下し、1〜2秒間低くなってから跳ね上がります再び。

仮想マシンの過去のパフォーマンスデータを見ると、この状態が少なくとも1年間続いているが、3月以降は頻度が増えていることがわかります。

問題のあるプロセスは、DHCPクライアント（dhcpcsvc.dll）、EventLog（wevtsvc.dll）、およびLMHOSTS（lmhsvc.dll）サービスをラップしているSVChost.exeです。私は確かにWindowsの内部専門家ではありませんが、ProcessLog Explorerでプロセスを表示すると、EventLogが大量のRpcBindingUnbind呼び出しをトリガーしているように見える以外、特におかしなものを見つけることができませんでした。

この時点で、私はコーヒーとアイデアがなくなっています。この問題のトラブルシューティングを続行するにはどうすればよいですか？

TL; DR：EventLogファイルがいっぱいでした。エントリの上書きは高価であるか、Windows Server 2008での実装があまり適切ではありません。

で@pk。と@joeqwertyの提案を聞いた後、忘れられていた監視の実装がイベントログをスクレイピングしている可能性が最も高いと判断しました。

ドメインコントローラーの1つにMicrosoftのネットワークモニターをインストールし、ProtocolName == MSRPCフィルターを使用してMSRPCのフィルター処理を開始しました。多くのトラフィックがありましたが、それはすべてリモートサイトのRODCの間であり、残念ながらリスニングEventLogプロセスと同じ宛先ポートを使用しませんでした。くそー！その理論があります。

物事を単純化し、監視ソフトウェアを実行しやすくするために、SVCHostからEventLogサービスを展開することにしました。次のコマンドとドメインコントローラーの再起動は、1つのSVCHostプロセスをEventLogサービス専用にします。このPIDに複数のサービスが接続されていないため、これにより調査が少し簡単になります。

SC config EventLog Type= own

次に、ProcMonを使用して、そのPIDを使用しなかったすべてのものを除外するフィルターを設定しました。ここで考えられる原因として示されているように、EventLogが欠落しているレジストリキーを開こうとする試みに失敗することは多くありませんでした（明らかに、クラッピーなアプリケーションは非常に悪い方法でイベントソースとして登録できます）。予想通り、セキュリティイベントログ（C：\ Windows \ System32 \ WinEvt \ Logs \ Security.evtx）の多くの成功したReadFileエントリを見ました。

これらのイベントの1つのスタックを以下に示します。

最初にRPCBinding、次にRPCBindingUnbindに気付くでしょう。これらはたくさんありました。毎秒数千のように。セキュリティログが非常にビジーであるか、Security.evtxログで何かが正しく機能していません。

EventViewerでは、セキュリティログは1分あたり50〜100個のイベントのみを記録していましたが、これはこのサイズのドメインに適していると思われました。くそー！理論番号2には、忘れられた隅で非常に詳細なイベント監査が有効になっているアプリケーションがありましたが、まだ忠実に追い払われています。ログに記録されるイベントの割合が低くても、まだ多くのイベント（〜250,000）が記録されていました。おそらくログサイズ？

セキュリティログ-（右クリック）-プロパティ... 「必要に応じてイベントを上書きする」ラジオボタンがチェックされました。ログファイルを絶えず削除して書き込むことは、特に満杯の場合はおそらく大変な作業であると考えたため、ログをクリアすることを選択しました（後で監査する必要がある場合に備えて古いログを保存しました）。新しい空のファイル。その結果、CPU使用率は約5％の健全なレベルに戻りました。

小さなデータコレクターセットを作成することで、これを追跡できる場合があります。

• パフォーマンスモニターを開き、新しいユーザー定義のデータコレクターセットを作成します。
• 選択してくださいマニュアル（テンプレートなし）を選択し、イベントトレースデータのみを。
• Active Directoryドメインサービス：コアデータを追加し、セットを保存します。
• 変更停止条件の下で、プロパティを 1分に。
• セットを開始して待機します。
• 完了したら、保存した.etlファイルを使用して.csvに変換しますtracerpt –l “file.etl” –of CSV
• Excelでsummary.csvおよびdumpfile.csvデータを分析します。このImport-DC-Info.xlsmドキュメントをダウンロードして、分析に役立ててください。

私の考えが正しければ、いくつかのデバイス（IP：port）がDCを叩いているのを見るでしょう。

確かに難しいものです。そのままにしておく（1 CPU / 50％負荷..誰が気にする？）以外に、新しいドメインコントローラーをセットアップして、このコントローラーが同じ動作をするかどうかを数日後に確認することができます。もしそうなら、あなたはWiresharkトレースを試してみたいと思うかもしれません（明らかに、それを引き起こすネットワークから何かがあります）

次に頭に浮かぶのは、Microsoftへの単純な呼び出しです

トラビス、「アーカイブ」はあなたを助けませんでした。実際、2/3に成長したときにイベントログをクリアしても、役に立ちませんでした。しかし、「アーカイブ」はKraigMに役立ちました。

kce：131MBの「上書き」ファイルをクリアし、パフォーマンスが約55％から5％低下したのを確認しましたが、質問：おそらく、（a）上書き条件に達した場合にのみトリガーされるため、最終的に高使用率が再び表示されました。クリアされたファイルのサイズが0 MBから131 MBに増加すると、線形的に悪化する場合があります。

security.evtxでこれを見る人もいれば、タスクスケジューラの操作ログで見る人もいます。AV（使用しているAV）を完全にアンインストールして、試してみることをお勧めします。侵入者はトラックを非表示にする必要があり、トラックは設定したスケジュール済みタスクまたはログインで作成されます。そのため、これらのイベントログへのハンドルを壊し、トラックをスキップするように書き直すことで、トラックを隠します。マイクロソフトの場合、この高い使用率の多くが報告されていたはずですが、グーグルでいくつかの投稿を見ているので、AVはバグの多い方法でこれを検出する可能性があります。security.evtxログのサーバー2008 R2でもこれを見ています。イベントログサブスクライバー、外部モニターはありません。いくつかのAVサービス（McAfee）が実行されているのを観察しましたが、サーバーの総使用率が非常に低いため、アンインストールされたのは部分的にしかなかったと思われ（おそらくMcAfeeの特別なアンインストーラーが必要です）、フックがあるかどうか疑問に思います痕跡（または通常インストールされている）McAfeeサービスまたは実行中のMcAfeeフィルタードライバーは、何らかの形でイベントログに通常の書き込みを行い、フィルター処理で、これをイベントログ全体の完全な読み取りに変換する必要があると判断します。信頼してください。一部のAV企業のサードパーティのフィルタードライバーはバグが多く、Microsoftのイベントログの実装よりも10000倍もバグが多く、おそらく完璧です。要約すると、すべてのAVをアンインストールし、問題が解決した場合は参照してください。その場合は、AV会社と協力してAVを修正します。のファイル例外を作成することはお勧めできません。

また、procmonを使用する場合は、WriteFileがフィルターマネージャーをトリガーしてファイル全体を読み取るため、WriteFile呼び出しに注意してください。私の場合、読み取りは書き込みが完了してから約30秒後に開始されましたが、これは仕様による可能性があります。しかし、それは一貫性があり、私の場合、ファイルは4GBで、ファイルの読み取りには各64KBの長さの64Kの読み取りファイルが含まれ、これを達成するためにCPUの35％を使用しました。とても悲しい。

更新2016年3月23日このマシンのフィルタードライバーを調べたのは、これらのいずれかが原因であると判断したためです（イベントログメカニズム自体がバグになることはないか、この種のレポートの数は膨大で、そうではない）。先読みで仮想マシンのディスクパフォ​​ーマンスを向上させるAVおよび有名なサードパーティのフィルタードライバーをいくつか見て、チーフアーキテクト（非常に親切で親切な）に彼の製品が全体を過度に読んでいるかどうかを尋ねましたセキュリティイベントログ（procmonごとに明らかに発生していました）。これは、セキュリティログが小さい場合に役立ちますが、ここで報告されているサイズのものには役立ちません。まさか彼は言った。彼はそれがAVかもしれないことに同意した。

以下のAzureフェローに述べたように、イベントログをクリアした後に問題が再び表面化した場合、元のポスターからのフォローアップはありません。これは「フォローアップ」と呼ばれ、元のポスターの解決策は、フォローアップしていない人が問題を解決したと信じ込ませることができると思います。私もだまされそうになりました。イベントログをクリアし、パフォーマンスを改善しましたが、procmonを使用しましたが、問題が発生するまで、時間の経過とともに問題が大きくなり、ゆっくりと大きくなっていきました。何らかの理由で、Azureの仲間は、元のポスターがフォローアップしなかった（死んだ、解雇された、辞めた、または忙しくなった）可能性があると厳しく批判しています。以下のAzureフェローは、元のポスターがフォローアップしなかった場合、修正された問題であるに違いないと考えています。技術的に非常に高く評価され、この地位に就く人は誰も思いつかないので、これは厄介で不可解です。神経を刺した場合は謝罪します。おそらく、インターネット上の他の場所で人々を呼びかける私の活動では、彼の神経質になりました-ここ（serverfault）私は単に親切であり、深い技術知識を共有しています.Azure氏からの結果は、私の技術的な貢献が必要か、私のブログの一部です（そのようなブログはありません）。私はこのリンクをマイクロソフトの約半ダースのキーcroniesに送信するつもりはなく、MSFTの主要な従業員からのこの種のいじめで何が起こっているのかを尋ねるつもりです。念頭に置いたコミュニティと、Azure氏からの以下の回答は、一言で言えば、信じられないほど、愛国心が強い、不安といじめ-一部の人々は他の人に楽しんでいると確信しています。私は最初は気分を害しましたが、受動的または能動的な読者は私が言っていることに感謝し、私のコメントに感謝することを知っています-私はそれがここで微妙に不適切であるかどうかの法的理由を考慮せずに100％支持しています。M. Azure、優しさを実践し、私のコメントを下手にキャストしないでください。それを乗り越えて抑制を示し、再びコメントしないでください。優しさを実践し、私のコメントを粗末に投げることは控えてください。それを乗り越えて抑制を示し、再びコメントしないでください。優しさを実践し、私のコメントを粗末に投げることは控えてください。それを乗り越えて抑制を示し、再びコメントしないでください。

ハリー