关于hbase的一些调优问题
来源：互联网 发布：女友生日送什么花 知乎 编辑：程序博客网 时间：2024/05/24 06:49
- 网络不好，导致RegionServer 和 HMaster通信超时，RegionServer被认为已经挂掉，从而退出集群 --网络问题，无法从软件方面解决，关于通信超时的设置下面做个简单介绍
- Java full GC ，这个过程会block所有的线程，如果此事件过长，导致Session expired 会话过期，导致退出集群--下文会阐述
- 各节点时间不一致，导致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默认是30s，但不要太大，毕竟时间不一致是不正常现象，可将所有节点和同一服务器时间做同步，也可以和时间服务器同步。
- HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ，而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
- 调用HQuorunPeer.runZKServer
- 调用QuorumPeerMain.runFromConfig
- 设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
- 由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置，默认是2*ticktime
- 适度增大守护进程的HeapSize
- 调整内存回收参数
- 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
- export HBASE_THRIFT_OPTS="$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
- export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
当然，上述是在hbase-env.sh中对jvm的调优，还需要在hbase-site.xml中注意一些配置项
上面这张图不是一太清晰，我后面给个单独的连接
这里的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的配置项简介：
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
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.optionalcacheflushinterv
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.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；
- 关于hbase的一些调优问题
- 关于Hbase的一些优化
- hbase 0.96的一些问题
- 关于近期HBase系统设计开发和性能调优的一些小结
- 关于近期HBase系统设计开发和性能调优的一些小结
- 关于HBase的一些零碎事
- 关于HBase的一些零碎事
- 关于HBASE过滤器的一些基本实例
- 关于hbase应用的一些看法
- 关于hbase过滤查询的一些
- 关于Hbase设计的一些意见
- 关于hbase中scan的一些总结
- HBase的一些问题和答案
- hadoop环境搭建hbase的一些问题
- hbase和hive的一些调优心得
- hadoop,hbase集群一些问题
- 关于Tapestry的一些问题
- 关于session的一些问题
- Win8如何查看已保存的无线网络
- POJ1035——Spell checker
- spring头
- Android-Creating an Input Method（IME）
- ios程序中的内存分配 栈区堆区全局区
- 关于hbase的一些调优问题
- 带头节点单链表的实现
- 空对象模式
- Cracking code interviews_1
- 黑马程序员--C语言自学笔记---13结构体、预编译、宏、条件编译
- 剑指offer--替换空格
- Java中Runnable和Thread的区别
- AM5728概述(3)
- HDU 2041 超级楼梯（DP）
