环境如下: Centos6.5 Apache hadoop2.7.1 Apache HBase0.98.12 Apache ZooKeeper3.4.6 jdk1.7 Ant1.9.5 Maven3.0.
环境如下:
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在目前大多数互联网公司用的比较多,所以大家可以根据具体业务,来选择合适的压缩方案。
--结束END--
本文标题: 一次bug死磕经历之Hbase堆内存小导致regionser
本文链接: https://lsjlt.com/news/39485.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0