预估性优化
估算系统QPS,每个请求会创建多少对象,占多少内存,机器配置选型,年轻代应该给多少内存,YGC触发频率,对象进入老年代的速率,老年代应该给多少内存,Full GC触发的频率。这些都是根据代码可大概合理预估的。
预估完成后,就能采用优化思路,先给自己的系统设置一些初始JVM参数。如堆内存大小,年轻代大小,Eden和Survivor的比例,老年代的大小,大对象的阈值,大龄对象进入老年代的阈值等。
优化思路很简单,尽量让:
每次 YGC 后的存活对象 < Survivor区/2
保证都留存在年轻代里。尽量不让对象进入老年代,以减少Full GC频率,避免频繁Full GC影响JVM性能。
系统压测时的JVM优化
一个新系统开发完后,会经过本地的单元测试,到系统集成测试,再到测试环境的功能测试,预发布环境的压力测试,要保证系统的功能全部正常。在一定压力下性能、稳定性和并发能力都正常,最后才会部署到生产环境运行。
关键环节就是预发布环境的压力测试,会使用一些压力测试工具模拟比如1000个用户同时访问系统,造成每秒500个请求的压力,然后看系统能否支撑住每秒500请求的压力。同时看系统各个接口的响应延时是否在比如200ms内或在数据库中模拟出来百万级单表数据,然后看系统是否还能稳定运行。
具体如何进行系统压测,不是我们这里要讲述的内容,大家自行百度一下“Java压力测试”,就会看到很多开源的工具,可以轻松模拟出N个用户同时访问你系统的场景,还能给你一份压力测试报告,告诉你系统可以支撑每秒多少请求,包括系统接口的响应延时。通常压测工具会对系统发起持续不断的请求,持续很长时间,比如几个小时,甚至几天时间。
所以此时完全就可以在这个环节,对测试机器运行系统,采用jstat分析模拟真实环境的压力下,JVM运行状态。
然后根据压测环境JVM运行状况,如发现对象过快进入老年代,就需要采用之前介绍的优化思路,合理调整新生代、老年代、Eden、Survivor各个区域的内存大小,保证对象尽量留在年轻代,不要过快进入老年代。
当对压测环境下的系统优化好JVM参数之后,观察Young GC和Full GC频率都很低,此时就可部署上线。
监控线上JVM
每天高峰、低峰期用jstat、jmap、jhat等工具观察线上系统的JVM运行是否正常,有无频繁Full GC的问题。有就优化,没有就平时每天都定时或每周都看看。
部署专门监控系统
如Zabbix、OpenFalcon、Ganglia,然后你部署的系统都可以把JVM统计项发送到这些监控系统里去。
此时你就可以在这些监控系统可视化的界面里,看到你需要的所有指标,包括你的各个内存区域的对象占用变化曲线,直接可以看到Eden区的对象增速,还会告诉你Young GC发生的频率以及耗时,包括老年代的对象增速以及Full GC的频率和耗时。
而且这些工具还允许你设置监控。即指定一个监控规则,比如线上系统的JVM,如果10分钟之内发生5 次以上Full GC,就需要发送报警给你。比如发送到你的邮箱、短信。
其实把这些命令行用好了,基本线上系统的JVM监控和优化都能搞定了。
线上运行系统,要不然用命令行工具手动监控,发现问题就优化,要不然就是依托公司监控系统,可视化查看日常系统的运行状态。