HBase疑难杂症填坑指南

hbasegroup 发表了文章 • 1 个评论 • 804 次浏览 • 2018-12-28 18:06 • 来自相关话题

1.如何避免HBase写入过快引起的各种问题?
首先我们简单回顾下整个写入流程client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem



整个写入流程从客户端调用API开始,数据会通过protobuf编码成一个请求,通过socket实现的IPC模块被送达server的RPC队列中。最后由负责处理RPC的handler取出请求完成写入操作。写入会先写WAL文件,然后再写一份到内存中,也就是memstore模块,当满足条件时,memstore才会被flush到底层文件系统,形成HFile。
当写入过快时会遇见什么问题?
写入过快时,memstore的水位会马上被推高。
你可能会看到以下类似日志:RegionTooBusyException: Above memstore limit, regionName=xxxxx ...这个是Region的memstore占用内存大小超过正常的4倍,这时候会抛异常,写入请求会被拒绝,客户端开始重试请求。当达到128M的时候会触发flush memstore,当达到128M * 4还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下:hbase.hregion.memstore.flush.size=128M
hbase.hregion.memstore.block.multiplier=4或者这样的日志:regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size
regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms这是所有region的memstore内存总和开销超过配置上限,默认是配置heap的40%,这会导致写入被阻塞。目的是等待flush的线程把内存里的数据flush下去,否则继续允许写入memestore会把内存写爆hbase.regionserver.global.memstore.upperLimit=0.4 # 较旧版本,新版本兼容
hbase.regionserver.global.memstore.size=0.4 # 新版本当写入请求由于达到memstore上限而被阻塞,队列会开始积压,如果运气不好最后会导致OOM,你可能会发现JVM由于OOM crash或者看到如下类似日志:ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x
java.lang.OutOfMemoryError: Java heap spaceHBase这里我认为有个很不好的设计,捕获了OOM异常却没有终止进程。这时候进程可能已经没法正常运行下去了,你还会在日志里发现很多其它线程也抛OOM异常。比如stop可能根本stop不了,RS可能会处于一种僵死状态。
如何避免RS OOM?
一种是加快flush速度:hbase.hstore.blockingWaitTime = 90000 ms
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10当达到hbase.hstore.blockingStoreFiles配置上限时,会导致flush阻塞等到compaction工作完成。阻塞时间是hbase.hstore.blockingWaitTime,可以改小这个时间。hbase.hstore.flusher.count可以根据机器型号去配置,可惜这个数量不会根据写压力去动态调整,配多了,非导入数据多场景也没用,改配置还得重启。
同样的道理,如果flush加快,意味这compaction也要跟上,不然文件会越来越多,这样scan性能会下降,开销也会增大。hbase.regionserver.thread.compaction.small = 1
hbase.regionserver.thread.compaction.large = 1增加compaction线程会增加CPU和带宽开销,可能会影响正常的请求。如果不是导入数据,一般而言是够了。好在这个配置在云HBase内是可以动态调整的,不需要重启。
上述配置都需要人工干预,如果干预不及时server可能已经OOM了,这时候有没有更好的控制方法?hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G直接限制队列堆积的大小。当堆积到一定程度后,事实上后面的请求等不到server端处理完,可能客户端先超时了。并且一直堆积下去会导致OOM,1G的默认配置需要相对大内存的型号。当达到queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个可以防止写入过快时候把server端写爆,有一定反压作用。线上使用这个在一些小型号稳定性控制上效果不错。
填坑链接:如何避免HBase写入过快引起的各种问题 查看全部
1.如何避免HBase写入过快引起的各种问题?
首先我们简单回顾下整个写入流程
client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem
1.png

整个写入流程从客户端调用API开始,数据会通过protobuf编码成一个请求,通过socket实现的IPC模块被送达server的RPC队列中。最后由负责处理RPC的handler取出请求完成写入操作。写入会先写WAL文件,然后再写一份到内存中,也就是memstore模块,当满足条件时,memstore才会被flush到底层文件系统,形成HFile。
当写入过快时会遇见什么问题?
写入过快时,memstore的水位会马上被推高。
你可能会看到以下类似日志:
RegionTooBusyException: Above memstore limit, regionName=xxxxx ...
这个是Region的memstore占用内存大小超过正常的4倍,这时候会抛异常,写入请求会被拒绝,客户端开始重试请求。当达到128M的时候会触发flush memstore,当达到128M * 4还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下:
hbase.hregion.memstore.flush.size=128M 
hbase.hregion.memstore.block.multiplier=4
或者这样的日志:
regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size 
regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms
这是所有region的memstore内存总和开销超过配置上限,默认是配置heap的40%,这会导致写入被阻塞。目的是等待flush的线程把内存里的数据flush下去,否则继续允许写入memestore会把内存写爆
hbase.regionserver.global.memstore.upperLimit=0.4 # 较旧版本,新版本兼容 
hbase.regionserver.global.memstore.size=0.4 # 新版本
当写入请求由于达到memstore上限而被阻塞,队列会开始积压,如果运气不好最后会导致OOM,你可能会发现JVM由于OOM crash或者看到如下类似日志:
ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x 
java.lang.OutOfMemoryError: Java heap space
HBase这里我认为有个很不好的设计,捕获了OOM异常却没有终止进程。这时候进程可能已经没法正常运行下去了,你还会在日志里发现很多其它线程也抛OOM异常。比如stop可能根本stop不了,RS可能会处于一种僵死状态。
如何避免RS OOM?
一种是加快flush速度
hbase.hstore.blockingWaitTime = 90000 ms 
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10
当达到hbase.hstore.blockingStoreFiles配置上限时,会导致flush阻塞等到compaction工作完成。阻塞时间是hbase.hstore.blockingWaitTime,可以改小这个时间。hbase.hstore.flusher.count可以根据机器型号去配置,可惜这个数量不会根据写压力去动态调整,配多了,非导入数据多场景也没用,改配置还得重启。
同样的道理,如果flush加快,意味这compaction也要跟上,不然文件会越来越多,这样scan性能会下降,开销也会增大。
hbase.regionserver.thread.compaction.small = 1 
hbase.regionserver.thread.compaction.large = 1
增加compaction线程会增加CPU和带宽开销,可能会影响正常的请求。如果不是导入数据,一般而言是够了。好在这个配置在云HBase内是可以动态调整的,不需要重启。
上述配置都需要人工干预,如果干预不及时server可能已经OOM了,这时候有没有更好的控制方法?
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G
直接限制队列堆积的大小。当堆积到一定程度后,事实上后面的请求等不到server端处理完,可能客户端先超时了。并且一直堆积下去会导致OOM,1G的默认配置需要相对大内存的型号。当达到queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个可以防止写入过快时候把server端写爆,有一定反压作用。线上使用这个在一些小型号稳定性控制上效果不错。
填坑链接:如何避免HBase写入过快引起的各种问题

Hbase 写入过快OOM, 导致整个hbase挂掉.

回复

Nick 回复了问题 • 1 人关注 • 1 个回复 • 431 次浏览 • 2018-12-27 14:41 • 来自相关话题

hbase replication

回复

zhangleiHbase 发起了问题 • 1 人关注 • 0 个回复 • 189 次浏览 • 2018-12-26 19:42 • 来自相关话题

获取hbase表结构

beyond 回复了问题 • 2 人关注 • 1 个回复 • 309 次浏览 • 2018-12-26 12:28 • 来自相关话题

hbase 2.0 procedure卡住了

回复

zxpns18 发起了问题 • 1 人关注 • 0 个回复 • 185 次浏览 • 2018-12-21 10:56 • 来自相关话题

如何有效防止hbase被攻击

anbbrr 回复了问题 • 2 人关注 • 2 个回复 • 341 次浏览 • 2018-12-20 11:26 • 来自相关话题

多线程写入hbase

陈坤 回复了问题 • 3 人关注 • 3 个回复 • 373 次浏览 • 2018-12-18 16:54 • 来自相关话题

SnapshotScanMR的用法

回复

小勇 发起了问题 • 1 人关注 • 0 个回复 • 285 次浏览 • 2018-12-16 00:03 • 来自相关话题

hbase 日志洪灾 滚动报“requested wrong row”

回复

xint1ao 发起了问题 • 1 人关注 • 0 个回复 • 217 次浏览 • 2018-12-15 22:29 • 来自相关话题

hbase 2.0 启用MOB特性 regionserver出现卡住

WangYQ 回复了问题 • 2 人关注 • 1 个回复 • 392 次浏览 • 2018-12-14 13:26 • 来自相关话题

hbase scan 非常慢,如何着手定位并解决问题

WangYQ 回复了问题 • 3 人关注 • 2 个回复 • 482 次浏览 • 2018-12-14 13:25 • 来自相关话题

hbase 的hfile命令什么时候用得到,什么问题会考虑解析hfile

Sophie 回复了问题 • 3 人关注 • 1 个回复 • 250 次浏览 • 2018-12-12 03:44 • 来自相关话题

一个cdh的一个集群下可以搭建两个hbase集群吗?

回复

任强 发起了问题 • 2 人关注 • 0 个回复 • 246 次浏览 • 2018-12-11 10:27 • 来自相关话题

大scan造成内存溢出

beyond 回复了问题 • 2 人关注 • 1 个回复 • 287 次浏览 • 2018-12-10 09:54 • 来自相关话题

hbase: Cloudera manager免费版和付费版在管理hbase的实际使用中有什么区别吗?

beyond 回复了问题 • 2 人关注 • 1 个回复 • 245 次浏览 • 2018-12-07 10:48 • 来自相关话题

slow sync cost有什么办法优化吗?

beyond 回复了问题 • 3 人关注 • 3 个回复 • 464 次浏览 • 2018-12-07 09:32 • 来自相关话题

hbase2.0 一直rit

zxpns18 回复了问题 • 6 人关注 • 6 个回复 • 859 次浏览 • 2018-12-06 17:40 • 来自相关话题


中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群