一次显式GC导致的High CPU问题处理过程

Posted 2020-10-04 王.小辉

项目现场反馈系统出现性能问题，具体表现为：所有的客户端响应极其卡顿。

第一反应推测，难道是DB层面出现阻塞？检查v$session会话状态及等待类型未见异常，应该可以排除DB层面原因导致的可能。

继续检查，难道是应用服务器层面出现资源瓶颈？检查任务管理器，w3wp.exe进程占用在10%-20%之间，整体占用也在30%以下（项目现场服务器环境为某通运营商云服务器，此处有坑），内存占用不到4G，w3wp.exe只占了1G多点，服务器的内存好像是48G这个应该也不是瓶颈。继续。。。难道是网络？显然不可能。现场小伙伴是在服务器本地localhost访问。。。那是什么原因导致的呢？好像无处下手了TXT...

套路的方法用完了，好像没找出什么蛛丝马迹。死马当成活马医，抓个dump看看吧。上传下载，中间折腾好几个小时，dump可算是搞来了。。。

先添加到debugdiag分析下吧，Start Analysis之后自己也尝试分析下看看~

检查下系统的资源占用情况，what？明明在抓的时候眼瞅是CPU占用很低的，此处是坑吗。。。看样子问题8成是出在自家身上了，环境问题随他去吧~

什么会导致CPU占用这么高呢？按照Tess的解释，大概有这么三种情况，不过好像是还漏了一种情况——程序执行过程中异常过多。

 

添加下Windows性能计数器看看吧，what？疯了吧。。三个小时GC次数涨了这么多。。。而且，很神奇的是Gen0-Gen2次数很接近。。。这个好像有点问题，按照之前的印象，应该是Gen0内存GC的次数多才对吧...这个是什么原因呢？有点诡异。。。（其实分析的时候没有用这么长时间的日志，只是这个比较明显，就搬过来了~）

 

回头看看debugdiag解析情况，OK~最起始的位置就是个惊人的警告！no，应该是Error！工具分析的结果是69号线程触发了GC，I bet  ，High CPU应该是GC导致！要是猜错了的话，，，那就错了吧~突然发现DebugDiag还是很贴心的，怕我不明白还特意给出了个连接解释。https://blogs.msdn.microsoft.com/tess/2006/06/22/asp-net-case-study-high-cpu-in-gc-large-objects-and-high-allocation-rates/

看了半天，可能是太水，好像借鉴意义不是很大。。。

 

继续，那就先看看69号线程在干啥吧，好像有点怪怪的。。。为啥业务代码中还会调到GC_Collect呢？反编译看看吧

IL反编译

果然调了GC_Collect

改下看看吧，验证OK。