记一次CPU持续100%及分析方法

背景

某天晚上八点多，突然收到一个 CPU 爆表的告警。

过了一会，几个业务线就开始反馈系统变慢了。

后面紧急处理了这台机器后，让业务先恢复正常。

后续看了一下监控，拔凉拔凉的。

这个服务是比较重要的一个老业务，.NET Framework 的 Web API 项目。

回过头来看一下，要找出造成了 CPU 持续 100% 的根本原因，这样才能把这个雷去掉。

要分析的话，需要创建了一个 CPU 持续很高的时候的 dump 包，然后用 WinDbg 来处理。

下面来分析一下，探个究竟。

WinDbg 分析

WinDbg分析CPU，用的比较多的其实就那几个命令。

照着走一遍基本就出来结果了。

首先是用 !threadpool 查看当前CPU状况和线程信息。

上面主要的是 76% 的 CPU 使用率。

然后是用 !runaway 看线程的耗时，看那个占用多

从上图可以看出 32 、34 、38 、39 这几个线程比较可疑。

下面就是切换到对应的线程看具体的信息了。

用 ~34s 切换到 34 号线程，如果是其他，按需替换即可。

然后用 !clrstack 看这个线程在执行什么内容

上面的图很清晰的告诉我们，有一个 ConverAgeMonth 的方法，里面用到了正则。说到正则，用的不好，真的很容易出问题。

到这里基本就知道问题出在那里了。

下面还要看具体的参数信息，才会更加清晰一点。

这里用的是 !clrstack -p 这个命令。

可以看到 ConverAgeMonth 这个方法有两个参数， age 和 ageMonth。

点一下 age 对应的地址或者手动输入 !do 地址 就可以看到具体的字符串内容了。

看到这个超级长字符串，长度接近 2w 。。。。

同样看了其他几个，都是如出一辙，可以断定就是那个正则惹的祸了。

后续调整了这一块的内容后就没有出现过了 CPU 爆表的情况了。

写在最后

虽然 WinDbg 用起来感觉很不错，不过整体流程相对复杂一点，相当于是离线分析，不能实时进行观测和分析。

这一块还有待完善，有很大的提升空间。