码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2018-05-25 19:37:35      阅读:165      评论:0      收藏:0      [点我收藏+]

标签:-o   alt   host   线程   windows   响应   win   ima   处理   

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

第一反应推测,难道是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问题处理过程(转)

标签:-o   alt   host   线程   windows   响应   win   ima   处理   

原文地址:https://www.cnblogs.com/AmilyWilly/p/9090034.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!