HBase-2.0.3 & HBase-2.1.1版本内存泄漏

HBase Committer胡争提出的issue:
[HBASE-21551]Memory leak when use scan with STREAM at server side
https://issues.apache.org/jira/browse/HBASE-21551


问题摘要
通常顺序扫描的时候。为了可以避免频繁的Position Read,服务端采用STREAM类型。如果出现以下任何一种情况,由于泄漏导致的内存不足错误,HBase集群将遇到Region Server故障:
1.用户发起设置为使用STREAM读取类型的Scan操作;
2.用户发起设置为使用默认读取类型,读取扫描中涉及的超过4倍列族块大小(例如,默认为4 * 64KiB)的Scan操作;
3.运行Compaction。
问题描述
我们使用STREAM打开RegionServerScanner,如下所示:

RegionScannerImpl#initializeScanners
      |---> HStore#getScanner
                    |----------> StoreScanner()
                                        |-------> StoreFileScanner#getScannersForStoreFiles
                                                          |------> HStoreFile#getStreamScanner      #1

在#1中,将StoreFileReader放入ConcurrentHashMap streamReaders,但是在关闭StoreFile之前不会从streamReaders中删除StreamReader。
因此,如果使用流扫描很多次,则会展开HashMap streamReaders,通过heap-dump查看堆存储情况:


胡争发现此错误,因为当通过在集群中使用YCSB(RS的堆大小为50g)对扫描性能进行基准测试时,RS很容易在很长时间内Full GC(~110秒)。
根本原因
当有长时间运行的扫描时,Region Server进程会尝试使用面向顺序访问的不同API来优化访问。由于HBASE 2.0+的HBASE-20704错误,因此当扫描完成时Region Server无法释放相关资源。 HBase内部文件压缩过程始终使用相同的优化路径。
解决方法
升级到最新版本。通过将配置值“hbase.storescanner.pread.max.bytes”设置为MAX_INT可以最大限度地减少对此错误的影响,以避免对默认用户扫描进行优化。并且应该检查客户端以确保它们不会将STREAM读取类型传递给Scan API。这将对长时间Scan的性能产生严重影响。
压缩总是使用这种顺序优化的读取机制,因此下游用户需要在压缩发生后定期重新启动Region Server角色。
修复实现
https://github.com/apache/hbase/commit/3b854859f6fad44cbf31164374569a6ab23f3623
https://github.com/apache/hbase/commit/67ab8b888f8b393979624a2bd7d527fefd9dd6d7

在此感谢HBase Committer胡争Review细节。

你可能感兴趣的:(HBase-2.0.3 & HBase-2.1.1版本内存泄漏)