一次显式GC导致的High CPU问题处理过程
来源:互联网 发布:给差评被淘宝店家威胁 编辑:程序博客网 时间:2024/06/11 21:30
项目现场反馈系统出现性能问题,具体表现为:所有的客户端响应极其卡顿。
第一反应推测,难道是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问题处理过程
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 一次RAC共享磁盘映射问题导致RAC异常重启的故障处理过程
- ORACLE一次大量数据删除导致问题的处理
- 一次Full GC 过程的日志分析
- 一次频繁Full GC的排查过程
- 一次线上的GC问题排查
- ORACLE CPU过高的一次调整过程
- 一次因为归档日志写满磁盘导致的数据库异常以及恢复处理过程
- hbase GC时间过程导致进程挂掉问题
- 网上一次MySQL中文乱码问题的处理过程
- 网上一次MySQL中文乱码问题的处理过程
- 一次处理项目中工作流问题的过程记录
- 记一次Hive元数据管理问题的处理过程
- High Water Mark导致的SQL效率问题
- 一次CMS GC问题排查过程(理解原理+读懂GC日志)
- 一次CMS GC问题排查过程(理解原理+读懂GC日志) (顶)
- [源码阅读笔记]整合
- Super Jumping! Jumping! Jumping! LIS
- git linux安装
- Android4.42-Settings源码分析之蓝牙模块Bluetooth(全)
- Hibernate ERROR: Table doesn't exist
- 一次显式GC导致的High CPU问题处理过程
- 机器学习第八课(决策树)
- 随笔20170826
- Android攻城狮的第二门课(第2季)第4章 使用AlertDialog实现提示框
- 集合(2)list 关羽
- 专三(上)学习规划
- DOM编程艺术第二章
- .html(),.text()和.val()的差异总结:
- mac OS 配置 Java 开发环境