环境如下:
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代码
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)
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在目前大多数互联网公司用的比较多,所以大家可以根据具体业务,来选择合适的压缩方案。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
当前文章:一次bug死磕经历之Hbase堆内存小导致regionser-创新互联
URL分享:http://scpingwu.com/article/dcgsdi.html