我们在一个包含 150 个客户端的小型域中有两个 Windows Server 2008 SP2（遗憾的是不是 2008 R2）域控制器，它们的 CPU 使用率非常“高”。这两个域控制器都表现出相同的行为，并且托管在 vSphere 5.5.0，1331820 上。每隔两三秒，CPU 使用率就会跃升至 80-100%，然后迅速下降，保持一两秒的低位，然后再次跃升。
查看虚拟机的历史性能数据表明，这种情况已经持续了至少一年，但自三月份以来频率有所增加。
有问题的进程是 SVChost.exe，它包装了 DHCP 客户端 (dhcpcsvc.dll)、EventLog (wevtsvc.dll) 和 LMHOSTS (lmhsvc.dll) 服务。我当然不是 Windows 内部专家，但在使用 Process Explorer 查看进程时，我似乎没有发现任何特别不对劲的地方，只是 EventLog 似乎触发了大量解除绑定呼叫。
到现在为止，我已经没有咖啡和想法了。我应该如何继续解决此问题？
答案1
TL;DR：EventLog 文件已满。在 Windows Server 2008 中，覆盖条目的成本很高，并且/或者实现得不是很好。
在@pk。和@joeqwerty建议并询问了周围的人之后，我认为最有可能的是被遗忘的监控实现正在抓取事件日志。
我安装了微软的网络监视器在其中一个域控制器上，并开始使用过滤器过滤 MSRPC ProtocolName == MSRPC。有很多流量，但都是在我们远程站点的 RODC 之间，不幸的是，它们没有使用与监听 EventLog 进程相同的目标端口。该死！这个理论不成立。
为了简化操作并更轻松地运行监控软件，我决定从 SVCHost 中解开 EventLog 服务。以下命令和域控制器的重新启动将一个 SVCHost 进程专用于 EventLog 服务。由于您没有将多个服务附加到该 PID，因此这使调查变得更容易一些。
SC config EventLog Type= own
然后我诉诸进程监控并设置一个过滤器以排除所有未使用该 PID 的程序。我没有看到 EventLog 尝试打开丢失的注册表项失败的次数，这可能是原因这里（显然糟糕的应用程序可以注册为事件源以极其糟糕的方式）。不出所料，我看到安全事件日志 (C:\Windows\System32\WinEvt\Logs\Security.evtx) 中有很多成功的 ReadFile 条目。
以下是其中一个事件的堆栈：
您会首先注意到 RPCBinding，然后是 RPCBindingUnbind。很多这些。每秒大概几千个。要么是安全日志真的很忙，要么是日志出了问题Security.evtx。
在 EventViewer 中，安全日志每分钟仅记录 50-100 个事件，这对于这种规模的域来说似乎很合适。该死！第二个理论是，我们在一个被遗忘的角落里打开了一些非常详细的事件审计的应用程序，它们仍在尽职尽责地运行。尽管记录事件的速率很低，但仍然记录了大量事件（约 250,000 个）。也许是日志大小？
安全日志 - （右键单击） - 属性... 最大日志大小设置为 131,072 KB，当前日志大小为 131,072 KB。选中“根据需要覆盖事件”单选按钮。我认为不断删除和写入日志文件可能很费劲，尤其是在日志文件已满的情况下，所以我选择清除日志（我保存了旧日志以防我们以后需要它进行审计）并让 EventLog 服务创建一个新的空文件。结果：CPU 使用率恢复到 5% 左右的正常水平。
答案2
您可以通过创建一个小型数据收集器集来追踪此问题。
- 打开性能监视器并创建一个新的用户定义的数据收集器集。
- 选择手动的（无模板）并选择事件跟踪数据仅有的。
- 添加Active Directory 域服务：核心数据并保存该集合。
- 更改停止条件在下面特性至 1 分钟。
- 启动设置并等待。
- 完成后，转换保存的.etl文件到.csv使用
tracerpt –l “file.etl” –of CSV - 分析摘要.csv和转储文件Excel 中的数据。您可能想要下载此导入-DC-信息.xlsmdoc来帮助您进行分析。
如果我的预感正确，您将会看到一些设备（IP：端口）正在攻击您的 DC。
答案3
当然很难。除了让它保持原样（1 CPU / 50% 负载……谁在乎？），您可以尝试设置一个新的域控制器，并在几天后查看它是否给您相同的行为。如果是，您可能需要尝试使用 Wireshark 跟踪（显然，这是网络的某些原因造成的）
我想到的下一个办法是给微软打个电话
答案4
Travis，“存档”对你没用。事实上，即使事件日志已经增长了 2/3，清除它也没用。但“存档”对 KraigM 有帮助。
kce：清除了一个 131MB 的“覆盖”文件，发现性能从 55% 下降到了 5%，但问题是：也许你最终会再次看到高利用率，因为这可能 (a) 仅在达到覆盖条件时才会触发，或者 (b) 随着清除的文件大小从 0mb 增加到 131MB，情况可能会呈线性恶化。
一些人在 security.evtx 中看到了这一点，还有人认为这是任务计划程序操作日志中的问题。我建议完全卸载 AV（您正在使用哪一个）并尝试。入侵者需要隐藏他们的踪迹，他们的踪迹是在他们设置的计划任务或登录时留下的。因此，他们将通过破坏这些事件日志的句柄并重写它们以跳过他们的踪迹来隐藏他们的踪迹。AV 可能以一种有缺陷的方式检测到这一点，因为如果是微软，会报告更多这种高利用率，但我在谷歌搜索时只看到少数几篇帖子。我也在 server 2008 R2 的 security.evtx 日志中看到了这一点。没有事件日志订阅者，没有外部监视器。我观察到几个 AV 服务（McAfee）正在运行，对于运行了这么多天的服务器来说，它们的总利用率非常低，所以我怀疑它被卸载了，而且只是部分卸载（可能需要 McAfee 的特殊卸载程序），我想知道残留的（甚至是正常安装的）McAfee 服务或正在运行的 McAfee 过滤驱动程序中是否存在钩子，它们会以某种方式正常写入事件日志，并在过滤中决定需要将其转变为对整个事件日志的完整读取。相信我，一些 AV 公司提供的第三方过滤驱动程序存在错误，而且肯定比微软的事件日志记录实现的错误多 10000 倍，而微软的事件日志记录实现很可能是完美的。总之，100% 卸载所有 AV，看看问题是否解决。如果是这样，请与您的 AV 公司合作修复他们的 AV。对 .EVTX 文件设置文件例外是不明智的，因为您可能会失去这种入侵检测，相信我，这对坏人来说很重要。
此外，使用 procmon 时，请注意 WriteFile 调用，因为 Writefile 将触发筛选器管理器读取整个文件。在我的例子中，读取是在写入完成后大约 30 秒启动的，这可能是设计使然。但它是一致的，在我的例子中，文件为 4GB，文件读取涉及 64K Readfiles，每个 Readfiles 长度为 64KB，它利用了 35% 的 CPU 来完成此操作。非常遗憾。
更新 2016 年 3 月 23 日 我查看了这台机器上的过滤驱动程序，得出结论认为这一定是由其中一个驱动程序引起的（事件日志机制本身不可能有缺陷，否则这种报告的数量会非常惊人，但事实并非如此）。我看到了一些来自 AV 和一家知名第三方公司的过滤驱动程序，这些公司通过前瞻读取来提高虚拟机磁盘性能，并询问他们的首席架构师（他非常善良和宽容）他的产品是否会过度读取整个安全事件日志（这显然是每个 procmon 都在发生的）。这对较小的安全日志有帮助，但对这里报告的大小没有帮助。他说不可能。他同意可能是 AV。
正如我对下面的 Azure 同事所说的，如果问题在清除事件日志后再次出现，我们不会收到原始发帖人的后续回复，因为这是一种常见且错误的解决方案，因为性能会随着时间的推移再次下降。这被称为“后续回复”，我亲眼看到原始发帖人的解决方案可以欺骗那些不跟进的人，让他们相信他们已经解决了问题。我也差点被骗了。我清除了事件日志，性能得到了改善——但我使用了 procmon，发现问题会随着时间的推移而缓慢增长，直到成为问题。出于某种原因，当原始发帖人没有跟进时（可能已经去世、被解雇、辞职或变得忙碌），Azure 同事严厉批评我。下面的 Azure 同事认为，如果原始发帖人没有跟进，那一定是个已解决的问题。这令人恼火和困惑，因为我想不出有哪个技术上如此受人尊敬的人会采取这种立场。如果我刺痛了你的神经，我深表歉意。也许我在互联网上其他地方的行动主义中，我呼吁人们站出来，惹恼了他——在这里（serverfault），我只是出于善意，分享深厚的技术知识，而 Azure 先生却对我的技术贡献是否必要或是否只针对我的某个博客（我没有这样的博客）进行恐吓。我暂时不打算将此链接发送给微软的大约六个关键密友，并问他们微软关键员工的这种恐吓到底是怎么回事，因为我只专注于社区的最大利益，而 Azure 先生的以下回复，简而言之，令人难以置信、尖刻、令人不安和恐吓——我相信有些人喜欢这样对待别人。我最初感到被冒犯，但已经克服了，我知道，被动或主动的读者都会欣赏我所说的话，欣赏我的评论——我 100% 支持它，无论出于法律原因，它在这里是否不合适。Azure 先生，请表现得善良，不要对我的评论产生负面影响。只要克服它并保持克制，就不要再发表评论。
哈利