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

TL; DR：EventLog文件已满。 在Windows Server 2008中，覆盖条目非常昂贵和/或不能很好地实现。

在@pk。 和@joeqwerty的build议，并经过询问后，我决定，似乎最有可能的是一个被遗忘的监控实施是抓取事件日志。

我在其中一个域控制器上安装了Microsoftnetworking监视器 ，并使用ProtocolName == MSRPCfilter开始ProtocolName == MSRPC过滤。 有很多的stream量，但它是在我们的远程站点的RODC之间，不幸的是没有使用相同的目标端口作为监听EventLog进程。 该死！ 有这个理论。

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

 SC config EventLog Type= own 

然后，我采取了ProcMon并设置一个filter，以排除所有不使用该PID。 我没有看到很多EventLog失败尝试打开缺less的registry项，这可能是因为这里可能的原因（显然，蹩脚的应用程序可以通过极其糟糕的方式注册为事件源 ）。 可以预见，我看到了很多成功的安全事件日志（C：\ Windows \ System32 \ WinEvt \ Logs \ Security.evtx）的ReadFile条目。

在这些事件之一看看Stack：

您将首先注意到RPCBinding，然后是RPCBindingUnbind。 有很多这些。 就像每秒数千 安全日志非常繁忙，或者Security.evtx日志不能正常工作。

在EventViewer中，安全日志仅logging每分钟50-100个事件，这似乎适合于这个大小的域。 该死！ 有理论上的第二个，我们有一个非常详细的事件审计应用程序左转在一个被遗忘的angular落仍然忠实地徘徊离开。 即使logging的事件发生率很低，仍然有很多（〜250,000）事件被logging下来。 日志大小也许？

安全日志 – （右键单击） – 属性…，最大日志大小设置为131,072 KB，日志大小当前为131,072 KB。 “按需要覆盖事件”单选button被选中。 我认为，不断删除和写入日志文件可能是困难的工作，尤其是当它是如此充分，所以我select了清除日志（我保存旧的日志，以防万一我们需要审计以后），让EventLog服务创build一个新的空文件。 结果：CPU使用率恢复到理性水平大约5％。

您可以通过创build一个小型数据收集器集来追究这一点。

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

如果我的直觉是正确的，你会看到一些设备（IP：端口）锤击你的DC。

当然是一个困难的。 除了单独放置（1个CPU / 50％负载..谁在乎？）之外，你可以尝试设置一个新的域控制器，并在几天后看看这个控制器是否给你提供相同的行为。 如果是这样，你可能想用Wireshark跟踪（显然，networking中有东西会导致这个）

接下来想到的是一个简单的调用微软

特拉维斯，“档案”没有帮助你。 事实上，即使在2/3的时候清理事件日志也没有帮助你。 但“档案”确实帮助了KraigM。

kce：清除了一个131MB的“覆盖”文件，看到性能从55％降到5％，但问题：或许你最终还是看到了高利用率，因为这可能（a）只有在达到覆盖条件时触发，或者（b）当清除的文件从0mb大小增加到131MB时，它可能会线性恶化。

有些人认为这是为security.evtx，一个人看到它的任务计划程序操作日志。 我build议完全卸载你的AV（你正在使用哪一个）并尝试。 入侵者需要隐藏他们的踪迹，并且他们的踪迹是在他们设置或login的计划任务中完成的。 所以他们会隐藏他们的轨道，打破处理这些事件日志，并重写他们跳过他们的轨道。 AVs可能会以一种错误的方式检测到这一点，因为如果它是微软，更多的这种高利用率将被报告，但是当谷歌search时，我看到的只是很less的post。 我也看到这在服务器2008 R2的security.evtx日志。 没有事件日志订户，没有外部显示器。 我观察到一些AV服务（McAfee）正在运行，而且服务器的总利用率很低，所以我怀疑它已被卸载，只有部分如此（可能需要McAfee的特殊卸载程序），我想知道是否有挂钩（或者甚至是正常安装的）迈克菲服务或McAfeefilter驱动程序运行，以某种方式对事件日志进行正常写入，并在其过滤中决定将其转换为对整个事件日志的全面读取。 相信我，来自一些AV公司的第三方filter驱动程序是错误的，而且肯定比微软的事件日志logging实现了10000倍的buggier，这很可能是完美的。 总之，100％卸载所有你自己，看看如果问题解决。 如果是这样，请与您的AV公司合作解决他们的AV。 build议.EVTX文件的文件例外是不明智的，因为您可能会失去这种入侵检测，相信我，这对坏人很重要。

此外，使用procmon时，请注意WriteFile调用，因为Writefile会触发filterpipe理器读取整个文件。 就我而言，读取是在写入完成后大约30秒后启动的，这可能是devise的。 但它是一致的，在我的情况下，该文件是4GB，文件读取涉及64K读文件，每个64KB的长度，它利用了35％的CPU来完成这一点。 很伤心。

更新03/23/2016我看了这台机器上的过滤驱动程序后，得出这是由其中之一造成的（事件日志机制可能永远不会自行车，或这种types的报告数量是惊人的，不是这样）。 我看到一些来自AV的过滤驱动程序，以及一家知名的第三方公司，它们提前读取虚拟机磁盘的性能，并询问他们的首席架构师（谁非常友善和亲切），如果他的产品可能过度积极地阅读整个安全事件日志（这明显是每个procmon发生的）。 这对于较小的安全日志是有帮助的，但不是这里报告的大小。 他没有办法说。 他同意这可能是AV。

正如我对下面的Azure研究员所说的，如果在清除事件日志后问题重新出现，我们就没有后续的原始海报，因为这是一个常见的错误的解决scheme，因为性能会随着时间的推移而再次下降。 这就是所谓的“后续”，我亲眼看到原来的海报的解决scheme可以欺骗那些没有跟进的人，相信他们已经解决了这个问题。 我也几乎被骗了。 我清除了事件日志，提高了性能 – 但是我使用了procmon，发现问题会随着时间的推移慢慢增长和增长，直到问题出现。 出于某种原因，这个azure色的家伙在原来的海报没有跟进时（可能已经死了，被解雇，辞职或忙），严厉地批评我。 下面的Azure家认为，如果原来的海报没有跟进，那肯定是一个固定的问题。 这是令人烦恼和困惑的，因为我想不出任何在技术上如此受到重视的人会采取这一立场。 我道歉，如果我刺痛了神经。 也许在互联网上的其他地方，我把人们叫出来的激进主义，我觉得他很神经 – 在这里（服务器故障），我只是善良的，分享深厚的技术知识，Azure先生的结果是欺负我的技术贡献是否必要或是为我的一些博客（我没有这样的博客）。 我还不打算把这个链接发送给微软的六位左右的密友，并询问他们这样一个关键的MSFT员工的欺凌行为是怎么回事，因为我特别关注的是记住这个社区，以及来自Azure先生的回应，简而言之，是令人难以置信的，辛辣的，令人不安的和欺凌的 – 这是我相信一些人喜欢做的。 我最初被冒犯了，但是知道了，被动或主动的读者会很欣赏我所说的，并且赞赏我的评论 – 我站在它后面100％，而不考虑它为什么在这里不恰当的法律原因。 M. Azure，请实践善意，不要在贫穷的光照下发表我的评论。 只是克服它，performance克制，不再评论。

掠夺