一次bug死磕经历之Hbase堆内存小导致regionserver频繁挂掉

[size=medium]
环境如下：
Centos6.5
Apache Hadoop2.7.1
Apache Hbase0.98.12
Apache Zookeeper3.4.6
JDK1.7
Ant1.9.5
Maven3.0.5

最近在测Hbase的压缩，Hadoop安装了lzo和snappy，插入50条文本数据，每条数据大约4M，来看他们的压缩率对比，
然后在测的过程中，发现用java客户端去scan这50条数据时，regionserver频繁宕机看hbase的log发现并无明显异常，查看datanode的log发现如下异常：
[/size]

java.io.IOException: Premature EOF from inputStream
        at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:201)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doReadFully(PacketReceiver.java:213)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:134)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:109)
        at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receivePacket(BlockReceiver.java:472)
        at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receiveBlock(BlockReceiver.java:849)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:804)
        at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:137)
        at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:251)
        at java.lang.Thread.run(Thread.java:745)

[size=medium]
截图如下，好吧，出异常了，就拿这个异常google查找结果，发现并没有明确的答案，大部分都是说链接超时，或者是句柄数满了，导致链接中断等等，然后就按这些答案，改了若干配置，发现依然没有生效，这领我感到十分奇怪 ，得出一个错误的结论，hbase不支持多种压缩类型并存的表，然后我去掉了其他类型用来压缩测试的表，再次测试，发现问题依旧，这再次令我十分诧异，会不会是环境的问题？因为我实在想不出来可能的问题所在了，然后就在本机虚拟机上进行测试，
虚拟机的环境，因为是自己用，所以JDK版本是1.8 和 Centos版本是7，Hbase，Hadoop，Zookeeper版本则保持一致，
搭建完毕后，继续测试，发现问题依旧，这下令人更迷惑了，看的出来非环境的问题了，不过这次有了点新的线索，由于用的是JDK8，在Hbase的log里面发现出现了大量的full gc日志，意思就是内存严重不足，导致垃圾收集时间出现了4,5秒，这下我才有点头绪，hbase是个吃内存的玩意，内存给的少，确实有可能导致regionserver挂掉，于是我查看hbase的堆内存分配情况，发现是默认的1G，这下确实跟这个有很大关系，50条数据占存储200M，如果每次scan一次，hbase会将其缓存在cache里面，第二次继续scan不同压缩类型的表，会导致内存膨胀，继而引发，regionserver宕机，而给出的异常提示，并不是非常明确，所以才定位问题比较困难，知道了大概原因所在，然后把hbase的堆内存调到4G，并分发到所有节点上，再次启动，用java 客户端，扫描全表测试，这次非常稳定，regionserver没有出现过再次挂掉的情况。

[/size]

[img]http://dl2.iteye.com/upload/attachment/0114/3169/abbad681-5eff-3fd9-bfbc-9a22dcf08fcf.png[/img]


[size=medium]
最后给出测试压缩的一个结论：总共测了4种压缩比较，原始数据200M
（1）不用压缩 占空间 128.1 M
（2）gz压缩 占920.3 K
（3）snappy压缩 占 13.2M
（4）lzo压缩 占8M

以上可以看出，gz的压缩比最高，lzo次之，snappy第三，当然不同的压缩适用于不用的业务场景，这里不能就简简单单的
总结必须用什么，这里面snappy和lzo在目前大多数互联网公司用的比较多，所以大家可以根据具体业务，来选择合适的压缩方案。
[/size]
[b][color=green][size=large]
最后欢迎大家扫码关注微信公众号：我是攻城师(woshigcs)，我们一起学习，进步和交流!（woshigcs）
本公众号的内容是有关搜索和大数据技术和互联网等方面内容的分享，也是一个温馨的技术互动交流的小家园，有什么问题随时都可以留言，欢迎大家来访！
[/size][/color][/b]
[img]http://dl2.iteye.com/upload/attachment/0104/9948/3214000f-5633-3c17-a3d7-83ebda9aebff.jpg[/img]