ドメインコントローラでの「ピーキー」なCPU使用率
2つのWindows Server 2008 SP2（残念ながら2008 R2ではない）ドメインコントローラーが、非常に「ピーク」のCPU使用率を示す小さな150クライアントドメインにあります。ドメインコントローラーはどちらも同じ動作を示し、vSphere 5.5.0、1331820でホストされます。2〜3秒ごとに、CPU使用率が80〜100％に跳ね上がり、すぐに低下し、1〜2秒間低いままで、その後跳ね上がります。再び。
仮想マシンのパフォーマンスデータの履歴を見ると、この状態が少なくとも1年間続いているが、頻度は3月以降増加していることがわかります。
問題のプロセスは、DHCPクライアント（dhcpcsvc.dll）、EventLog（wevtsvc.dll）、およびLMHOSTS（lmhsvc.dll）サービスをラップしているSVChost.exeです。私は確かにWindowsの内部専門家ではありませんが、ProcessLogでプロセスを表示するときに、EventLogが大量の RpcBindingUnbind 呼び出しをトリガーしているように見えること以外は、特に問題を見つけることができなかったようです。
この時点で、私はコーヒーもアイデアもありません。この問題のトラブルシューティングを続行するにはどうすればよいですか？
TL; DR：EventLogファイルがいっぱいでした。エントリの上書きは、コストがかかるか、Windows Server 2008に適切に実装されていない。
@ pk。 の提案と @ joeqwerty の提案で、質問したところ、忘れられていた監視の実装がイベントログをかき集めている可能性が高いと判断しました。
ドメインコントローラの1つに Microsoftのネットワークモニタ をインストールし、ProtocolName == MSRPCフィルタを使用してMSRPCのフィルタリングを開始しました。大量のトラフィックがありましたが、それはすべてリモートサイトのRODC間のトラフィックであり、残念ながら、リスニングするEventLogプロセスと同じ宛先ポートを使用していませんでした。くそー！その理論があります。
物事を単純化し、監視ソフトウェアを実行しやすくするために、EventLogサービスをSVCHostからアンラップすることにしました。次のコマンドとドメインコントローラーの再起動により、1つのSVCHostプロセスがEventLogサービス専用になります。このPIDに複数のサービスがアタッチされていないため、調査が少し簡単になります。
SC config EventLog Type= own
次に ProcMon に頼り、そのPIDを使用しなかったすべてのものを除外するフィルターを設定しました。考えられる原因として示されているように、欠落しているレジストリキーを開くためのEventLogによる試行の失敗が大量に見られませんでした here （どうやら安っぽいアプリケーションは Event Sources として登録できます） ）。予想通り、セキュリティイベントログ（C：\ Windows\System32\WinEvt\Logs\Security.evtx）の多くの成功したReadFileエントリが見つかりました。
これらのイベントの1つでスタックを見てみましょう。 
最初にRPCBinding、次にRPCBindingUnbindに気付くでしょう。これらのロットがありました。毎秒数千のように。セキュリティログが非常にビジーであるか、Security.evtxログで何かが正しく機能していません。
EventViewerでは、セキュリティログは1分あたり50〜100のイベントしかログに記録しませんでした。これは、このサイズのドメインに適しているように思われました。くそー！理論2は、忘れられたコーナーで左に非常に詳細なイベント監査がオンになっているいくつかのアプリケーションがまだ忠実に離れているということです。ログに記録されるイベントの割合が低いにもかかわらず、記録されたイベントはまだ多く（約250,000）ありました。おそらくログサイズ？
セキュリティログ-（右クリック）-プロパティ...そして最大ログサイズは131,072 KBに設定され、ログサイズは現在131,072 KBで保持されていました。 [必要に応じてイベントを上書きする]ラジオボタンがオンになりました。ログファイルを絶えず削除して書き込むのはおそらく大変な作業なので、ログをクリアすることを選択し（後で監査するために古いログを保存しておく必要がある場合に備えて保存しました）、EventLogサービスを作成しました新しい空のファイル。その結果、CPU使用率は約5％の正常なレベルに戻りました。
小さなデータコレクターセットを作成することで、これを追跡できる場合があります。
- パフォーマンスモニターを開き、新しいユーザー定義のデータコレクターセットを作成します。
- Manual（テンプレートなし）を選択し、Event trace dataのみを選択します。
- Active Directory Domain Service：Coreデータを追加して、セットを保存します。
- PropertiesのStop Conditionを1分に変更します。
- セットを開始して待ちます。
- 完了したら、
tracerpt –l “file.etl” –of CSVを使用して、保存された。etlファイルを。csvに変換します - Excelでsummary.csvおよびdumpfile.csvデータを分析します。この Import-DC-Info.xlsm ドキュメントをダウンロードして、分析に役立てることができます。
私の直感が正しければ、いくつかのデバイス（IP：ポート）がDCをハンマーしているのがわかります。
確かに難しい。そのままにしておくこと（1 CPU/50％の負荷..気にしないのか）は別として、新しいドメインコントローラーをセットアップして、数日後にこれが同じ動作をするかどうかを確認できます。もしそうなら、Wiresharkトレースを試してみることをお勧めします（明らかに、ネットワークから何かがこれを引き起こしています）
次に頭に浮かぶのは、Microsoftへの単純な呼び出しです