JVM 调优 —— GC 长时间停顿问题及解决方法
2017-01-04 22:03
232 查看
零. 简介
垃圾收集器长时间停顿,表现在 Web 页面上可能是页面响应码 500 之类的服务器错误问题,如果是个支付过程可能会导致支付失败,将造成公司的直接经济损失,程序员要尽量避免或者说减少此类情况发生。
一. 并发模式失败(concurrent mode failure)
并发模式失败日志:
两个原因:
在 CMS 启动过程中,新生代提升速度过快,老年代收集速度赶不上新生代提升速度
在 CMS 启动过程中,老年代碎片化严重,无法容纳新生代提升上来的大对象
发送这种情况,应用线程将会全部停止(相当于网站这段时间无法响应用户请求),进行压缩式垃圾收集(回退到 Serial Old 算法)
解决办法:
新生代提升过快问题:(1)如果频率太快的话,说明空间不足,首先可以尝试调大新生代空间和晋升阈值。(2)如果内存有限,可以设置 CMS 垃圾收集在老年代占比达到多少时启动来减少问题发生频率(越早启动问题发生频率越低,但是会降低吞吐量,具体得多调整几次找到平衡点),参数如下:如果没有第二个参数,会随着 JVM 动态调节 CMS 启动时间
-XX:CMSInitiatingOccupancyFraction=68 (默认是 68)
-XX:+UseCMSInitiatingOccupancyOnly
老年代碎片严重问题:(1)如果频率太快或者 Full GC 后空间释放不多的话,说明空间不足,首先可以尝试调大老年代空间(2)如果内存不足,可以设置进行 n 次 CMS 后进行一次压缩式 Full GC,参数如下:
-XX:+UseCMSCompactAtFullCollection:允许在 Full GC 时,启用压缩式 GC
-XX:CMSFullGCBeforeCompaction=n 在进行 n 次,CMS 后,进行一次压缩的 Full GC,用以减少 CMS 产生的碎片
二. 提升失败(promotion failed)
在 Minor GC 过程中,Survivor Unused 可能不足以容纳 Eden 和另一个 Survivor 中的存活对象, 那么多余的将被移到老年代, 称为过早提升(Premature Promotion)。 这会导致老年代中短期存活对象的增长, 可能会引发严重的性能问题。 再进一步, 如果老年代满了, Minor GC 后会进行 Full GC, 这将导致遍历整个堆, 称为提升失败(Promotion Failure)。
提升失败日志:
提升失败原因:Minor GC 时发现 Survivor 空间放不下,而老年代的空闲也不够
新生代提升太快
老年代碎片太多,放不下大对象提升(表现为老年代还有很多空间但是,出现了 promotion failed)
解决方法:
两条和上面 concurrent mode failure 一样
另一条,是因为 Survivor Unused 不足,那么可以尝试调大 Survivor 来尝试下
三. 在 GC 的时候其他系统活动影响
有些时候系统活动诸如内存换入换出(vmstat)、网络活动(netstat)、I/O (iostat)在 GC 过程中发生会使 GC 时间变长。
前提是你的服务器上是有 SWAP 区域(用 top、 vmstat 等命令可以看出)用于内存的换入换出,那么操作系统可能会将 JVM 中不活跃的内存页换到 SWAP 区域用以释放内存给线程使用(这也透露出内存开始不够用了)。内存换入换出是一个开销巨大的磁盘操作,比内存访问慢好几个数量级。
看一段 GC 日志:耗时 29.47 秒
再看看此时的 vmstat 命令中 si、so 列的数值,如果数值大说明换入换出严重,这是内存不足的表现。
解决方法:减少线程,这样可以降低内存换入换出;增加内存;如果是 JVM 内存设置过大导致线程所用内存不足,则适当调低 -Xmx 和 -Xms。
四. JVM 的 bug
这种原因就根据自己使用的 JDK 版本去查一下,如果是 JVM 的 bug,升级到解决的版本一般就能解决。
五. 总结
长时间停顿问题的排查及解决首先需要一定的信息和方法论:
详细的 GC 日志
借助 Linux 平台下的 iostat、vmstat、netstat、mpstat 等命令监控系统情况
使用 GCHisto 这个 GC 图形用户界面工具,可以统计出 Minor GC 及 Full GC 频率及时长分布,可参考:http://blog.csdn.net/wenniuwuren/article/details/50760259
查看 GC 日志中是否出现了上述的典型内存异常问题(promotion failed, concurrent mode failure),整体来说把上述两个典型内存异常情况控制在可接受的发生频率即可,对 CMS 碎片问题来说杜绝以上问题似乎不太可能,只能靠 G1 来解决了
是不是 JVM 本身的 bug 导致的
如果程序没问题,参数调了几次还是不能解决,可能说明流量太大,需要加机器把压力分散到更多 JVM 上
六. 参考资料
《Java 性能优化权威指南》
https://blogs.oracle.com/poonam/entry/troubleshooting_long_gc_pauses
原文出处: 文牛武人
from: http://www.importnew.com/22886.html
垃圾收集器长时间停顿,表现在 Web 页面上可能是页面响应码 500 之类的服务器错误问题,如果是个支付过程可能会导致支付失败,将造成公司的直接经济损失,程序员要尽量避免或者说减少此类情况发生。
一. 并发模式失败(concurrent mode failure)
并发模式失败日志:
在 CMS 启动过程中,新生代提升速度过快,老年代收集速度赶不上新生代提升速度
在 CMS 启动过程中,老年代碎片化严重,无法容纳新生代提升上来的大对象
发送这种情况,应用线程将会全部停止(相当于网站这段时间无法响应用户请求),进行压缩式垃圾收集(回退到 Serial Old 算法)
解决办法:
新生代提升过快问题:(1)如果频率太快的话,说明空间不足,首先可以尝试调大新生代空间和晋升阈值。(2)如果内存有限,可以设置 CMS 垃圾收集在老年代占比达到多少时启动来减少问题发生频率(越早启动问题发生频率越低,但是会降低吞吐量,具体得多调整几次找到平衡点),参数如下:如果没有第二个参数,会随着 JVM 动态调节 CMS 启动时间
-XX:CMSInitiatingOccupancyFraction=68 (默认是 68)
-XX:+UseCMSInitiatingOccupancyOnly
老年代碎片严重问题:(1)如果频率太快或者 Full GC 后空间释放不多的话,说明空间不足,首先可以尝试调大老年代空间(2)如果内存不足,可以设置进行 n 次 CMS 后进行一次压缩式 Full GC,参数如下:
-XX:+UseCMSCompactAtFullCollection:允许在 Full GC 时,启用压缩式 GC
-XX:CMSFullGCBeforeCompaction=n 在进行 n 次,CMS 后,进行一次压缩的 Full GC,用以减少 CMS 产生的碎片
二. 提升失败(promotion failed)
在 Minor GC 过程中,Survivor Unused 可能不足以容纳 Eden 和另一个 Survivor 中的存活对象, 那么多余的将被移到老年代, 称为过早提升(Premature Promotion)。 这会导致老年代中短期存活对象的增长, 可能会引发严重的性能问题。 再进一步, 如果老年代满了, Minor GC 后会进行 Full GC, 这将导致遍历整个堆, 称为提升失败(Promotion Failure)。
提升失败日志:
新生代提升太快
老年代碎片太多,放不下大对象提升(表现为老年代还有很多空间但是,出现了 promotion failed)
解决方法:
两条和上面 concurrent mode failure 一样
另一条,是因为 Survivor Unused 不足,那么可以尝试调大 Survivor 来尝试下
三. 在 GC 的时候其他系统活动影响
有些时候系统活动诸如内存换入换出(vmstat)、网络活动(netstat)、I/O (iostat)在 GC 过程中发生会使 GC 时间变长。
前提是你的服务器上是有 SWAP 区域(用 top、 vmstat 等命令可以看出)用于内存的换入换出,那么操作系统可能会将 JVM 中不活跃的内存页换到 SWAP 区域用以释放内存给线程使用(这也透露出内存开始不够用了)。内存换入换出是一个开销巨大的磁盘操作,比内存访问慢好几个数量级。
看一段 GC 日志:耗时 29.47 秒
解决方法:减少线程,这样可以降低内存换入换出;增加内存;如果是 JVM 内存设置过大导致线程所用内存不足,则适当调低 -Xmx 和 -Xms。
四. JVM 的 bug
这种原因就根据自己使用的 JDK 版本去查一下,如果是 JVM 的 bug,升级到解决的版本一般就能解决。
五. 总结
长时间停顿问题的排查及解决首先需要一定的信息和方法论:
详细的 GC 日志
借助 Linux 平台下的 iostat、vmstat、netstat、mpstat 等命令监控系统情况
使用 GCHisto 这个 GC 图形用户界面工具,可以统计出 Minor GC 及 Full GC 频率及时长分布,可参考:http://blog.csdn.net/wenniuwuren/article/details/50760259
查看 GC 日志中是否出现了上述的典型内存异常问题(promotion failed, concurrent mode failure),整体来说把上述两个典型内存异常情况控制在可接受的发生频率即可,对 CMS 碎片问题来说杜绝以上问题似乎不太可能,只能靠 G1 来解决了
是不是 JVM 本身的 bug 导致的
如果程序没问题,参数调了几次还是不能解决,可能说明流量太大,需要加机器把压力分散到更多 JVM 上
六. 参考资料
《Java 性能优化权威指南》
https://blogs.oracle.com/poonam/entry/troubleshooting_long_gc_pauses
原文出处: 文牛武人
from: http://www.importnew.com/22886.html
相关文章推荐
- Java 6 JVM参数选项大全(中文版)
- 打印机无法响应的解决方法第1/2页
- 三个不同文件停顿二秒弹出不同窗口的批处理
- C#提示:“在证书存储区中找不到清单签名证书”的解决方法
- Internet Explorer 8 beta 中文版与IE7共存的解决方法
- Oracle数据更改后出错的解决方法
- ON_COMMAND_RANGE多个按钮响应一个函数的解决方法
- VB的32位程序在64位系统中出现文件和注册表自动转向的解决方法
- php采用curl访问域名返回405 method not allowed提示的解决方法
- PHP提示Cannot modify header information - headers already sent by解决方法
- php运行提示:Fatal error Allowed memory size内存不足的解决方法
- php5.3提示Function ereg() is deprecated Error问题解决方法
- C#控件闪烁的解决方法
- php出现web系统多域名登录失败的解决方法
- 一些Asp技巧和实用解决方法
- php使用iconv中文截断问题的解决方法
- php版微信支付api.mch.weixin.qq.com域名解析慢原因与解决方法
- IE中鼠标经过option触发mouseout的解决方法
- TinyMCE提交AjaxForm获取不到数据的解决方法
- 二行代码解决全部网页木马