JVM堆大小的建议

12-07-21 banq

JVM的堆大小设置是一趟很深的水,既要有对架构高度认识和落地,也要有对语言内部机制深入理解和掌握。

首先,需要对JVM的Heap大小有一个预设和监测,见这篇文章选择合适Java堆大小的五个建议(5 Tips for Proper Java Heap Size),其实文中主要普及了一些JVM设置基础知识,强调需要了解的几个知识点和一般经验,也没有给出实战中具体可行的操作办法,其实每个系统是不一样的,就象病人因人而异一样,需要根据自己的系统和自己的经济条件能力找出适合自己的Heap大小。

堆主要分年轻态和老生态两种,刚刚创建的对象在年轻态,如果这个对象引用被容器或静态或其他对象Hold住,或者经常使用,反正不是那种用完就丢等死那种,那么JVM会将其逐步类似复制粘贴到老生态,如果你使用缓存,那么缓存的对象将大部分在老生态这个区域中,比如Jdonframework或Jivejdon缺省都有缓存,是一种基于内存的计算模式,也就是内存状态管理,那么对于堆的这两个区域大小设置就比较讲究了,下面以jivejdon设置的经验谈谈:

在生产环节,需要对年轻态和老生态两个区域大小进行监测,根据访问量不同和CMS设置不同,特别是老生态大小会经常变化,监测使用PSI-Probe

初期JVM的大小按照年轻态:老生态=1:3进行配置,当然也和缓存中空闲失效期设置有关,缓存对其中对象如果空闲多长时间没有被使用,将实现清除,类似HttpSession机制。

如果缓存失效期设置过短,老生态利用率不高,比如1.3G的老生态只使用了300M,当然,也可以延缓CMS的启动比例,比如在接近1.3G的70%开始CMS垃圾收集,但是这样碰上尖峰访问可能来不及收集就撑死了(OME:OutOfMemoryError )。

如果缓存失效期设置过长,老生态会被撑满,频繁启动CMS也是徒劳无益,增加系统暂停响应时间,增加了系统延迟。

这样,缓存失效期或者说缓存大小就需要根据JVM老生态在长时间生产环境运行下进行不断微调,Probe起到了关键作用,主要是其图形化直观显示,比起JDK的JConsole等等工具要方便。

[该贴被admin于2012-07-21 18:41修改过]

                   

43
banq
2012-07-21 10:40

上面讨论了堆的大小设置和缓存的关系,因为我们的应用是基于DDD,实体包含状态常驻内存,所以,堆大小对于应用系统是至关重要的。

权衡堆的大小还和两个架构指标有关:延迟和吞吐量,我们总是想通过低延迟获得高吞吐量,堆越大,无疑吞吐量越大,但又不能频繁触发垃圾回收,否则引起暂停,提高了延迟,这是一对矛盾,当然,堆的垃圾回收我们已经设定了新生代是并发回收,老生态采取CMS。

首先,我们要获得关于我们系统的延迟和吞吐量确切指标:使用javamelody对http请求响应时间监测是必要的,其实是对系统重要指标延迟latency进行监测,JVM的微调成绩最终会反映这个指标上。

另外一个微调衡量指标是吞吐量,可以通过jsvnstat + SNMP来获得每天吞吐量,假设是400M,那么,对于JVM的老生态大小至少要大于400M,能撑过一天访问量,缓存失效期为24小时。

上文谈了如何观察堆的大小,特别是老生态的大小,下面谈谈对堆内部更细节的观察,特别是对老生态内部最关心的是哪个类占据内存最多,或者容易发生内存泄漏memory leak导致OME。

工具比较多,包括在线取样Jprofiler或visualvm和离线取样两种,对于生产环境,通过Probe和javamelody发现问题后,如老生态不断增加,垃圾回收好像失效,响应延迟不断增加等等,这时进行离线取样比较合适。

离线取样有几个工具,见这篇文章:Java heap dump触发和分析,关键是在生产服务器下使用jmap -heap:format=b PID 获得heap.bin文件,执行取样时可能耗CPU,对系统延迟有重大影响,挑在空闲时刻取样。

下载heap.bin,使用取样分析工具,推荐使用eclipse 的MAT,其他工具好像没有随着JDK更新而更新,都有些小问题。

至于如何发现导致老生态突然增大甚至OME的罪魁祸首,可借鉴这篇文章:hprof :memory leak analysis tutorial

总结:当我们通过以上工具和思路掌握监控我们系统的JVM后,应用系统的运维关键也就掌握心中,通过不断微调提供7x24几乎不停机的不间断服务成为可能,高可用性也即将成为现实。

[该贴被banq于2012-07-24 17:03修改过]

banq
2012-07-24 17:08

本人通过使用VisualVM的Monitor监视中Head dump离线取样,下载其在服务器生成的HPROF文件,再用VisualVM的load加载后分析比较简单,比MAT更加直观,如果发现有数量超过java.lang.String,极可能这个类是内存泄漏点,还可以进行前后取样对比,通过这种方式,本人发现了JdonFramework中ValueEvent存在泄漏见下图,及时修复。

内存监视如同人去做体检,在未做体检之前,你无法想象你身体哪部分出现问题,再完美周密的设计在运行时也可能存在漏洞,因为运动系统规律比我们思维要复杂得多。


yshyshaxw
2013-01-05 12:08

上次去一家公司面试,被问了一堆jvm和jmm的东西,很多都很模糊,希望banq老师能多发些经验之谈

猜你喜欢