我们有两个Windows Server 2008 SP2(不幸的是不是2008 R2)域控制器在一个小型的150个客户端域中展示了非常“高峰”的CPU使用率。 域控制器都performance出相同的行为,并托pipe在vSphere 5.5.0,1331820上。每两到三秒钟CPU使用率跳至80-100%,然后迅速下降,保持低一两秒,然后跳转再次。
查看虚拟机的历史性能数据表明,这种情况已经持续了至less一年,但从三月份以来频率已经增加。
有问题的过程是SVChost.exe包装DHCP客户端(dhcpcsvc.dll),EventLog(wevtsvc.dll)和LMHOSTS(lmhsvc.dll)服务。 我当然不是Windows内部专家,但是在使用Process Explorer查看进程时,似乎找不到任何特别的错误,除了EventLog正在触发大量的RpcBindingUnbind调用。
在这一点上,我没有咖啡和想法。 我应该如何继续解决这个问题?
TL; DR:EventLog文件已满。 在Windows Server 2008中,覆盖条目非常昂贵和/或不能很好地实现。
在@pk。 和@joeqwerty的build议,并经过询问后,我决定,似乎最有可能的是一个被遗忘的监控实施是抓取事件日志。
我在其中一个域控制器上安装了Microsoftnetworking监视器 ,并使用ProtocolName == MSRPC
filter开始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一个小型数据收集器集来追究这一点。
tracerpt –l “file.etl” –of CSV
将保存的.etl文件转换为.csv 如果我的直觉是正确的,你会看到一些设备(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克制,不再评论。
掠夺