老年代 CMS gc回收算法 对hbase的影响

老年代 CMS gc回收算法 对hbase的影响*****

参考链接： 深入研究java gc https://blog.51cto.com/12445535/2372976 CMS失败模式（CMS Failure Mode） 1、上文提到在正常的情况下CMS整个流程的暂停时间都是很短的，一般也就在10ms～100ms左右。 2、然而这与线上的情况并不相符，线上集群在读写压力很大的情况下，经常会出现长时间的卡顿，有些卡顿甚至长达几分钟，导致很严重的读写阻塞，甚至会造成Region Server和Zookeeper之间Session超时，使得Region Server异常离线。 3、实际上，CMS并不是很完美，它会在两种场景下产生严重的Full GC（Concurrent Failure(并发失败)，Promotion Failure （促销失败）），接下来分别进行介绍。

Concurrent Failure(并发失败) 为什么会出现并发失败？ 1、假如现在系统正在执行CMS回收老生代空间，在回收的过程中新生代来了一批对象进来，不巧的是，老生代已经没有空间再容纳这些对象了。 2、这种场景下，CMS回收器会停止继续工作，系统进入 ’stop-the-world’ 模式，并且回收算法会退化为单线程复制算法，重新分配整个堆内存的存活对象到S0中，释放所有其他空间。很显然，整个过程会非常’漫长’。 解决方法： JVM提供了参数-XX:CMSInitiatingOccupancyFraction=N来设置CMS回收的时机，其中N表示当前老生代已使用内存占新生代总内存的比例，该值默认为68，可以将该值修改的更小使得回收更早进行。 //cdh中 默认值为70 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 表示 老年代堆空间的使用率

Promotion Failure （促销失败） 1、假设此时设置XX:CMSInitiatingOccupancyFraction＝60，但是在已使用内存还没有达到总内存60%的时候，已经没有空间容纳从新生代迁移的对象了。 2、oh，my god！怎么会这样？罪魁祸首就是内存碎片，上文中提到CMS算法会产生大量碎片，当碎片容量积累到一定大小之后就会造成上面的场景。 3、这种场景下，CMS回收器一样会停止工作，进入漫长的 ’stop-the-world’ 模式。 4、JVM也提供了参数 -XX: UseCMSCompactAtFullCollection来减少碎片的产生，这个参数表示会在每次CMS回收垃圾之后执行一次碎片整理，很显然，这个参数会对性能有比较大的影响，对HBase这种对延迟敏感的业务来说并不是一个完美解决方案。 //-XX: UseCMSCompactAtFullCollection 此参数，在cdh中默认没有

1、在实际线上环境中，很少出现Concurrent Failure模式的Full GC，大多数Full GC场景都是Promotion Failure。 2、我们线上集群也会每隔半个月左右就会因为Promotion Failure触发一次Full GC。 3、为了更好地理解CMS策略下内存碎片是如何触发Promotion Failure，接下来我们做一个简单的实验： 4、JVM提供了参数 -XX:PrintFLSStatistics=1来打印每次GC前后内存碎片的统计信息，统计信息主要包括3个维度：Free Space、Max Chunk Size和Num Chunks， 5、其中Free Space表示老生代当前空闲的总内存容量， 6、Max Chunk Size表示老生代中最大的内存碎片所占的内存容量大小， 7、Num Chunks表示老生代中总的内存碎片数。 8、我们在测试环境集群（共4台Region Server）将这个参数设置为1，然后使用一个客户端YCSB执行Read-And-Write操作，分别统计日志中Free Space和Max Chunk Size两个指标随时间的变化情况。 小结： 可以知道：CMS GC会不断产生内存碎片，当碎片小到一定程度之后就会基本维持不变，如果此时业务写入一些单条数据量很大的KeyValue，就有可能触发Promotion Failure模式Full GC。

参考链接： http://hbasefly.com/2016/05/21/hbase-gc-1/