关于hbase的一些调优问题

1、HMaster
          HMaster的任务前面已经说过了,两个大方向:一、管理Hbase Table的 DDL操作 二、region的分配工作,任务不是很艰巨,但是如果采用默认自动split region的方式,     HMaster会稍微忙一些,负载不大,可适度对此进程做适量放大heap 的操作,但不可太大,因为更耗内存的是HRegionServer
     2、HRegionServer
          这个进程是HBase中的核心守护进程,原则上是每个slave启动一个HRegionServer,但多种情况可能导致HRegionServer 意外退出,下面举几个简单的方面:
    •  网络不好,导致RegionServer 和 HMaster通信超时,RegionServer被认为已经挂掉,从而退出集群 --网络问题,无法从软件方面解决,关于通信超时的设置下面做个简单介绍
    •  Java full GC ,这个过程会block所有的线程,如果此事件过长,导致Session expired 会话过期,导致退出集群--下文会阐述
    •  各节点时间不一致,导致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度,默认是30s,但不要太大,毕竟时间不一致是不正常现象,可将所有节点和同一服务器时间做同步,也可以和时间服务器同步
          第一种情况 和其它原因导致的RegionServer 超时挂掉的问题,我们要首先要调高Session的容忍度,默认180000其实这个回话有效期已经够长的了,但是有的集群是可以
   降低了这个值,可能会造成Session 超时,这个参数是 zookeeper.session.timeout 默认18000。
          针对上面这个参数,有的博文认为即使设为180000也不能真正的达到目的,因为zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为
   20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候,系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。
          针对上述观点,我从源码中找到了结论,首先如果是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码:
    •           HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ,而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
    •           调用HQuorunPeer.runZKServer
    •           调用QuorumPeerMain.runFromConfig
    •           设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
    •           由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置,默认是2*ticktime
          由此可见 其实如果设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime,再不信可以用echo conf|nc zserver 2181 看一下 zookeeper系统参数
          第二种情况是要讨论的,导致产生这个问题的主要原因是很多,产生的情景很多,比如在做 major compact的过程中,时间过长,导致Full GC等,那就尽量去减少这种情
   况的发生。二个方面
    •   适度增大守护进程的HeapSize
    •   调整内存回收参数
          第一个方面:Hbase 默认各守护进程为1G  在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000,当我们启动hbase各守护进程的时候,那所有的hbase守护进程都
     将是1000的heapsize,对于有的进程,够用,但有些进程取远远不够,我们可以考虑增大此参数,比如export HBASE-HEAPSIZE=6000 那就把守护进程的heap 内存调大到
     6G,但是这样会有问题,有些进程不需要这么多,虽然设置的比较大不影响内存的实际占用,但却混淆了对各进程内存占用的认识。所以上述参数不做改变,在下面的参数中
     修改守护进程Heap 内存。
    • export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
    • export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC 
                    -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
    • export HBASE_THRIFT_OPTS="$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
    • export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
            我们分别对各守护进程设置堆内存 其中-Xmx 表示最大可用内存,-Xms表示出事分配内存 -Xmn 表示 年轻代堆内存分配,这个值网上有的建议按照3/3 总heapsize来设
     置,因为是经验值,暂无法考证合理性,更多详细的堆内存分配参数,本地不做过多阐述,后面有机会可做一个单元来解释。那其它参数是什么意思呢?
     -XX:+UseParNewGC 等,这就到了我们说的第二个方面:
            第二个方面:调整内存回收参数,比如-XX:+UseParNewGC 表示年轻带内存回收策略采用并发收集,此参数在JDK5.0已经自动配置,不需再手动配置;
     -XX:+UseConcMarkSweepGC 表示年老代并发收集;
     -XX:+CMSInitiatingOccupancyFraction表示年老代内存占用超过此比例即开始做CMS,这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时,
     才开始做内存收集,而此时剩余的10%依然接受从年轻代迁移过来的对象,迁移过快,导致年老代heap 100%时,Full GC 即开始,才是会暂停所有的任务,直至Full GC 完
     成,此时是造成RegionServer 意外退出的元凶,那为了安全起见,在调大堆内存的情况下 蒋此值降低到一个较低的阀值,减少Full GC的产生,那我建议此值设70%。
          3、HQuorumPeer 
               此守护集成是Zookeeper的守护进程,因为我们用的是Hbase内置的ZooKeeper 所以此进程启动过程中,会读取hbase-env.sh 所以守护进程对内存和 HBASE-HEAPSIZE
     的一致,所以也应在hbase-env.sh中合理设置,见HRegionServer 小节中的参数设置方法。
          4、ThriftServer
               同上

注:转载请标明出处多谢!
http://blog.csdn.net/zhouleilei/article/details/12577091

当然,上述是在hbase-env.sh中对jvm的调优,还需要在hbase-site.xml中注意一些配置项
http://img.my.csdn.net/uploads/201212/23/1356248763_6580.JPG

上面这张图不是一太清晰,我后面给个单独的连接

 这里的HBase的优化主要从三个大的维度来进行分析

1、系统硬件

       采用普通的PC Server即可,Master要求高一点(比如8 CPU,48G内存,SAS raid),Regionserver(如8CPU,24G内存,1T*12 SATA JBOD)

      对于存储regionserver节点采用JBOD,master采用sas raid1+0

     数据的存储在hdfs中本身考虑到了冗余,一般情况下replication设置为3,所以不用做raid;需要考虑的是每个节点的可用的存储空间的大小,所以这里用磁盘簇的方式。

      网卡千兆的,做网卡bond,并且管理网段和请求网段分开,对于大的混合集群来说,可以设计多个vlan。

2、客户端client

       a、 scan cache:顺序读的场景中,比如mapreduce做计算,可以设置在regionserver中的一次缓存的数量,可以加快scan的进度,

       不过考虑到regionserver的内存限制,需要注意regionserver并发线程的控制。

      b、在插入数据时,最好用批量插入操作,效率会更高一些。

      c、auto flush最好disable掉

            对于client来说,有一个writebuffer的缓冲,buffer满了之后,自动的发送数据到regionserver端

             可以在某个时间点,手动调用flush的操作进行flush数据

             调用close操作,会隐含调用flush操作

3、regionserver    

           a、对于插入操作,不要集中在一个region中插入,需要考虑rowkey的设计(rowkey如果是顺序设计的,这样会集中插入到一个region中),以及最好预先创建好split region

            b、对于查询操作时,又分为两种情况,一种是顺序读,一种是随机读。

                    顺序读,最好rowkey是连续的设计的,这样可以从一个region中批量读数据;并且关闭block cache(客户端调用setBlockCache(false))。

                    随机读,打开block cache(设置cache合理大小,hfile.block.cache.size);采用booleam filter,提供随机查询的效率。

                  当然HFile块的大小设计很重要,随机读的情况下,可以设置小一点,顺序读的情况下,设计大一下。

             c、对于compact&split操作,建议禁止major compact(hbase.hregion.majorcompaction设为0),该为手动方式,每天不忙的时候进行。

                    设置单个region的合理的大小(hbase.hregion.max.filesize),超过这个值,就自动进行split操作。

              d、手动进行balancer操作

              e、内存大小的相关考虑

                        1) 对于region column family 的buffer,设置合理的checkpoint百分比,减少硬盘IO的操作;对buffer memstore设计合理大小,防止内存溢出。

                                           主要有这三个参数,hbase.regionserver.global.memstore.upperLimit,hbase.regionserver.global.memstore.lowerLimit,memstore.flush .size

                         2)regionserver JVM参数设置

                                      设置最大合理内存大小

                                      垃圾回收策略,并发CMS的设置,比如-XX:CMSInitiatingOccupancyFraction=70,memstore limit 40%,block cache 20%,

                                            防止promted fail(new区S区域放不下,放到旧生代,而旧生代空间不足),防止CMS的同时  ,对象迁移到旧生代,而旧生代空间不足。  

                                             为了避免CMS带来的碎片,可以考虑采用MSLAB

                           3) block cache,创建表时,设置该表对应的块是cache的,通过LRU算法淘汰;不过块中的数据索引dataIndex是放在内存中的。

                f、HFile的设置

                           1)可以压缩存储,减少磁盘和网络IO,有GZIP、LZO、Snappy,一般采用LZO或者Snappy。

                           2)对于HFile中块的大小设置,可以根据顺序读和随机读的比重,来考虑(顺序读,块设置大,随机读,块设置小一点)     

                 g、regionserver并发处理线程handler的的数量(payload大,建议handler数量小一些,反之,建议handler数量大一些)

                 h、可以把一些操作,放在regionserver端执行,避免来回数据交互(filter,coprocessor,count) 

 

相关参数设置参考

  client
              Scan Caching(默认是1条,设置成20条)
              Scan Attribute Selection
             Close ResultScanners
              AutoFlush(默认是true,设置成false)
              Bloom Filter
   
regionserver
    内存 

       JVM(CMS GC,24G heap,-XX:CMSInitiatingOccupancyFraction=70)
        hbase.regionserver.global.memstore.upperLimit(默认0.4)
        hbase.regionserver.global.memstore.lowerLimit(默认0.3)
        hbase.hregion.memstore.flush.size(64M,如果region的数量不多,可以设置的大一些,假如有1000个region*200M)
         hbase.hregion.memstore.block.multiplier(默认是2)
         hfile.block.cache.size(默认是0.2,场景中是读多写少,建议开大一些,0.4)
         hbase.hregion.memstore.mslab.enabled
    文件大小
         hbase.hregion.max.filesize(默认256M,实际环境中为1G,每天手动split,compact)
         hbase.hstore.blockingStoreFiles(默认7),通常情况下,一个storeFile大概在200M的样子,当进行major compact时,会合并成一个
    线程设置
          hbase.regionserver.handler.count(默认是10,设置成100,和内存大小有关系)


【注:如果hbase出现不稳定现象,还可能是以下原因】hadoop的 namenode重新格式化以后,重启hbase,发现它的hmaster进程启动后马上消失,查看一大堆日志,最后在zookeeper的日志里发现如下问题

Unable to read additional data from client sessionid 0x14e86607c850007, likely client has closed socket

解决 方法:删除掉hbase的hbase-site.xml中一下内容所配置路径下的目录,重启zookeeper集群,再重启hbase让该目录重新生成即可

<property>
<name>hbase.zookeeper.property.dataDir</name>
<value>/home/infocenter/zookeeper/data</value>
</property>

hbase.zookeeper.property.dataDir:这个是ZooKeeper配置文件zoo.cfg中的dataDir。zookeeper存储数据库快照的位置。


接下来贴上hbase的配置项简介:
Hbase配置项(1)
hbase.tmp.dir:本地文件系统的临时目录,默认是java.io.tmpdir/hbase?{user.name};
hbase.rootdir:hbase持久化的目录,被所有regionserver共享,默认${hbase.tmp.dir}/hbase,一般设置为hdfs://namenode.example.org:9000/hbase类似,带全限定名;
hbase.cluster.distributed:hbase集群模式运作与否的标志,默认是false,开启需要设置为true,false时启动hbase会在一个jvm中运行hbase和zk;
hbase.zookeeper.quorum:重要的也是必须设置的,启动zk的服务器列表,逗号分隔,cluster模式下必须设置,默认是localhost,hbase客户端也需要设置这个值去访问zk;
hbase.local.dir:本地文件系统被用在本地存储的目录,默认${hbase.tmp.dir}/local/;
hbase.master.port:hbase master绑定的端口,默认是60000;
hbase.master.info.port:hbase master web 界面的端口,默认是60010,设置为-1可以禁用ui;
hbase.master.info.bindAddress:master web界面的绑定地址,默认是0.0.0.0;
hbase.master.logcleaner.plugins:清理日志的插件列表,逗号分隔,被LogService调用的LogCleanerDelegate,可以自定义,顺序执行,清理WAL和HLog;默认org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner
hbase.master.logcleaner.ttl:HLog在.oldlogdir目录中生存的最长时间,过期则被Master起线程回收,默认是600000;
hbase.master.hfilecleaner.plugins:HFile的清理插件列表,逗号分隔,被HFileService调用,可以自定义,默认org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner
hbase.master.catalog.timeout:Catalog Janitor从master到META的超时时间,我们知道这个Janitor是定时的去META扫描表目录,来决定回收无用的regions,默认是600000;
fail.fast.expired.active.master:如果master过期,那么不需要从zk恢复,直接终止,默认是false;
hbase.master.dns.interface:master的dns接口,向该接口提供ip,默认是default;
hbase.master.dns.nameserver:master使用的dns主机名或者ip,默认是default;
hbase.regionserver.port:regionserver绑定的端口,默认是60020;
hbase.regionserver.info.port:regionserver的web界面端口,-1取消界面,默认是60030;
hbase.regionserver.info.bindAddress:regionserver的web绑定,默认是0.0.0.0;
hbase.regionserver.info.port.auto:master或者regionserver是否自动搜索绑定的端口,默认是false;
hbase.regionserver.handler.count:regionserver上rpc listener的个数,
http://kenwublog.com/hbase-performance-tuning把这个配置称为io线程数,其实雷同,就是说在regionserver上一个处理rpc的handler,默认是30;
hbase.regionserver.msginterval:regionserver向master发消息的间隔,默认3000毫秒;
hbase.regionserver.optionallogflushinterval:如果没有足够的entry触发同步,那么过了这个间隔后HLog将被同步到HDFS,默认是1000毫秒;
hbase.regionserver.regionSplitLimit:regionsplit的最大限额,默认是MAX_INT=2147483647,设置这个限制后,在到达限制时region split就不会再进行;
hbase.regionserver.logroll.period:不管有多少版本,直接roll掉commit log的周期,也就是说一个固定的时间周期,到期就roll,默认是3600000毫秒;
hbase.regionserver.logroll.errors.tolerated:可接受的WAL关闭错误个数,到达后将触发服务器终止;设置为0那么在WAL writer做log rolling失败时就停止region server,默认是2;
hbase.regionserver.hlog.reader.impl:HLog 文件reader的实现类,默认是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader;
hbase.regionserver.hlog.writer.impl:HLog 文件writer的实现类,默认是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter;
hbase.regionserver.global.memstore.upperLimit:memstore在regionserver内存中的上限,届时新的update被阻塞并且flush被强制写,默认是0.4就是堆内存的40%;阻塞状态持续到regionserver的所有memstore的容量到达hbase.regionserver.global.memstore.lowerLimit;
hbase.regionserver.global.memstore.lowerLimit:memstore在regionserver内存中的最大上限,到达时flush就被强制写,默认是0.38等价于38%的内存容量;
hbase.regionserver.optionalcacheflushinterval:一个edit版本在内存中的cache时长,默认3600000毫秒,设置为0的话则禁止自动flush;
hbase.regionserver.catalog.timeout:regionserver的Catalog Janitor访问META的超时时间,默认是600000;
hbase.regionserver.dns.interface:同master类似~~不讲
hbase.regionserver.dns.nameserver:同master类似
zookeeper.session.timeout:这是个值得说道一下的配置,首先ZK客户端要用,Hbase使用zk的客户端联系总体,同时也被用来启动一个zk server,作为zk的maxSessionTimeout,总的来说就是regionserver与zk的关键参数,如果连接超时,master会重新的balance,regionserver也会被从集群名单中清除,默认是90000;一个问题是如果zk 由hbase自己维护,那么该参数作为regionserver连接是一个值,如果zk在另外的集群,那么zk自己的maxSessionTimeout参数将优先于Hbase的该参数,届时可能会发生超时时间不同的问题;
zookeeper.znode.parent:znode存放root region的地址,默认是root-region-server;
zookeeper.znode.acl.parent:root znode的acl,默认acl;
hbase.zookeeper.dns.interface:zk的dns接口,默认default;
hbase.zookeeper.dns.nameserver:zk的dns服务地址,默认default;
hbase.zookeeper.peerport:zk的peer之间的通讯端口,默认是2888;
hbase.zookeeper.leaderport:zk选leader的通讯端口,默认是3888;
hbase.zookeeper.useMulti:zk支持多重update,要求zk在3.4版本以上,默认是false;
hbase.config.read.zookeeper.config:让hbaseconfig去读zk的config,默认false,也不支持开启,这个功能很搞笑~~个人观点;
hbase.zookeeper.property.initLimit:zk的配置,同步的属性个数限制,默认10个~~没用;
hbase.zookeeper.property.syncLimit:zk的配置,同步时的每次请求的条数,默认5个;
hbase.zookeeper.property.dataDir:zk的配置,snapshot存放的目录,默认是${hbase.tmp.dir}/zookeeper;
hbase.zookeeper.property.clientPort:zk的配置,client连zk的端口,默认2181;
hbase.zookeeper.property.maxClientCnxns:zk的配置,允许接入zk的最大并发连接数的限制,按ip分配,默认300;
Hbase配置项(2)
hbase的配置接上篇
hbase.client.write.buffer:htable客户端写缓冲区大小,默认是2097152BYTE,这个缓冲区就是为了写数据的临时存放,设置大了,浪费客户端和服务端的存储,设置小了,如果写的数据多,太多的RPC又带来网络开销,官方给的一个服务端存储耗费评估计算是:hbase.client.write.buffer*hbase.regionserver.handler.count,服务端的rs的处理handler个数也很关键;
hbase.client.pause:pause时长,在hbase发生get或其他操作fail掉的时候进行pause的时间长度,默认是100;
hbase.client.retries.number:发生操作fail时的重试次数,结合上一个指标一起来控制总的重试时间,默认是35;
hbase.client.max.total.tasks:一个HTable实例可以提交给集群的最大并发任务数,默认是100;
hbase.client.max.perserver.tasks:一个HTable实例给一台regionserver提交的最大并发任务数,默认是5;
hbase.client.max.perregion.tasks:客户端连接一台region的最大连接数,换句话说,当你有这么多个连接在region时,新的操作不被发送直到有操作完成,默认是1;
hbase.client.scanner.caching:做scanner的next操作时(如果再本地client没找到)缓存的数据行数,这个值的设置也需要权衡,缓存的多则快,但吃内存,缓存的少则需要多的拉数据,需要注意的事项是如果两次调用的时间差大于scanner的timeout,则不要设置该值,默认是100;
hbase.client.keyvalue.maxsize:一个KeyValue实例的最大大小,这是存储文件中一个entry的容量上限,合理的设置这个值可以控制regionserver的split,split不会拆keyvalue,所以把keyvalue的大小设置为regionserver大小的一个比例分数(可除)是个不错的选择,默认是10485760;
hbase.client.scanner.timeout.period:结合刚才的caching做的一个,scanner的超时时间,默认是60000毫秒;
hbase.client.localityCheck.threadPoolSize:做localityCheck的线程池大小,默认是2;
hbase.bulkload.retries.number:做bulk load的最大重试次数,默认是0,即代表不断重试;
hbase.balancer.period:Master运行balancer的周期,默认是300000毫秒;
hbase.regions.slop:如果有regionserver的region数目超过average+(average*slop),则rebalance,默认是0.2;
hbase.server.thread.wakefrequency:服务线程的sleep时间,默认10000毫秒,比如log roller;
hbase.server.versionfile.writeattempts:退出前写 version file的重试次数,默认3,每次尝试的间隔由上一个参数控制;
hbase.hregion.memstore.flush.size:Memstore写磁盘的flush阈值,超过这个大小就flush,默认是134217728;
hbase.hregion.preclose.flush.size:如果一个region的memstore的大小等于或超过这个参数的量,在关闭region时(放置关闭flag),要提前flush,然后region关闭下线,默认大小是5242880;
hbase.hregion.memstore.block.multiplier:如果memstore的大小满足hbase.hregion.block.memstore * hbase.hregion.flush.size个byte,那么阻塞update,这个配置可以避免不必要的长时间split或者compact,甚至是OOME,默认是2;
hbase.hregion.memstore.mslab.enabled:开启MemStore-Local Allocation Buffer,这个配置可以避免在高写入的情况下的堆内存碎片,可以降低在大堆情况下的stop-the-world GC频率,默认是true;
hbase.hregion.max.filesize:HStoreFile的最大尺寸,换句话说,当一个region里的列族的任意一个HStoreFile超过这个大小,那么region进行split,默认是10737418240;
hbase.hregion.majorcompaction:一个region的所有HStoreFile进行major compact的时间周期,默认是604800000 毫秒(7天);
hbase.hregion.majorcompaction.jitter:major compaction的发生抖动范围,这么理解比较容易,就是说上一个参数不是一个严格周期,会有个抖动,这个参数就是这个抖动的比例,默认是0.5;
hbase.hstore.compactionThreshold:一个HStore存储HStoreFile的个数阈值,超过这个阈值则所有的HStoreFile会被写到一个新的HStore,需要平衡取舍,默认是3;
hbase.hstore.blockingStoreFiles:一个HStore存储HStoreFile阻塞update的阈值,超过这个阈值,HStore就进行compaction,直到做完才允许update,默认是10;
hbase.hstore.blockingWaitTime:一个更强力的配置,配合上一个参数,当HStore阻塞update时,超过这个时间限制,阻塞取消,就算compaction没有完成,update也不会再被阻塞,默认是90000毫秒;
hbase.hstore.compaction.max:每个minor compaction的HStoreFile个数上限,默认是10;
hbase.hstore.compaction.kv.max:在flushing或者compacting时允许的最大keyvalue个数,如果有大的KeyValue或者OOME的话则配置一个小的值,如果行数多且小则配置大值,默认是10;
hbase.storescanner.parallel.seek.threads:如果并行查找开启的线程池大小,默认是10;
hfile.block.cache.size:一个配置比例,允许最大堆的对应比例的内存作为HFile和HStoreFile的block cache,默认是0.4,即40%,设置为0则disable这个比例,不推荐这么做;
hfile.block.index.cacheonwrite:在index写入的时候允许put无根(non-root)的多级索引块到block cache里,默认是false;
hfile.index.block.max.size:在多级索引的树形结构里,如果任何一层的block index达到这个配置大小,则block写出,同时替换上新的block,默认是131072;
hfile.format.version:新文件的HFile 格式版本,设置为1来测试向后兼容,默认是2;
hfile.block.bloom.cacheonwrite:对于组合布隆过滤器的内联block开启cache-on-write,默认是false;
io.storefile.bloom.block.size:一个联合布隆过滤器的单一块(chunk)的大小,这个值是一个逼近值,默认是131072;
hbase.rs.cacheblocksonwrite:当一个HFile block完成时是否写入block cache,默认是false;
Hbase配置项(3)
HBase的配置 完结篇:
hbase.rpc.server.engine:hbase 做rpc server的调度管理类,实现自org.apache.hadoop.ipc.RpcServerEngine,默认是org.apache.hadoop.hbase.ipc.ProtobufRpcServerEngine;
hbase.rpc.timeout:Hbase client发起远程调用时的超时时限,使用ping来确认连接,但是最终会抛出一个TimeoutException,默认值是60000;
hbase.rpc.shortoperation.timeout:另一个版本的hbase.rpc.timeout,控制短操作的超时时限,比如region server 汇报master的操作的超时时限可以设置小,这样有利于master的failover,默认是10000;
hbase.ipc.client.tcpnodelay:默认是true,具体就是在tcp socket连接时设置 no delay;
hbase.master.keytab.file:kerberos keytab 文件的全路径名,用来为HMaster做log,无默认值;
hbase.master.kerberos.principal:运行HMaster进程时需要kerberos的principal name,这个配置就是这个name的值,形如:
hbase/_HOST@EXAMPLE.COM
hbase.regionserver.keytab.file:kerberos keytab 文件的全路径名,用来为HRegionServer做log,无默认值;
hbase.regionserver.kerberos.principal:运行HRegionServer进程时需要kerberos的principal name,这个配置就是这个name的值,形如:
hbase/_HOST@EXAMPLE.COM
hadoop.policy.file:RPC服务器做权限认证时需要的安全策略配置文件,在Hbase security开启后使用,默认是habse-policy.xml;
hbase.superuser:Hbase security 开启后的超级用户配置,一系列由逗号隔开的user或者group;
hbase.auth.key.update.interval:Hbase security开启后服务端更新认证key的间隔时间:默认是86400000毫秒;
hbase.auth.token.max.lifetime:Hbase security开启后,认证token下发后的生存周期,默认是604800000毫秒;
hbase.ipc.client.fallback-to-simple-auth-allowed:client使用安全连接去链接一台非安全服务器时,服务器提示client切换到SASL SIMPLE认证模式(非安全),如果设置为true,则client同意切换到非安全连接,如果false,则退出连接;
hbase.coprocessor.region.classes:逗号分隔的Coprocessores列表,会被加载到默认所有表上。在自己实现了一个Coprocessor后,将其添加到Hbase的classpath并加入全限定名。也可以延迟加载,由HTableDescriptor指定;
hbase.rest.port:Hbase REST服务器的端口,默认是8080;
hbase.rest.readonly:定义REST服务器启动的模式,有两种方式,false:所有http方法都将被通过-GET/PUT/POST/DELETE,true:只有get方法ok。默认值是false;
hbase.rest.threads.max:REST服务器线程池的最大线程数,池满的话新请求会自动排队,限制这个配置可以控制服务器的内存量,预防OOM,默认是100;
hbase.rest.threads.min:同上类似,最小线程数,为了确保服务器的服务状态,默认是2;
hbase.rest.support.proxyuser:使REST服务器支持proxy-user 模式,默认是false;
hbase.defaults.for.version.skip:是否跳过hbase.defaults.for.version的检查,默认是false;
hbase.coprocessor.master.classes:由HMaster进程加载的coprocessors,逗号分隔,全部实现org.apache.hadoop.hbase.coprocessor.MasterObserver,同coprocessor类似,加入classpath及全限定名;
hbase.coprocessor.abortonerror:如果coprocessor加载失败或者初始化失败或者抛出Throwable对象,则主机退出。设置为false会让系统继续运行,但是coprocessor的状态会不一致,所以一般debug时才会设置为false,默认是true;
hbase.online.schema.update.enable:设置true来允许在线schema变更,默认是true;
hbase.table.lock.enable:设置为true来允许在schema变更时zk锁表,锁表可以组织并发的schema变更导致的表状态不一致,默认是true;
hbase.thrift.minWorkerThreads:线程池的core size,在达到这里配置的量级后,新线程才会再新的连接创立时创建,默认是16;
hbase.thrift.maxWorkerThreads:顾名思义,最大线程数,达到这个数字后,服务器开始drop连接,默认是1000;
hbase.thrift.maxQueuedRequests:Thrift连接队列的最大数,如果线程池满,会先在这个队列中缓存请求,缓存上限就是该配置,默认是1000;
hbase.thrift.htablepool.size.max:Thrift服务器上table pool的最大上限,默认是1000;
hbase.offheapcache.percentage:JVM参数-XX:MaxDirectMemorySize的百分比值,默认是0,即不开启堆外分配;
hbase.data.umask.enable:开启后,文件在regionserver写入时会有权限相关设定,默认是false不开启;
hbase.data.umask:开启上面一项配置后,文件的权限umask,默认是000;
hbase.metrics.showTableName:是否为每个指标显示表名前缀,默认是true;
hbase.metrics.exposeOperationTimes:是否进行关于操作在使用时间维度的指标报告,比如GET PUT DELETE INCREMENT等,默认是true;
hbase.snapshot.enabled:是否允许snapshot被使用、存储和克隆,默认是true;
hbase.snapshot.restore.take.failsafe.snapshot:在restore过程中,如果失败则启用snapshot替换,成功则删除掉snapshot,默认开启true;
hbase.snapshot.restore.failsafe.name:刚才所说过程中snapshot的名字,默认是hbase-failsafe-{snapshot.name}-{restore.timestamp};
hbase.server.compactchecker.interval.multiplier:检查是否需要compact的时间间隔,一般情况是在比如memstore flush后或者其他事件触发compact的,但是有时也需要不同的compact策略,所以需要周期性的检查具体间隔=hbase.server.compactchecker.interval.multiplier * hbase.server.thread.wakefrequency,默认1000;
hbase.lease.recovery.timeout:在dfs 租约超时时限,超时则放弃,默认是900000;
hbase.lease.recovery.dfs.timeout:dfs恢复租约调用的超时时限,默认是64000;

阅读更多
换一批

没有更多推荐了,返回首页