大数据技术-HBase:MSLAB介绍

随着内存资源价格的降低,服务器的内存越来越大,很多都是达到96GB的。而HBase的RS又是内存耗用性的,很多时候我们为其分配了比较大的内存空间。但与此同时,很多人都会遇到配置大内存所导致的各种问题。

首先,我们知道HBase工作依赖于Zookeeper,RS会定期向Master进行状态汇报,如果长时间没有收到RS的汇报信息,Master会认为RS已经死掉,然后开始进行恢复操作。而Zookeeper与RS的会话也可能因为STW的GC导致会话超时,自己便会退出。

其次,很大堆内存一旦触发full gc,除了可能导致长时间的停顿,客户端感觉到明显的延迟甚至timeout,另外一个比较严重的是随着时间推移,堆内存中存在大量内存碎片,带来的结果是虽然还有很多空余内存,但很多是比较小无法分配使用的,promotion failure。

生产环境一般新生代使用ParNew, 老年代用CMS,触发尽量别配置太大比例,否则容易产生晋升失败。

HBase提供了以下几个参数便于利用上一种机制,防止堆中产生过多碎片,大概思路也是参考TLAB,叫做MSLAB,MemStore-Local Allocation Buffer,为memstore划分相应的区块MemStoreLAB,里面一个字节数组固定的大小(curChunk),用于存放KeyValue的具体数值,还有一个变量用于记录目前空余空间偏移指针,当一个Chunk被填满,重新开辟一个字节数组空间。有效减少了因为内存碎片导致的full gc。


MSLAB,全称是 MemStore-Local Allocation Buffer,是Cloudera在HBase 0.90.1时提交的一个patch里包含的特性。它基于Arena Allocation解决了HBase因Region flush导致的内存碎片问题。
MSLAB的实现原理(对照Arena Allocation,HBase实现细节):
MemstoreLAB为Memstore提供Allocator。
创建一个2M(默认)的Chunk数组和一个chunk偏移量,默认值为0。
当Memstore有新的KeyValue被插入时,通过KeyValue.getBuffer()取得data bytes数组。将data复制到Chunk数组起始位置为chunk偏移量处,并增加偏移量=偏移量+data.length。
当一个chunk满了以后,再创建一个chunk。
所有操作lock free,基于CMS原语。
优势:
KeyValue原始数据在minor gc时被销毁。
数据存放在2m大小的chunk中,chunk归属于memstore。
flush时,只需要释放多个2m的chunks,chunk未满也强制释放,从而为Heap腾出了多个2M大小的内存区间,减少碎片密集程度。
开启MSLAB
hbase.hregion.memstore.mslab.enabled=true // 开启MSALB
hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小,越大内存连续性越好,但内存平均利用率会降低
hbase.hregion.memstore.mslab.max.allocation=256K // 通过MSLAB分配的对象不能超过256K,否则直接在Heap上分配,256K够大了



参考:

http://blog.sina.com.cn/s/blog_6b10e1740100rxnk.html

http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/

http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-2/

http://blog.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/


你可能感兴趣的:(hbase)