GC Tuning Case学习摘要

case 1 场景
4CPU 2.6.18
-Xmx1536m -Xms1536m -Xmn500m

目标
减少GC次数，以避免由于GC造成难以支撑高并发量
方法：
降低响应时间或请求次数，这个需要重构，比较麻烦
减少旧生代内存的消耗，比较靠谱
减少每次请求的内存消耗，貌似比较靠谱
降低GC造成的应用暂停时间


jmap dump;发现里面的线程大部分在waiting状态，没在处理任务！
于是根据MAT查到底谁在消耗内存，发现是由于某地方使用了ThreadLocal，但在使用完毕后没
ThreadLocal.set(null), 做完tuning后，旧生代内存下降了大概200M，于是FULL GC频率缩短一半，但仍然不理想

想减少每次请求所分配的内存，碰到问题，如何知道？？？尝试只做一次请求，在run之前之后，进而对比，但实际上dump的时候会force gc，找不到最终的引用关系。。。只好review all code， e.g，  substring会产生新对象，新方法是遍历char array来避免产生新对象

降低GC所造成的长暂停： 采用CMS GC， QPS只提升到50.。。于是放弃，而且还有和jmap -heap的冲突


前端和QPS定量，后端用TPS定量

终极必杀技：降低系统响应时间，QPS终于能支撑到90， 把响应时间从100ms低到40ms左右

预估系统QPS峰值，提前报警，避免系统crash

认真分析GC LOG



case 2

目标
降低FULL GC频率，以及GC所造成的应用暂停
如果还能降低MINOR GC频率与时间更好

方法：
降低响应时间或请求次数，比较麻烦，涉及太多的业务应用
减少每次请求所需分配内存，貌似比较麻烦
减少每次MINOR GC晋升到OLD的对象，比较靠谱
->调大new，在当前参数下不好操作(1536, xmn700)
->调大Survivor，根据目前状况，可选
->调大TenuringThreshold，根据目前状况，不是key point


经过多次调整得到最优值，达到了降低full gc目标，但整体GC所造成的响应时间下降只有10%。 于是保持

Survivor space，同时改成CMS GC
-Xms1536m -Xmx1536m -Xmn700m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC

-XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=1000

-XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -

XX:+DisableExplicitGC

关注JVM最新BUG