RegionServer与OOM不得不说的一些事儿

「爱情、让人受尽委屈。」 2022-08-08 06:58 171阅读 0赞

RegionServer进程运行中，可能会突然挂掉，RegionServer日志中看不到任何错误提示，也不会生成hs\_err\_pid.log之类的提示。相信许多同学遭遇过这种场景，此时，你应该想到罪魁祸首是OOM（OutOfMemory）。

对于OOM问题，我认为首要问题是：搞清楚RegionServer是被主动还是被动kill的？

**1. 先说说何为主动和被动？**

主动是指：如果RegionServer发现自己OOM，则自身主动请求去被kill；被动是指：RegionServer没有OOM，但是操作系统内存不够用了，于是OS会选择kill一些进程，那么内存大户RegionServer就可能被动的kill了。

**2. 再说说为何要区分主动和被动？**

如果是主动，那就说明是RegionServer方的原因。但是，你应该明白绝大部分是因为使用不当hbase引起的，而不是RegionServer的bug之类的问题。比如：应用中put一个超大的cell可能引发OOM（我在测试中就这么搞过......）。所以，你接下来的任务就是如何优化操作hbase的应用了。

如果是被动，说明机器中存在其它内存大户。此时，你需要考虑内存划分是否合理。如何合理，那就是某些应用的内存使用存在问题，这个更需要你来好好寻找了。比如在我遭遇的OOM场景下，就是这种情况，详细过程可以参考另一篇博文：[clouera-scm-agent进程内存高涨的一个案例][clouera-scm-agent]。

**3. 最后说说怎么区分主动和被动？**

3.1. 主动kill

其实RegionServer进程启动时，已经告诉JVM如何处理OOM了。

./jps -v|grep "Region"
    HRegionServer -Dproc_regionserver -XX:OnOutOfMemoryError=kill -9 %p -Xmx1000m -Djava.net.preferIPv4Stack=true -Xms16106127360 -Xmx16106127360 -XX:+UseG1GC -XX:MaxGCPauseMillis=6000 -XX:OnOutOfMemoryError=/usr/lib64/cmf/service/common/killparent.sh -Dhbase.log.dir=/data14/log/hbase -Dhbase.log.file=hbase-cmf-hbase-REGIONSERVER-cb8.log.out -Dhbase.home.dir=/opt/cloudera/parcels/CDH-5.2.0-1.cdh5.2.0.p0.36/lib/hbase -Dhbase.id.str= -Dhbase.root.logger=INFO,RFA -Djava.library.path=/opt/cloudera/parcels/CDH-5.2.0-1.cdh5.2.0.p0.36/lib/hadoop/lib/native -Dhbase.security.logger=INFO,RFAS

通过上述的jps命令，可以看到RegionServe告诉JVM：我要使用的最大内存为16106127360B，如果我出现了OOM，你就去执行/usr/lib64/cmf/service/common/killparent.sh吧。

killparent.sh脚本的主要代码就一行：kill -9 $PPID。$PPID表示父进程号，也就是JVM的进程号。

所以JVM监测到RegionServe的OOM后，将会fork一个子进程去执行这个脚本，于是，JVM就被kill了，当然RegionServer也就被kill了。

此时，你查看RegionServer的out文件，将会看到类似如下的提示：

# java.lang.OutOfMemoryError: Java heap space
    # -XX:OnOutOfMemoryError="kill -9 %p
    /usr/lib64/cmf/service/common/killparent.sh"
    #   Executing /bin/sh -c "kill -9 9192
    /usr/lib64/cmf/service/common/killparent.sh"...

此处说明一个小问题：上述snippet不是出现在RegionServer的日志文件里，而是在out文件里。不同的hbase封装版本，可能对这两类文件有不同的定义方式。比如CDH里面，就是/var/run/cloudera-scm-agent/process/\*-hbase-REGIONSERVER/logs/stdout.log，其中的\*为一个数字。

3.2. 被动kill

在linux的message日志中，可以看到类似如下的提示：

kernel: Out of memory: Kill process 38551 (java) score 501 or sacrifice child
    kernel: Killed process 38551, UID 483, (java) total-vm:17538500kB, anon-rss:16420056kB, file-rss:28kB
    kernel: java invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

上述日志表明：RegionServer进程(38551)被kill了。注意：total-vm:17538500kB, anon-rss:16420056kB应该是它占用的内存，而不是已经使用的内存。如果没有搞清楚这个区别，你可能会以为RegionServer已经超过max-heap-size了，那么kill就应该变成主动了。  
此处说明一个小问题：如何知道38551就是之前运行的RegionServer进程呢？RegionServer进程启动后，在其日志中可以看到如下类似的日志：

INFO org.apache.hadoop.hbase.util.ServerCommandLine: env:HBASE_ZNODE_FILE=/var/run/cloudera-scm-agent/process/5644-hbase-REGIONSERVER/znode38551

其中的38551就是进程号。

另附在本文探索过程中发现的一个小问题：如果/proc/sys/vm/overcommit\_memory设为0，则为-Xmx参数指定一个较大值时，可能会出现错误：

Error occurred during initialization of VM
    Failed to allocate initial heap.

此时，修改/proc/sys/vm/overcommit\_memory为1即可。原因就是因为在overcommit（过度分配）时，0是一种相当保守的策略，而1是一种相当开放的策略......这里描述比较朦胧，详细描述，大家可以百度一下。

[clouera-scm-agent]: http://blog.csdn.net/c77_cn/article/details/45871889