Apache HBase 常见问题分析

  • A+
所属分类:体育平台

阅读本文可以带着下面问题:

1、HBase 遇到问题,可以从哪几个方面解决问题?

2、HBase 个别请求为什么很慢?你认为是什么原因?

3、客户端读写请求为什么大量出错?该从哪方面来分析?

4、大量服务端 Exception,一般原因是什么?

5、系统越来越慢的原因是什么?

6、HBase 数据写进去,为什么会没有了,可能的原因是什么?

7、RegionServer 发生 Abort ,遇到最多的是什么情况?

8、从哪些方面可以判断 HBase 集群是否健康?

9、为了加强 HBase 的安全性,你会采取哪些措施?

问题分析主要手段

(1)监控系统:首先用于判断系统各项指标是否正常,明确系统目前状况

(2)服务端日志:查看例如 region 移动轨迹,发生了什么动作,服务端接受处理了哪些客户端请求

(3)gc日志:GC 情况是否正常

(4)操作系统日志和命令:操作系统层面,硬件是否故障,当前状态如何

(5)btrace:实时跟踪目前服务端的请求和处理情况

(6)运维工具:可以结合 Arthas 分析定位线上 HBase 问题,通过内置于系统中的功能,不过各有各的用法,下面我会通过常见问题来梳理这 6 大手段

常见问题1:个别请求为什么很慢?

个别请求慢是用户遇到最多的问题,首先需要明确是客户端还是服务端的原因,进而分析服务端状况以及捕获这些请求来明确定位。

(1)通过客户端日志来初步分析下慢请求的规律,尝试在客户端确定请求的 rowkey 和操作类型。

(2)确定是不是一段时间内集中出现慢请求,如果是,那么可以参考常见问题 2 来解决。

(3)查看服务端监控,观察响应时间是否平稳,maxResponseTime 是否出现峰值。如果存在,那么可以初步确定是服务端问题。

(4)客户端分析无效,可以通过运维工具在服务端捕获请求的 rowkey 和 操作类型。

(5)确定 rowkey 对应的 region,初步查看是否存在数据表参数配置不合理(例如 version 设置过多,blockcache、bloomfilter 类型不正确、storefile 过多,命中率过低等问题)。

(6)尝试重试这些请求或者直接分析 hfile 来查看返回结果是否过大,请求是否耗费资源过多。

(7)查看服务端关于 hdfs 的监控和日志,以及 datanode 日志,来分析是否存在 hdfs 块读取慢或者磁盘故障。

常见问题2:客户端读写请求为什么大量出错?

读写请求大量出错的现象主要有两类:

  • 大量出现服务端 Exception
  • 大量超时,其中第一种有异常信息较好判断问题所在

(1)大量服务端 Exception 一般是 region 不在线导致的,可能是 region 在 split ,但是时间很长超过了预期,或者是 meta 数据错误导致客户端获取 region location 错误。以上现象均可通过日志来定位。

(2)遇到大量超时,首先应该排除服务端是否出现了 full gc 或者 ygc 时间过长。前者可能由于内存碎片、CMS GC 速度来不及导致,后者一般是由于系统使用了 swap 内存。

(3)通过系统命令和日志来查看是否有机器 load 过高,磁盘压力过大,磁盘故障。

(4)查看监控是否出现 callqueue 积压,请求无法得到及时处理,进一步通过 call 查看工具或者 jstack 可以查看正在处理的 call 和进程堆栈信息。

(5)通过 datanode 日志和 hbase 访问 hdfs 的时间,来判断问题是否在 hdfs 层。

(6)查看监控判断是否出现 blocking update,memstore 是否已接近系统设置的上限。

常见问题3:系统为什么越来越慢了?

系统原来挺快的,为什么越来越慢?多数是不合理的服务端配置导致的,可以通过以下几个方面来分析。

(1)磁盘读写和系统 load 是不是比以前高了,初步判断导致系统变慢的原因。

(2)如果磁盘读写加剧,重点查看 flush 是否过小,compact 是否过频,尤其是 major compact 是否有必要,从测试结果来看 compact 产生的磁盘 io 对系统性能影响很大。

(3)单个 region 的 storefile 个数是否有成倍的提高。

(4)命中率是否有下降趋势。

(5)regionserver 是否存在 region 分配不均衡导致的读写集中,或者读写 handler 的竞争。

(6)datablock 的本地化率是否出现下降。

(7)是否存在 datanode 运行不正常,可以监控查看是否有个别机器读取的 block 时间明显偏高。

常见问题4:数据为什么没了,明明写进去过?

数据丢失也是 HBase 常见的 bug,分为临时性和永久性两类。临时性的丢失往往是由于 hbase 本身的正确性问题导致瞬间读取数据错误。永久性丢失一般是日志恢复 bug 或者 region 的二次分配。

(1)首先可以通过 hbck 或者 master 日志排查丢失的数据所在 region 是否发生过二次分配。

(2)集群中的 regionserver 是否出现过 abort ,日志是否正确恢复。

(3)扫描 storefile 确定目前数据情况

(4)扫描 logs 或者 oldlogs 中文件来确定是否写入过这些数据,以及写入数据的时间,配合 rs 的日志来确定当时 server 的行为。

(5)根据写入数据的时间,确定 regionserver 是否正确完成了 flush 并且将数据写入磁盘。

常见问题5:为什么有服务器进程挂了?

regionserver 发生 abort 的场景很多,除了系统 bug 引起的以外,线上遇到最多的就是 full gc 引起的 zk 节点超时或者文件系统异常。

(1)查看 regionserver 日志查询 FATAL 异常,确定异常类型

(2)查看 GC 日志确定是否发生 full gc 或者 ygc 时间过长

(3)如果没有征兆,日志突然中断,首先需要考虑是否发生了 OOM(0.94版本会直接 kill -9)

(4)可以通过系统内存监控判断是否出现被占满的情况

(5)查看 datanode 是否出现异常日志,regionserver 可能由于 roll log 或者 flush 时的文件系统异常导致 abort

(6)排除人为调用 stop 的情况

HBase 健康检查

一个集群是否健康,大体可以从以下几个方面来判断:

(1)单 regionserver 的 storefile 数量是否合理

(2)memstore 是否得到合理的利用,此项指标与 hlog 的数量和大小相关

(3)compact 和 flush 的流量比值是否合理,如果每天仅 flush 1G 却要 compact 几十上百GB就是明显的浪费

(4)split 是否过频繁,能否采取预分配方式

(5)集群的 region 是否过多,zk 在默认参数下无法支撑 12W 以上的 region 个数,并且 region 过多也会影响 regionserver failover 的时间

(6)读写响应时间是否合理,datablock 的读取延时是否符合预期

(7)flush 队列,callqueue 长度、compact 队列是否符合预期。前两者的积压都会造成系统不稳定。

(8)failedRequest 和 maxResponseTime

(9)gc 状况,过长的 ygc 和过频繁的 cms 都需要警惕;当使用cms时候,heap 设置为31GB后还是存在full gc,频繁的 ygc,可以考虑换成 g1 gc。

欢迎关注我微信公众号,一起来聊技术,来学习,来成长,来进步,感谢。

Apache HBase 常见问题分析

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: