标签：
环境如下：
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.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)
截图如下，好吧，出异常了，就拿这个异常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在目前大多数互联网公司用的比较多，所以大家可以根据具体业务，来选择合适的压缩方案。
一次bug死磕经历之Hbase堆内存小导致regionserver频繁挂掉
标签：
原文地址：http://www.cnblogs.com/qindongliang/p/5104589.html
