高吞吐低延迟Java应用的垃圾回收优化
1.1. 为GC优化系统内存和I/O管理
通常来说,GC停顿发生在(1)低用户时间,高系统时间和高时钟时间和(2)低用户时间,低系统时间和高时钟时间。这意味着基础的进程/OS设置存在问题。情况(1)可能说明Linux从JVM偷页,情况(2)可能说明清除磁盘缓存时Linux启动GC线程,等待I/O时线程陷入内核。在这些情况下如何设置参数可以参考该PPT。
为避免运行时性能损失,启动应用时使用JVM选项-XX:+AlwaysPreTouch访问和清零页面。设置vm.swappiness为零,除非在绝对必要时,OS不会交换页面。
可能你会使用mlock将JVM页pin在内存中,使OS不换出页面。但是,如果系统用尽了所有的内存和交换空间,OS通过kill进程来回收内存。通常情况下,Linux内核会选择高驻留内存占用但还没有长时间运行的进程(OOM情况下killing进程的工作流)。对我们而言,这个进程很有可能就是我们的应用程序。一个服务具备优雅降级(适度退化)的特点会更好,服务突然故障预示着不太好的可操作性——因此,我们没有使用mlock而是vm.swappiness避免可能的交换惩罚。
1. LinkedIn动态信息数据平台的GC优化
对于该平台原型系统,我们使用Hotspot JVM的两个算法优化垃圾回收:
- 新生代垃圾回收使用ParNew,老年代垃圾回收使用CMS。
- 新生代和老年代使用G1。G1用来解决堆大小为6GB或者更大时存在的低于5秒稳定的、可预测停顿时间的问题。在我们用G1实验过程中,尽管调整了各种参数,但没有得到像ParNew/CMS一样的GC性能或停顿时间的可预测值。我们查询了使用G1发生内存泄漏相关的一个bug[3],但还不能确定根本原因。
使用ParNew/CMS,应用每三秒40-60ms的新生代停顿和每小时一个CMS周期。JVM选项如下:
// JVM sizing options
-server -Xms40g -Xmx40g -XX:MaxDirectMemorySize=4096m -XX:PermSize=256m -XX:MaxPermSize=256m
// Young generation options
-XX:NewSize=6g -XX:MaxNewSize=6g -XX:+UseParNewGC -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=8 -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
// Old generation options
-XX:+UseConcMarkSweepGC -XX:CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly
// Other options
-XX:+AlwaysPreTouch -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:-OmitStackTraceInFastThrow
使用这些选项,对于几千次读请求的吞吐量,应用百分之99.9的延迟降低到60ms。
本教程由尚硅谷教育大数据研究院出品,如需转载请注明来源,欢迎大家关注尚硅谷公众号(atguigu)了解更多。