HBase 查询导致RegionServer OOM故障复盘

最新推荐文章于 2023-07-31 10:58:11 发布

weixin_30387799

最新推荐文章于 2023-07-31 10:58:11 发布

阅读量258

点赞数

原文链接：http://www.cnblogs.com/lhfcws/p/6346834.html

版权

背景：我司作为某运营商公司的技术咨询公司，发现有第三方开发公司在使用HBase 1.1.2 （HDP 2.4.2.258版本）一段时间使用正常后，从某一天开始报OOM，从而导致RegionServer宕机。

故障排查步骤

查看 regionserver的log和stdout。由于是突然宕机，log没有任何error信息，stdout 因为自动拉起以及默认启动脚本是重定向覆盖，所以被洗掉了；而oom dump当时还没开启，无任何明显提示信息。
regionserver的log中尽管没有发现error信息，但发现了许多warning，BucketCache: Failed allocation for ${block_id}，org.apache.hadoop.hbase.io.hfile.bucket.BucketAllocatorException: Allocation too big size=21342038。这虽然不是错误，但其实是个很有用的提示信息，说明可能存在着有许多大的block，无法写入bucketcache读缓存中。
尝试重新拉起regionserver，但由于业务方疏忽，他们表示已停了所有程序，但却依然没完全停止读取hbase程序，因此反复拉起regionserver失败，此时可看到日志 java.lang.OutOfMemoryError: Requested array size exceeds VM limit。
根据stacktrace进去读源码，发现是在做rpc fetch data的时候，ByteBufferOutputStream对象时用一个数组cache数据，bytes超过capacity上限后会把当前的capacity乘以2，new一个新的byte数组，把旧的数组内容copy到新的去。这种底层的类似c的写法可以减少对象和随机读内存的开销。但是源码很蠢，分配的上限是Integer.MAX_VALUE，而众所周知，Oracle/OpenJDK 7的数组只允许开到 Integer.MAX_VALUE - 2 ，因为用户一个查询过大，即使内存和网络足够好也会OOM导致RegionServer宕机，这明显是个bug。[HBase 14978] [HBase 14946] 从issue看应该是在1.2.0以后加了对multi的限制，尝试从服务前端避免这种问题发生，但本人尚未仔细阅读1.2.0的源码去确认是否真的修复。
由于业务方不知是对自己的数据不熟悉还是其他原因，一直不承认有大数据，于是我们通过反复实验定位找回了查询挂的语句，开了oom dump 获取了宕机前的内存快照。通过对ByteBuffer对象的分析和反二进制化，发现了挂机时其内存吃到了1g，按照capacity翻倍，再翻倍就是2g超出了数组上限，完全符合错误栈信息。
从快照里获取了一个看起来比较大的rowkey，get出来整个row有38m。而后我们又写了个scan程序对全表scan并统计size，发现整体几百k以上的数据也不少，还有少部分是10m以上的。在他们的20000/batch 的multi-get的场景，基本很容易挂。拿出数据与业务方对峙后，业务方承认数据可能是存在脏数据，他们之前实际遇到过类似问题。在写入时报了 keyvalue size too large 的问题，但他们毫不在意，把配置的size改成了512m就写入算了。

至此，故障已被成功排查。对于咨询团队来说，主要的任务已经完成了。

附：OOM错误完整 stacktrace

FATAL [IndexRpcServer.handler=5,queue=0,port=60020J regionserver.HRegionServer： Run out of memory； HRegionServer will abort itself immediately
java.lang.OutOfMemoryError： Requested array size exceeds VM limit 
    at  java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57) 
    at  java.nio.ByteBuffer.allocate(ByteBuffer.java：331) 
    at org.apache.hadoop.hbase.io.ByteBufferOutputStream.checkSizeAnd6row(ByteBufferOutputStream.java：74) 
    at org.apache.hadoop.hbase.io.ByteBufferOutputStream.write(ByteBufferOutputStream.java：112) at org.apache.hadoop.hbase.KeyValue.oswrite{KeyVdlue.java：2881) 
    at org.apache.hadoop.hbase.codec.KeyValueCodec^KeyVdlueEncoder.writetKeyVdlueCodec.java：60) 
    at  org.apache.hadoop.hbase.ipc.IPCUtil.buildCeilBlock(IPCUti1.java：120)    at org.apache.hadoop.hbase.ipc.RpcServer$Call.setResponse(RpcServer.java：384)
    at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java：128)
    at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java：112)
    at org.apache.hadoop.hbase.ipc.RpcExecutor$l.run(RpcExecutor.java：92)
    at java.lang.Th read.run(Th read.java:745)

Best Practice

避免此类问题，须注意如下HBase使用技巧：

负责入库的需做好数据限制，谨慎修改 keyvalue max size 限制，脏数据或不重要的数据可适当裁剪或丢弃，实在较大的数据考虑存hdfs，hbase存路径去指向文件。
读取时需大致估算平均每行数据大小，并适当留出冗余的内存，来决定一个multi get的batch大小。不需要的列字段就尽量不要读，避免oom也可以节省性能。
column family和qualifier尽可能短而精确，因为每一个keyvalue都会存qualifier。
如无必要，表的字段尽量不太太多。
动态qualifier慎用，除非你对你自己的数据有足够清楚的上限了解。
（其他）索引表和数据表尽量分离，不然scan会带来额外不必要的开销。

转载于:https://www.cnblogs.com/lhfcws/p/6346834.html