什么样避免HBase写副过快引起的各种问题

第一我们简要回顾下所有写副流程

client api ==> RPC ==>  server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to  filesystem

全方位写副流程从客户端调用API开始,数据会通过protobuf编码成一个要,通过scoket实现的IPC模块于送达server的RPC队列中。最后由于负责处理RPC的handler取出请求完成写入操作。写副会事先勾勒WAL文件,然后再度写一客到内存中,也就算是memstore模块,当满足条件时,memstore才见面给flush到脚文件系统,形成HFile。


首先我们简要回顾下任何写副流程

manbetx手机网页版 1

通写副流程从客户端调用API开始,数据会通过protobuf编码成一个请,通过scoket实现的IPC模块于送达server的RPC队列中。最后由当处理RPC的handler取出请求完成写入操作。写副会预先勾勒WAL文件,然后还写一客到外存中,也即是memstore模块,当满足条件时,memstore才会受flush到脚文件系统,形成HFile。

当写副过快时会受见什么问题manbetx手机网页版?

写副了不久时,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 # 新版本

当写副于打断,队列会起积压,如果命运不好最后会造成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可能会见处在同一种僵死状态。


当写副了不久时会见面临见什么问题?

描绘副过不久时,memstore的水位会即时让推高。

卿恐怕会见看以下类似日志:

manbetx手机网页版 2

这是Region的memstore占用内存大小超过正常的4倍增,这时候会抛大,写副请求会受驳回,客户端起来重试请求。当及128M之早晚会触发flush
memstore,当上128M *
4还没法触发flush时候会弃大来拒绝写入。两独相关参数的默认值如下:

manbetx手机网页版 3

或这样的日志:

manbetx手机网页版 4

当即是兼具region的memstore内存总和开超过配置上限,默认是部署heap的40%,这会招致写副于打断。目的是等待flush的线程把内存里的数flush下去,否则继续允许写副memestore会把内存写爆

manbetx手机网页版 5

当写副于卡住,队列会开始积压,如果运气不好最后见面招致OOM,你或会见发现JVM由于OOM
crash或者看到如下类似日志:

manbetx手机网页版 6

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内是可以动态调整的,不欲重新开。

怎避免RS OOM?

同一栽是加速flush速度:

manbetx手机网页版 7

当及hbase.hstore.blockingStoreFiles配置上限时,会造成flush阻塞等及compaction工作完。阻塞时是hbase.hstore.blockingWaitTime,可以改小这个时刻。hbase.hstore.flusher.count可以依据机器型号去安排,可惜是数额不会见冲写压力去动态调整,配多矣,非导入数据差不多状况为从没因此,改配置还得又开。

同等的理,如果flush加快,意味这compaction也要跟达到,不然文件会更加多,这样scan性能会落,开销也会见增大。

manbetx手机网页版 8

日增compaction线程会增多CPU和带富开销,可能会见潜移默化正常的请求。如果非是导入数据,一般而言是十足了。好以是布局在云HBase内是可以动态调整之,不欲再行开。

上述配置都需人工干预,如果干预不及时server可能已经OOM了,这时候有没有来再度好之主宰方式?

manbetx手机网页版 9

直接限制队列堆积的尺寸。当堆积到得程度后,事实上后面的呼吁等不顶server端处理终结,可能客户端先超时了。并且直接堆积下来会造成OOM,1G之默认配置需要相对大内存的型号。当及queue上限,客户端会收到CallQueueTooBigException 然后活动重试。通过之可防写副了快时把server端写爆,有自然反压作用。线及利用此当一部分小型号稳定性控制及效益不错。

原稿链接

上述配置都需要人工干预,如果干预不就server可能已经OOM了,这时候来没发出还好的操纵措施?
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G

一直限制队列堆积的深浅。当堆积到早晚水平后,事实上后面的伸手等不顶server端处理终结,可能客户端先超时了。并且直接堆积下来会促成OOM,1G之默认配置需要相对大内存的型号。当及queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个得防范写副了不久时把server端写爆,有一定反压作用。线上运用这个在部分小型号稳定性控制及力量是。

阅读原文

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图