Hbase超时机制
发布日期:2021-09-18 01:37:03 浏览次数:10 分类:技术文章

本文共 11686 字,大约阅读时间需要 38 分钟。

配置优化

zookeeper.session.timeout

默认值:3分钟(180000ms)
说明:RegionServer与Zookeeper间的连接超时时间。当超时时间到后,ReigonServer会被Zookeeper从RS集群清单中移除,HMaster收到移除通知后,会对这台server负责的regions重新balance,让其他存活的RegionServer接管.
调优:
这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低,可以减少因等待超时而被延长的failover时间。
不过需要注意的是,对于一些Online应用,RegionServer从宕机到恢复时间本身就很短的(网络闪断,crash等故障,运维可快速介入),如果调低timeout时间,反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时,HMaster就开始做balance了(让其他RS根据故障机器记录的WAL日志进行恢复)。当故障的RS在人工介入恢复后,这个balance动作是毫无意义的,反而会使负载不均匀,给RS带来更多负担。特别是那些固定分配regions的场景。

hbase.zookeeper.quorum

默认值:localhost
说明:hbase所依赖的zookeeper部署
调优:
部署的zookeeper越多,可靠性就越高,但是部署只能部署奇数个,主要为了便于选出leader。最好给每个zookeeper 1G的内存和独立的磁盘,可以确保高性能。hbase.zookeeper.property.dataDir可以修改zookeeper保存数据的路径。

hbase.regionserver.handler.count

默认值:10
说明:RegionServer的请求处理IO线程数。
调优:
这个参数的调优与内存息息相关。
较少的IO线程,适用于处理单次请求内存消耗较高的Big PUT场景(大容量单次PUT或设置了较大cache的scan,均属于Big PUT)或ReigonServer的内存比较紧张的场景。
较多的IO线程,适用于单次请求内存消耗低,TPS要求非常高的场景。设置该值的时候,以监控内存为主要参考。
这里需要注意的是如果server的region数量很少,大量的请求都落在一个region上,因快速充满memstore触发flush导致的读写锁会影响全局TPS,不是IO线程数越高越好。
压测时,开启,可以同时监控每次请求的内存消耗和GC的状况,最后通过多次压测结果来合理调节IO线程数。
这里是一个案例?,作者在SSD的机器上设置IO线程数为100,仅供参考。

hbase.hregion.max.filesize

默认值:256M
说明:在当前ReigonServer上单个Reigon的最大存储空间,单个Region超过该值时,这个Region会被自动split成更小的region。
调优:
小region对split和compaction友好,因为拆分region或compact小region里的storefile速度很快,内存占用低。缺点是split和compaction会很频繁。
特别是数量较多的小region不停地split, compaction,会导致集群响应时间波动很大,region数量太多不仅给管理上带来麻烦,甚至会引发一些Hbase的bug。
一般512以下的都算小region。

大region,则不太适合经常split和compaction,因为做一次compact和split会产生较长时间的停顿,对应用的读写性能冲击非常大。此外,大region意味着较大的storefile,compaction时对内存也是一个挑战。

当然,大region也有其用武之地。如果你的应用场景中,某个时间点的访问量较低,那么在此时做compact和split,既能顺利完成split和compaction,又能保证绝大多数时间平稳的读写性能。

既然split和compaction如此影响性能,有没有办法去掉?

compaction是无法避免的,split倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值,比如100G,就可以间接禁用自动split(RegionServer不会对未到达100G的region做split)。
再配合这个工具,在需要split时,手动split。
手动split在灵活性和稳定性上比起自动split要高很多,相反,管理成本增加不多,比较推荐online实时系统使用。

内存方面,小region在设置memstore的大小值上比较灵活,大region则过大过小都不行,过大会导致flush时app的IO wait增高,过小则因store file过多影响读性能。

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默认值:0.4/0.35
upperlimit说明:hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时,flush该region的所有memstore。RegionServer的flush是通过将请求添加一个队列,模拟生产消费模式来异步处理的。那这里就有一个问题,当队列来不及消费,产生大量积压请求时,可能会导致内存陡增,最坏的情况是触发OOM。
这个参数的作用是防止内存占用过大,当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时,HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。
lowerLimit说明: 同upperLimit,只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时,不flush所有的memstore。它会找一个memstore内存占用最大的region,做个别flush,此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中,表现为 “** Flush thread woke up with memory above low water.”
调优:这是一个Heap内存保护参数,默认值已经能适用大多数场景。
参数调整会影响读写,如果写的压力大导致经常超过这个阀值,则调小读缓存hfile.block.cache.size增大该阀值,或者Heap余量较多时,不修改读缓存大小。
如果在高压情况下,也没超过这个阀值,那么建议你适当调小这个阀值再做压测,确保触发次数不要太多,然后还有较多Heap余量的时候,调大hfile.block.cache.size提高读性能。
还有一种可能性是?hbase.hregion.memstore.flush.size保持不变,但RS维护了过多的region,要知道 region数量直接影响占用内存的大小。

hfile.block.cache.size

默认值:0.2

说明:storefile的读缓存占用Heap的大小百分比,0.2表示20%。该值直接影响数据读的性能。
调优:当然是越大越好,如果写比读少很多,开到0.4-0.5也没问题。如果读写较均衡,0.3左右。如果写比读多,果断默认吧。设置这个值的时候,你同时要参考?hbase.regionserver.global.memstore.upperLimit?,该值是memstore占heap的最大百分比,两个参数一个影响读,一个影响写。如果两值加起来超过80-90%,会有OOM的风险,谨慎设置。

hbase.hstore.blockingStoreFiles

默认值:7
说明:在flush时,当一个region中的Store(Coulmn Family)内有超过7个storefile时,则block所有的写请求进行compaction,以减少storefile数量。
调优:block写请求会严重影响当前regionServer的响应时间,但过多的storefile也会影响读性能。从实际应用来看,为了获取较平滑的响应时间,可将值设为无限大。如果能容忍响应时间出现较大的波峰波谷,那么默认或根据自身场景调整即可。

hbase.hregion.memstore.block.multiplier

默认值:2
说明:当一个region里的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时,block该region的所有请求,进行flush,释放内存。
虽然我们设置了region所占用的memstores总内存大小,比如64M,但想象一下,在最后63.9M的时候,我Put了一个200M的数据,此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size 2倍时,block所有请求,遏制风险进一步扩大。
调优: 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控,那么保持默认值即可。如果正常情况下,你的写请求量就会经常暴长到正常的几倍,那么你应该调大这个倍数并调整其他参数值,比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit,以预留更多内存,防止HBase server OOM。

hbase.hregion.memstore.mslab.enabled

默认值:true
说明:减少因内存碎片导致的Full GC,提高整体性能。
调优:详见 

hbase.client.scanner.caching

默认值:1
说明:scanner调用next方法一次获取的数据条数
调优:少的RPC是提高hbase执行效率的一种方法,理论上一次性获取越多数据就会越少的RPC,也就越高效。但是内存是最大的障碍。设置这个值的时候要选择合适的大小,一面一次性获取过多数据占用过多内存,造成其他程序使用内存过少。或者造成程序超时等错误(这个超时与hbase.regionserver.lease.period相关)。

hbase.regionserver.lease.period

默认值:60000
说明:客户端租用HRegion server 期限,即超时阀值。
调优:
这个配合hbase.client.scanner.caching使用,如果内存够大,但是取出较多数据后计算过程较长,可能超过这个阈值,适当可设置较长的响应时间以防被认为宕机。

上篇博文结合一起线上问题介绍了HBase客户端基于退避算法的重试机制,并分析得出在某些场景下如果重试策略设置不当会导致长时间的业务阻塞。除了重试机制外,业务童鞋最关心的就是超时机制了。客户端超时设置对整个系统的稳定性以及敏感性至关重要,一旦没有超时设置或超时时间设置过长,服务器端的长时间卡顿必然会引起客户端阻塞等待,进而影响上层应用。好在HBase提供了多个客户端参数设置超时,主要包括 hbase.rpc.timeout / hbase.client.operation.timeout / hbase.client.scanner.timeout.period。然而这些参数官方并没有给出具体的介绍,导致开发人员并不真正理解这些参数的含义。接下来本文分别对这三个参数进行介绍,应用童鞋可以根据自己的实际情况对这三个参数进行设置。

hbase.rpc.timeout

从字面意思就可知道,该参数表示一次RPC请求的超时时间。如果某次RPC时间超过该值,客户端就会主动关闭socket。此时,服务器端就会捕获到如下的异常:

java.io.IOException: Connection reset by peer        at sun.nio.ch.FileDispatcherImpl.read0(Native Method)        at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)        at sun.nio.ch.IOUtil.read(IOUtil.java:197)        at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:384)        at org.apache.hadoop.hbase.ipc.RpcServer.channelRead(RpcServer.java:2246)        at org.apache.hadoop.hbase.ipc.RpcServer$Connection.readAndProcess(RpcServer.java:1496)....2016-04-14 21:32:40,173 WARN  [B.DefaultRpcServer.handler=125,queue=5,port=60020] ipc.RpcServer: RpcServer.respondercallId: 7540 service: ClientService methodName: Multi size: 100.2 K connection: 10.160.247.139:56031: output error2016-04-14 21:32:40,173 WARN  [B.DefaultRpcServer.handler=125,queue=5,port=60020] ipc.RpcServer: B.DefaultRpcServer.handler=125,queue=5,port=60020: caught a ClosedChannelException, this means that the server was processing a request but the client went away. The error message was: null

上述异常经常发生在大量高并发读写业务或者服务器端发生了比较严重的Full GC等场景下,导致某些请求无法得到及时处理,超过了时间间隔。该值默认大小为60000ms,即1min。

hbase.client.operation.timeout

该参数表示HBase客户端发起一次数据操作直至得到响应之间总的超时时间,数据操作类型包括get、append、increment、delete、put等。很显然,hbase.rpc.timeout表示一次RPC的超时时间,而hbase.client.operation.timeout则表示一次操作的超时时间,有可能包含多个RPC请求。举个例子说明,比如一次Put请求,客户端首先会将请求封装为一个caller对象,该对象发送RPC请求到服务器,假如此时因为服务器端正好发生了严重的Full GC,导致这次RPC时间超时引起SocketTimeoutException,对应的就是hbase.rpc.timeout。那假如caller对象发送RPC请求之后刚好发生网络抖动,进而抛出网络异常,HBase客户端就会进行重试,重试多次之后如果总操作时间超时引起SocketTimeoutException,对应的就是hbase.client.operation.timeout。

hbase.client.scanner.timeout.period

看到这里为止,很多细心的童鞋都会发现,hbase.client.operation.timeout参数规定的超时基本涉及到了HBase所有的数据操作,唯独没有scan操作。然而scan操作却是最有可能发生超时的,也因此是用户最为关心的。HBase当然考虑到了这点,并提供了一个单独的超时参数进行设置:hbase.client.scanner.timeout.period。这个参数理解起来稍微有点复杂,需要对scan操作本身有比较全面的理解,这可能也是很多业务用户并不了解的地方。

首先,我们来看一个最简单的scan操作示例:

public static void scan() {    
HTable table=(HTable) getHTablePool().getTable(
"tb_stu");
Scan scan=
new Scan();
scan.setMaxResultSize(
10000);
scan.setCacheing(
500);
ResultScanner rs = table.getScanner(scan);
for (Result r : rs) {
for (KeyValue kv : r.raw()) {
System.out.println(String.format(
"row:%s, family:%s, qualifier:%s, qualifiervalue:%s, timestamp:%s.”,
Bytes.toString(kv.getRow()),
Bytes.toString(kv.getFamily()),
Bytes.toString(kv.getQualifier()),
Bytes.toString(kv.getValue()),
kv.getTimestamp()));
}

很多人都会误认为一次scan操作就是一次RPC请求,实际上,一次请求大量数据的scan操作可能会导致多个很严重的后果:服务器端可能因为大量io操作导致io利用率很高,影响其他正常业务请求;大量数据传输会导致网络带宽等系统资源被大量占用;客户端也可能因为内存无法缓存这些数据导致OOM。基于此,HBase会将一次大的scan操作根据设置条件拆分为多个RPC请求,每次只返回规定数量的结果。上述代码中foreach(Result r :rs)语句实际上等价于Result r = rs.next(),每执行一次next()操作就会调用客户端发送一次RPC请求,参数hbase.client.scanner.timeout.period就用来表示这么一次RPC请求的超时时间,默认为60000ms,一旦请求超时,就会抛出SocketTimeoutException异常。

讲到这里,就借用宝地引申地讲讲另外两个相关的问题:

1.  上文提到一次大的scan操作会被拆分为多个RPC请求,那到底会拆分为多少个呢?

一次scan请求的RPC次数主要和两个因素相关,一个是本次scan的待检索条数,另一个是单次RPC请求的数据条数,很显然,两者的比值就是RPC请求次数。

一次scan的待检索条数由用户设置的条件决定,比如用户想一次获取某个用户最近一个月的所有操作信息,这些信息总和为10w条,那一次scan总扫瞄条数就是10w条。为了防止一次scan操作请求的数据量太大,额外提供了参数maxResultSize对总检索结果大小进行限制,该参数表示一次scan最多可以请求的数据量大小,默认为-1,表示无限制。

单次RPC请求的数据条数由参数caching设定,默认为100条。因为每次RPC请求获取到数据都会缓存到客户端,因此该值如果设置过大,可能会因为一次获取到的数据量太大导致客户端内存oom;而如果设置太小会导致一次大scan进行太多次RPC,网络成本高。

具体使用可以参考上文代码示例。

2. 经常有业务童鞋问道,在scan过程中RegionServer端偶尔抛出leaseException,是怎么回事?

看到leaseException就会想到租约机制,的确,HBase内部在一次完整的scan操作中引入了租约机制。为什么需要租约机制?这和整个scan操作流程有莫大的关系,上文讲到,一次完整的scan通常会被拆分为多个RPC请求,实际实现中,RegionServer接收到第一次RPC请求之后,会为该scan操作生成一个全局唯一的id,称为scanId。除此之外,RegionServer还会进行大量的准备工作,构建整个scan体系,构造需要用到的所有对象,后续的RPC请求只需要携带相同的scanId作为标示就可以直接利用这些已经构建好的资源进行检索。也就是说,在整个scan过程中,客户端其实都占用着服务器端的资源,此时如果此客户端意外宕机,是否就意味着这些资源永远都不能得到释放呢?租约机制就是为了解决这个问题。RegionServer接收到第一次RPC之后,除了生成全局唯一的scanId之外还会生成一个携带有超时时间的lease,超时时间可以通过参数hbase.regionserver.lease.period配置,一旦在超时时间内后续RPC请求没有到来(比如客户端处理太慢),RegionServer就认为客户端出现异常,此时会将该lease销毁并将整个scan所持有的资源全部释放,客户端在处理完成之后再发后续的RPC过来,检查到对应的lease已经不存在,就会抛出如下leaseExcption:

org.apache.hadoop.hbase.regionserver.LeaseException: lease '-8841369309248784313’ does not exist        at org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:230)        at org.apache.hadoop.hbase.regionserver.HRegionServer.next(HRegionServer.java:1847)        at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)        at java.lang.reflect.Method.invoke(Method.java:597)        at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570)      at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)

写在最后

一旦发生超时异常,很多童鞋的第一反应是会将超时时间设长。可以负责任的说,这样的处理是盲目的,不仅不能从本质上解决问题,还会使得整个系统处于特别不敏感的状态,在某些异常情况下,客户端就会因为超时时间设置太长而一直阻塞,进而导致上层业务长时间卡顿。因此在大多数情况下都不建议将超时时间设大,推荐的方法是找到超时的原因,分析超时原因是否可以避免。

文章最后再说说如何设置超时,用户可以通过修改配置文件hbase-site.xml来设置这几个参数,也可以通过代码的方式进行设置,如下所示:

Confiuration conf = HBaseConfiguration.create();    
conf.setInt(
"hbase.rpc.timeout",
20000);
conf.setInt(
"hbase.client.operation.timeout”,30000);
conf.setInt("hbase.client.scanner.timeout.period
",20000);
HTable table = new HTable(conf,"tableName
");
 
转自:http://hbasefly.com/2016/06/11/hbase-client-2/?utm_source=tuicool&utm_medium=referral

转载地址:https://blog.csdn.net/yue_2018/article/details/102909306 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:Linux13款工具
下一篇:国际三大主流ETL工具选型分析

发表评论

最新留言

初次前来,多多关照!
[***.217.46.12]2024年03月19日 00时57分56秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章

java怎样将日期本土化_Java中的日期操作 2019-04-21
java生产者消费者模型到精通_java生产者消费者模型 2019-04-21
java 执行 awk_3.1 biostar lesson3 linux学习日记;java版本;awk 2019-04-21
java二叉树求权值_百度笔试题目:二叉树路径权值和【转】 2019-04-21
欧亚马 java折叠车_如何选择欧亚马折叠车? 2019-04-21
python函数代码块以什么开头_Python初体验-开篇 代码全析 2019-04-21
java闹钟程序设计_JAVA课程设计_闹钟的设计与实现项目-报告_附源代码.doc 2019-04-21
java中的无效的列类型_java.sql.SQLException: 无效的列类型: 1111 2019-04-21
php rewrite url_PHP_URL Rewrite的设置方法,URL Rewrite需要服务器的支持! - phpStudy 2019-04-21
php读取大文件某行内容,PHP读取和修改大文件的某行内容_PHP教程 2019-04-21
打印php错误日志,php怎样打印错误日志 2019-04-21
Calendar导入java,Java程序使用Calendar.add()方法将分钟添加到当前时间 2019-04-21
mysql中用户线程作用,mysql用户线程的建立与用户线程的状态源码解析 2019-04-21
php页面引用公共文件,WeiPHP插件模板中快速引入公共模板文件 2019-04-21
php tracy,admin.php 2019-04-21
php访问父类的所有属性,php – 在父类中使用$this仅在子类中显示父类属性 2019-04-21
oracle比较强大的函数,SQL和ORACLE函数比较 2019-04-21
oracle12c order by,oracle 数据库中order by 的一些高级用法 2019-04-21
oracle8i substr,Oracle中的INSTR,NVL和SUBSTR函数的用法详解 2019-04-21
导出oracle11g的空表,轻松解决oracle11g 空表不能 exp 导出 的问题。 2019-04-21