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

Posted AmilyAmily

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次显式GC导致的High CPU问题处理过程(转)相关的知识,希望对你有一定的参考价值。

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

第一反应推测,难道是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。

 

 

 

 

 

 

 
 

以上是关于一次显式GC导致的High CPU问题处理过程(转)的主要内容,如果未能解决你的问题,请参考以下文章

记一次database cpu high的处理

JVM探秘:线上CPU占用过高故障排查

一次ipv6导致Cisco6509cpu高的处理过程

转 如何诊断和解决high version count 10.2.0.4

记一次OOM查询处理过程

记一次线上gc调优的过程