HBase 查询导致RegionServer OOM故障复盘

 

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

故障排查步骤

  1. 查看 regionserver的log和stdout。由于是突然宕机，log没有任何error信息，stdout 因为自动拉起以及默认启动脚本是重定向覆盖，所以被洗掉了；而oom dump当时还没开启，无任何明显提示信息。
  2. 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读缓存中。
  3. 尝试重新拉起regionserver，但由于业务方疏忽，他们表示已停了所有程序，但却依然没完全停止读取hbase程序，因此反复拉起regionserver失败，此时可看到日志  java.lang.OutOfMemoryError: Requested array size exceeds VM limit。
  4. 根据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的源码去确认是否真的修复。
  5. 由于业务方不知是对自己的数据不熟悉还是其他原因，一直不承认有大数据，于是我们通过反复实验定位找回了查询挂的语句，开了oom dump 获取了宕机前的内存快照。通过对ByteBuffer对象的分析和反二进制化，发现了挂机时其内存吃到了1g，按照capacity翻倍，再翻倍就是2g超出了数组上限，完全符合错误栈信息。
  6. 从快照里获取了一个看起来比较大的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)

相关原理简要分析

bucketcache

参考：HBase BlockCache系列 – 走进BlockCache HBase BlockCache系列 － 探求BlockCache实现机制

BlockCache是Region Server级别的，一个Region Server只有一个Block Cache，在Region Server启动的时候完成Block Cache的初始化工作。读数据时，会先访问blockcache，blockcache没数据则从hdfs读取数据尝试写入读缓存，写失败则会抛warning直接返回数据，否则从读缓存中返回数据。bucketcache是hbase读缓存blockcache的一种实现，听说是由阿里贡献的，其他的还有LRUBlockCache，SlabCache等。大致的发展可以梳理为 LRUBlockCache -> DoubleBlockCache(LRU + Slab) -> CombinedBlockCache(LRU+Bucket)。

bucketcache 可以配置四种模式：none禁用，heap堆内，off-heap堆外，file文件。一般推荐开启，file主要是针对ssd场景，off-heap配置不好会出现另外的direct memory OOM问题，具体计算较复杂，参见Configuring Off-heap Memory (BucketCache) - HortonWorks 。

bucketcache实际上和本次故障的直接关系不大，因为通过源码可以发现IPCUtil获取的outputstream只有堆上的ByteBufferOutputStream，只是其warning信息可以帮我们进一步佐证有异常过大数据的猜想。BucketCache的相关调用和实现逻辑可参见HFileReaderV2和BucketCache两个类。

Best Practice

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

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