域控制器上的“峰值” CPU使用率

在一个小的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会触发大量RpcBindingUnbind调用。

在这一点上，我没有咖啡和想法。我应该如何继续解决此问题？

TL; DR：EventLog文件已满。覆盖条目很昂贵，并且/或者在Windows Server 2008中无法很好地实现。

在@pk。和@joeqwerty的建议，并询问了一下之后，我认为似乎最有可能被遗忘的监视实现正在抓取事件日志。

我在一个域控制器上安装了Microsoft的网络监视器，并开始使用该ProtocolName == MSRPC筛选器筛选MSRPC 。流量很大，但是所有流量都在我们远程站点的RODC之间，但是不幸的是，没有使用与侦听EventLog进程相同的目标端口。该死！那里有理论。

为了简化操作并简化监视软件的运行，我决定从SVCHost拆开EventLog服务。以下命令和域控制器的重新启动将一个SVCHost进程专用于EventLog服务。由于您没有对该PID附加多个服务，因此这使调查变得容易一些。

SC config EventLog Type= own

然后，我求助于ProcMon并设置一个过滤器以排除不使用该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％的合理水平。

您可以通过创建一个小的数据收集器集来简化此过程。

• 打开性能监视器并创建一个新的用户定义的数据收集器集。
• 选择“ 手动（无模板）”，然后选择“ 仅事件跟踪数据”。
• 添加Active Directory域服务：核心数据并保存设置。
• 将“ 属性”下的“ 停止条件”更改为1分钟。
• 开始设置并等待。
• 完成后，保存的转换.etl文件到.CSV使用tracerpt –l “file.etl” –of CSV
• 在Excel中分析summary.csv和dumpfile.csv数据。您可能需要下载此Import-DC-Info.xlsm文档，以帮助您进行分析。

如果我的预感是正确的，您将看到一些设备（IP：端口）正在冲击DC。

当然是困难的。除了不理会它（1个CPU / 50％的负载。如果是这样，您可能要尝试使用Wireshark跟踪（很明显，网络中的某些原因导致了这种情况）

接下来想到的是对Microsoft的简单调用

Travis的“存档”并没有帮助您。实际上，即使清除事件日志增长2/3时仍无济于事。但是“存档”确实帮助了KraigM。

kce：清除了131MB的“覆盖”文件，发现性能从55％下降到5％，但是问题：也许您最终又看到了高利用率，因为这可能是（a）仅在达到覆盖条件时才触发，或者（b）随着清除文件的大小从0mb增加到131MB，它可能会线性恶化。

有些人将其用于security.evtx，另一些人将其用于Task Scheduler操作日志。我建议完全卸载AV（您正在使用的AV）并尝试。入侵者需要隐藏其踪迹，并且踪迹是在他们设置的预定任务或登录时创建的。因此，他们将通过中断这些事件日志的句柄并重写它们以跳过其轨迹来隐藏其轨迹。影音公司可能会以错误的方式检测到此情况，因为如果是Microsoft，则可能会报告更多这种高利用率的信息，但是我在谷歌搜索时看到的帖子很少。我还在server 2008 R2上看到了security.evtx日志。没有事件日志订阅者，没有外部监视器。我观察到有几个AV服务（McAfee）正在运行，并且它们在服务器中使用了很多天，总利用率非常低，因此我怀疑它只是部分被卸载了（可能需要McAfee的特殊卸载程序），我想知道是否存在挂钩运行该痕迹（或什至通常已安装）的McAfee服务或McAfee筛选器驱动程序以某种方式正常写入事件日志，并在其筛选中决定是否需要将其转变为完整读取整个事件日志。相信我，来自某些视音频公司的第三方过滤器驱动程序有漏洞，而且肯定比Microsoft的事件记录实现的错误率高10000倍，这很可能是完美的。总而言之，100％卸载所有AV和SEE如果问题解决。如果是这样，请与您的影音公司合作修复其影音。不建议对进行文件例外处理。

另外，在使用procmon时，请注意WriteFile调用，因为Writefile会触发过滤器管理器读取整个文件。就我而言，读取是在写入完成后大约30秒开始的，这可能是设计使然。但这是一致的，在我的情况下，文件为4GB，读取的文件涉及64K读取文件，每个文件的长度为64KB，它使用35％的CPU来完成此操作。很伤心

更新2016/03/23我断定这是由它们中的一个引起的之后，我查看了这台计算机上的筛选器驱动程序（事件日志机制本身不可能出错，或者此类报告的数量令人and目，它不是）。我看到了一些AV和一家知名的3rd party公司的过滤器驱动程序，这些驱动程序可以通过预先读取来提高虚拟机磁盘的性能，并询问其首席架构师（谁是非常友善和亲切的），他的产品是否可能过度激进地读取了整个产品。安全事件日志（显然每个procmon都在发生）。这对于较小的安全日志很有帮助，但对此处报告的大小没有帮助。他没办法说。他同意这可能是AV。

正如我对下面的Azure同事说的那样，如果在清除事件日志后问题再次出现，我们将没有原始海报的后续措施，因为这是常见且错误的解决方案，因为性能会随着时间的推移而再次下降。这就是所谓的“跟进”，我亲眼看到原始张贴者的解决方案可以使那些不跟进的人以为自己已经解决了问题。我也几乎上当了。我清除了事件日志并提高了性能-但我使用procmon并发现问题会随着时间的流逝而逐渐增长，直到出现问题为止。由于某种原因，当原始海报没有跟进时（可能已经死亡，被解雇，辞职或变得忙碌），Azure同事严厉批评我。下面的Azure研究员认为，如果原始海报没有跟进，那肯定是一个固定的问题。这令人烦恼和困惑，因为我想不出任何在技术上享有很高声誉的人会担任这一职位。如果我不安，我深表歉意。也许是在互联网上其他地方的激进主义中，我叫人对他感到不安-在这里（服务器故障），我只是善良并分享深厚的技术知识，而Azure先生的结果则是在欺负我的技术贡献是否均匀是必要的，还是属于我的某个博客（我没有此类博客）。我尚未打算将此链接发送给Microsoft的大约六个关键亲友，并询问他们对MSFT关键员工的这种欺凌行为是怎么回事，因为我特别关注于以下方面的利益：简而言之，社区的想法和Azure先生的以下回应简直令人难以置信，无礼，令人不安和欺负-我确信有些人喜欢对别人做。我起初是被冒犯的，但是对此感到无所适从，并且知道，无论是被动还是主动的读者，都会喜欢我所说的话，也很欣赏我的评论-我100％地支持它，而不考虑出于法律上的原因在这里还是不恰当的原因。M. Azure，请保持友善，不要以不好的眼光发表我的评论。克服它，表现出克制，不再发表评论。请保持友善，不要以卑鄙的态度发表我的评论。克服它，表现出克制，不再发表评论。请保持友善，不要以卑鄙的态度发表我的评论。克服它，表现出克制，不再发表评论。

哈里