hbase参数调整

简单的参数调整，适合初级学习

1.hbase中hfile的默认最大值(hbase.hregion.max.filesize) 256MB  --10GB？？


根据结果得到如下结论：值越小，平均吞吐量越大，但吞吐量越不稳定；值越大，平均吞吐量越小，吞吐量不稳定的时间相对更小。


2. autoflush=false的影响 2M(hbase.client.write.buffer决定)


3.<name>hbase.hregion.memstore.flush.size</name> 128MB


hbase存储目录：
1./hbase/.tmp
当对表做创建或者删除操作的时候，会将表move 到该 tmp 目录下，然后再去做处理操作。
2./hbase/MasterProcWALs
3./hbas/WALs
大家都知道 HBase 是支持 WAL（Write Ahead Log） 的，HBase 会在第一次启动之初会给每一台 RegionServer 在.log 下创建一个目录，若客户端如果开启WAL 模式，会先将数据写入一份到.log 下，当 RegionServer crash 或者目录达到一定大小，会开启 replay 模式，类似 MySQL 的 binlog。
4./hbase/archive
HBase 在做 Split或者 compact 操作完成之后，会将 HFile 移到.archive 目录中，然后将之前的 hfile 删除掉，该目录由 HMaster 上的一个定时任务定期去清理。
5./hbase/corrupt
  存储HBase做损坏的日志文件，一般都是为空的。 
6./hbase/data
这个才是 hbase 的核心目录，0.98版本里支持 namespace 的概念模型，系统会预置两个 namespace 即：hbase和default
7./hbase/hbase.id
它是一个文件，存储集群唯一的 cluster id 号，是一个 uuid。
8./hbase/hbase.version
同样也是一个文件，存储集群的版本号，貌似是加密的，看不到，只能通过web-ui 才能正确显示出来。
9./hbase/oldWALs
这里对应0.94的.oldlogs 目录，取名为 oldWALs 是不是更好了呢！
--10./hbase/.snapshot
     hbase若开启了 snapshot 功能之后，对某一个用户表建立一个 snapshot 之后，snapshot 都存储在该目录下，如对表test 做了一个 名为sp_test 的snapshot，就会在/hbase/.snapshot/目录下创建一个sp_test 文件夹，snapshot 之后的所有写入都是记录在这个 snapshot 之上。  
--11./hbase/.hbck
     HBase 运维过程中偶尔会遇到元数据不一致的情况，这时候会用到提供的 hbck 工具去修复，修复过程中会使用该目录作为临时过度缓冲。


查看属性
./jps -v|grep "Region"




export HBASE_OPTS="$HBASE_OPTS -XX:+UseCompressedOops -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSParallelRemarkEnabled  -XX:CMSInitiatingOccupancyFraction=75 -XX:SoftRefLRUPolicyMSPerMB=0"


-XX:+UseCompressedOops 
压缩指针，解决内存占用


-XX:+UseParNewGC 
设置年轻代为并行收集 
 
-XX:+UseConcMarkSweepG 
 使用CMS内存收集 
 
-XX:+CMSClassUnloadingEnabled 
相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置标志-XX:+CMSClassUnloadingEnabled。 在早期JVM版本中，要求设置额外的标志-XX:+CMSPermGenSweepingEnabled。注意，即使没有设置这个标志，一旦永久代耗尽空 间也会尝试进行垃圾回收，但是收集不会是并行的，而再一次进行Full GC。


-XX:+UseCMSCompactAtFullCollection 
使用并发收集器时,开启对年老代的压缩.


-XX:CMSFullGCsBeforeCompaction 
由于并发收集器不对内存空间进行压缩,整理,所以运行一段时间以后会产生”碎片”,使得运行效率降低.此值设置运行多少次GC以后对内存空间进行压缩,整理.


-XX:+CMSParallelRemarkEnabled 
降低标记停顿


-XX:CMSInitiatingOccupancyFraction=75 
使用cms作为垃圾回收使用75％后开始CMS收集


-XX:SoftRefLRUPolicyMSPerMB 
每兆堆空闲空间中SoftReference的存活时间




----
oldWALs 32MB左右？


----
关注一下dmesg和message的log
---------------
export HBASE_HEAPSIZE=6G


    <property>  
        <name>hfile.block.cache.size</name>  
        <value>0.3</value>  
    </property>  
    
<property>
   <name>hbase.regionserver.global.memstore.size.lower.limit</name>  
        <value>0.5</value>  
    </property>  
    <property>  
        <name>hbase.regionserver.global.memstore.size</name>  
        <value>0.5</value>  
    </property> 

 -===这样在HEAP_SIZE=4G时候，


    hfile.block.cache.size计算值为4G*0.3=1.2G;
     hbase.regionserver.global.memstore.size计算值为4G*0.5=2G;
     hbase.regionserver.global.memstore.size.lower.limit计算值为4G*0.5*0.5=1G;
     并且0.3+0.5<=0.8，没有超过hbase设置的不能超过0.8这个值
------
<property>  
        <!--htable.setWriteBufferSize(5242880);//5M -->  
        <name>hbase.client.write.buffer</name>  
        <value>5242880</value>  
</property> 


默认是 2097152； HTable客户端的写缓冲的默认大小。这个值越大，需要消耗的内存越大。因为缓冲在客户端和服务端都有实例，所以需要消耗客户端和服务端两个地方的内存。得到的好处是，可以减少RPC的次数
------
<property>    
        <name>hbase.regionserver.handler.count</name>    
        <value>100</value>    
        <description>Count of RPC Listener instances spun up on RegionServers.Same property is used by the Master for count of master handlers.</description>    
</property> 


默认30；；；参数hbase.regionserver.handler.count的本质是设置一个RegsionServer可以同时处理多少请求。 如果定的太高，吞吐量反而会降低;如果定的太低，请求会被阻塞，得不到响应。你可以打开RPC-level日志读Log，来决定对于你的集群什么值是合适的。(请求队列也是会消耗内存的)


-------


    1 .每一个Region都有一个Memstore，Memstore默认大小为128MB，可通过hbase.hregion.memstore.flush.size更改；
    2 Region会随着split操作逐步增多，为了控制Memstore之和导致OOM错误，在hbase老版本中是通过hbase.regionserver.global.memstore.upperLimit和hbase.regionserver.global.memstore.lowerLimit进行控制，新版本中使用hbase.regionserver.global.memstore.size和hbase.regionserver.global.memstore.lowerLimit控制；
    3 Hbase-env.sh中HEAP_SIZE=4G时，老版本Hbase.regionserver.global.memstore.upperLimit(默认HEAP_SIZE*0.4)=1.6G,hbase.regionserver.global.memstore.lowerLimit(默认HEAP_SIZE*0.35)=1.4G,新版本hbase.regionserver.global.memstore.size(默认HEAP_SIZE*0.4)=1.6G和Hbase.regionserver.global.memstore.lowerLimit(hbase.regionserver.global.memstore.size*HEAP_SIZE*0.95)=1.52G;

    4 Memstore总和达到第一个临界值，会在所有memstore中选择一个最大的那个进行flushing，此时不会阻塞写；
    Memstore总和达到第二个临界值，会阻塞所有的读写，将当前所有memstore进行flushing。
    每一个Region都有一个BlockCache，BlockCache总和默认打下为HEAP_SIZE乘以0.4，默认是通过hfile.block.cache.size设置；
    所有的读请求，先到BlockCache中查找，基本Memstore中有的值在BlockCache中也都有，找不到再去Hfile中找。
    5 hbase中默认规定Memstore总和最大值(hbase.regionserver.global.memstore.size默认0.4)和BlockCache总和最大值(hfile.block.cache.size默认0.4)之和不能大于0.8，因为要预留0.2的HEAP_SIZE供其他操作使用，这个可详见hbase源代码Org.apache.hadoop.hbase.io.util.HeapMemorySizeUtil.java文件。