菜单

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

2018年11月16日 - Java

先是我们简要回顾下整个写副流程

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。


先是我们大概回顾下一切写副流程

图片 1

普写副流程从客户端调用API开始,数据会通过protobuf编码成一个告,通过scoket实现之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 # 新版本

当写副于打断,队列会开积压,如果运气不好最后见面造成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的水位会及时叫推进高。

乃或许会见看出以下类似日志:

图片 2

本条是Region的memstore占用内存大小超过健康的4加倍,这时候会抛大,写副请求会叫拒绝,客户端起重试请求。当上128M之时光会触发flush
memstore,当及128M *
4还没法触发flush时候会废弃大来拒绝写入。两个有关参数的默认值如下:

图片 3

要么这样的日记:

图片 4

当即是有着region的memstore内存总和付出超过配置上限,默认是布局heap的40%,这会招写副于打断。目的是等flush的线程把内存里的数flush下去,否则继续允许写副memestore会把内存写爆

图片 5

当写副于卡住,队列会初步积压,如果运气不好最后会招致OOM,你或许会见意识JVM由于OOM
crash或者看如下类似日志:

图片 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速度:

图片 7

当上hbase.hstore.blockingStoreFiles配置上限时,会造成flush阻塞等交compaction工作做到。阻塞时是hbase.hstore.blockingWaitTime,可以改小这个时刻。hbase.hstore.flusher.count可以根据机器型号去安排,可惜这数目不会见因写压力去动态调整,配多了,非导入数据差不多状况也尚无因此,改配置还得更开。

同的理,如果flush加快,意味这compaction也要是和达到,不然文件会越加多,这样scan性能会降,开销也会附加。

图片 8

加compaction线程会增多CPU和带富开销,可能会见潜移默化健康的请求。如果不是导入数据,一般而言是够了。好当这个布局于云HBase内是足以动态调整之,不需要重新开。

上述配置都待人工干预,如果干预不就server可能已经OOM了,这时候有没有发出双重好之主宰方式?

图片 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地图