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

环境以下： 
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发现以下异常：

Java代码  

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

 



截图以下，好吧，出异常了，就拿这个异常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没有出现过再次挂掉的状况。 








最后给出测试压缩的一个结论：总共测了4种压缩比较，原始数据200M （1）不用压缩   占空间 128.1 M  （2）gz压缩       占920.3 K （3）snappy压缩 占 13.2M （4）lzo压缩       占8M 以上能够看出，gz的压缩比最高，lzo次之，snappy第三，固然不一样的压缩适用于不用的业务场景，这里不能就简简单单的 总结必须用什么，这里面snappy和lzo在目前大多数互联网公司用的比较多，因此你们能够根据具体业务，来选择合适的压缩方案。