预估GC频率的方法

  我们在进行GC调优的过程中，经常是发现出现问题后（比如OOM或者应用长时间暂停），再进行调优的过程。能不能做到在问题出现之前，就先进行调优呢？让我们来给GC算算卦吧！ 
  首先，我们需要拿到一些系统运行状况才能推算出GC的情况，比如： 

• 系统内存大小
• 系统高峰时的TPS/QPS
• 高峰时平均每个请求的耗时

根据这些数据，就可以开始“算命”了（以下是我针对某个线上应用的推算过程）： 

• 系统每秒钟分配的内存大小：因为新分配的内存都是放在EdenSpace的，所以我们可以根据jstat的观测推算出这个值来（jstat -gcutil [pid] 1000）。 多次观测取Eden的差值平均（排除GC前后的），既可以算出Eden在一秒钟内的内存增长比例，再根据jmap -heap（

注意在HotSpot1.6.0_20版本之前的bug）拿到Eden大小，即可推出在当前QPS下，每秒钟系统分配的内存大小 将每秒钟分配的内存大小/当前应用的QPS量，就推算出当前系统平均每个请求分配的内存大小 观测jstat在每次MinorGC后Suvivor的大小（取多次中的最大值）+从New晋升到Old的大小（OldGen的前后差值），可以近似的认为此值就是实际需要的SurvivorSpace空间，再将此值增加一定比例（为了留出一些冗余吞吐量）就得出了需要调优的SurvivorSpace。 根据Survivor和Eden的比例（-XX:SurvivorRatio）即可算出整个New需要多少空间。 估算出的EdenSpace大小/(平均每个请求分配内存的大小*系统QPS峰值)，就可以推出在峰值时大概几秒钟会发生一次MinorGC。注意如果MinorGC发生的频率过快，可以考虑放大New的空间，这样就可以让一些Eden中存活的对象多活一段时间，好处是MinorGC时应该会回收更多的内存，减少新对象晋升到Old的可能；坏处是增加每次MinorGC的耗时。
这样就可以将系统的QPS和内存的分配频率、分配大小结合在一起，通过一些监控，就可以实现当QPS到达一定值时，就要准备做性能调优或对服务器扩容了。当然，系统的内存分配监控可能不是这么简单的，系统每个请求的耗时、系统版本更新、外部资源的变更等可能都会导致系统内存分配的变化，所以这种“算命”只是针对稳态系统的情况下的一种测算方法。 


转载请注明出处： http://blueswind8306.iteye.com/blog/1217770