背景：我司作为某运营商公司的技术咨询公司，发现有第三方开发公司在使用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)相关原理简要分析
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使用技巧：
- 负责入库的需做好数据限制，谨慎修改 keyvalue max size 限制，脏数据或不重要的数据可适当裁剪或丢弃，实在较大的数据考虑存hdfs，hbase存路径去指向文件。
- 读取时需大致估算平均每行数据大小，并适当留出冗余的内存，来决定一个multi get的batch大小。不需要的列字段就尽量不要读，避免oom也可以节省性能。
- column family和qualifier尽可能短而精确，因为每一个keyvalue都会存qualifier。
- 如无必要，表的字段尽量不太太多。
- 动态qualifier慎用，除非你对你自己的数据有足够清楚的上限了解。
- （其他）索引表和数据表尽量分离，不然scan会带来额外不必要的开销。