环境如下:
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发现如下异常:

  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)
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频繁挂掉的更多相关文章

  1. 【死磕Java并发】-----Java内存模型之happend-before

    在上篇博客([死磕Java并发]-–深入分析volatile的实现原理)LZ提到过由于存在线程本地内存和主内存的原因,再加上重排序,会导致多线程环境下存在可见性的问题.那么我们正确使用同步.锁的情况下 ...

  2. 【死磕Java并发】-----Java内存模型之happens-before

    在上篇博客([死磕Java并发]-–深入分析volatile的实现原理)LZ提到过由于存在线程本地内存和主内存的原因,再加上重排序,会导致多线程环境下存在可见性的问题.那么我们正确使用同步.锁的情况下 ...

  3. 【死磕Java并发】-----Java内存模型之重排序

    在执行程序时,为了提供性能,处理器和编译器常常会对指令进行重排序,但是不能随意重排序,不是你想怎么排序就怎么排序,它需要满足以下两个条件: 在单线程环境下不能改变程序运行的结果: 存在数据依赖关系的不 ...

  4. 【原创】大叔问题定位分享(1)HBase RegionServer频繁挂掉

    最近hbase集群很多region server挂掉,查看其中一个RegionServer1日志发现,17:17:14挂的时候服务器压力很大,有大量的responseTooSlow,也有不少gc,但是 ...

  5. 【死磕Java并发】----- 死磕 Java 并发精品合集

    [死磕 Java 并发]系列是 LZ 在 2017 年写的第一个死磕系列,一直没有做一个合集,这篇博客则是将整个系列做一个概览. 先来一个总览图: [高清图,请关注"Java技术驿站&quo ...

  6. 【死磕 Spring】—– IOC 之解析Bean:解析 import 标签

    原文出自:http://cmsblogs.com 在博客[死磕Spring]----- IOC 之 注册 BeanDefinition中分析到,Spring 中有两种解析 Bean 的方式.如果根节点 ...

  7. 死磕 java集合之CopyOnWriteArraySet源码分析——内含巧妙设计

    问题 (1)CopyOnWriteArraySet是用Map实现的吗? (2)CopyOnWriteArraySet是有序的吗? (3)CopyOnWriteArraySet是并发安全的吗? (4)C ...

  8. Netty环境搭建 (源码死磕2)

    [正文]netty源码  死磕2: 环境搭建 本小节目录 1. Netty为什么火得屌炸天? 1.1. Netty是什么? 1.2. Netty火到什么程度呢? 1.3. Netty为什么这么火? 2 ...

  9. EventLoop(netty源码死磕4)

    精进篇:netty源码  死磕4-EventLoop的鬼斧神工 目录 1. EventLoop的鬼斧神工 2. 初识 EventLoop 3. Reactor模式回顾 3.1. Reactor模式的组 ...

随机推荐

  1. 使用CGIHTTPServer搭建简单网站

    目录 一.前提准备 二.搭建web网站 如何快速搭建web网站?这个问题对于我这样的小白来说简直就是一脸懵逼毫无头绪.在学习python的过程接触到了 CGI 编程,至于CGI是什么?怎么运行的?这我 ...

  2. 关于SecureCRT链接服务器出现乱码的问题

    连接到服务器,选择上方的“选项”->“会话选项”->“外观”->右边的字符编码->utf-8

  3. [学习笔记] $Maximum$ $Minimum$ $identity$

    \(Maximum\) \(Minimum\) \(identity\)学习笔记 比较好玩的一个科技.具体来说就是\(max(a,b)=a+b-min(a,b)\),这个式子是比较显然的,但是这个可以 ...

  4. NX二次开发-UFUN创建表达式UF_MODL_create_exp_tag有TAG

    NX9+VS2012 #include <uf.h> #include <uf_modl.h> UF_initialize(); //创建一个新的表达式,无TAG UF_MOD ...

  5. js Date.parse() format.

    date format android chrome linux chrome Mobile safari ios chrome windows safari linux firefox window ...

  6. 牛客多校第九场 E All men are brothers 并查集/组合论

    题意: 一开始有n人互不认识,每回合有两个人认识,认识具有传递性,也就是相互认识的人组成小团体.现在问你每个回合,挑选四个人,这四个人互不认识,有多少种挑选方法. 题解: 认识不认识用并查集维护即可, ...

  7. 暴力”注入Explorer

    暴力"注入Explorer                      pjf(jfpan20000@sina.com)         向一个运行中的进程注入自己的代码,最自然莫过于使用Cr ...

  8. JVM内核-原理、诊断与优化学习笔记(八):JAVA堆分析

    文章目录 内存溢出(OOM)的原因 在JVM中,有哪些内存区间? 堆溢出 永久区 Java栈溢出 直接内存溢出 小问题? MAT使用基础 柱状图显示 支配树 显示线程信息 显示堆总体信息,比如消耗最大 ...

  9. 如何在Spring Boot 中动态设定与执行定时任务

    本篇文章的目的是记录并实现在Spring Boot中,动态设定与执行定时任务. 我的开发项目是 Maven 项目,所以首先需要在 pom.xml 文件中加入相关的依赖.依赖代码如下所示: <de ...

  10. 【工具原则】5W2H法学习笔记

    目录 问题描述 事件(原因)描述 任务描述 方案决策 小结 5W2H法又叫七问分析法,是二战中美国陆军兵器修理部首创.按事务构成要素,从规范的七个方面思考,避免疏忽遗漏. 可以应用在:问题描述.事件描 ...