阅读本文可以带着下面问题:
1.HBase遇到问题,可以从几方面解决问题?
2.HBase个别请求为什么很慢?你认为是什么原因?
3.客户端读写请求为什么大量出错?该从哪方面来分析?
4.大量服务端exception,一般原因是什么?
5.系统越来越慢的原因是什么?
6.Hbase数据写进去,为什么会没有了,可能的原因是什么?
7.
regionserver发生abort,遇到最多是什么情况?
8.从哪些方面可以判断HBase集群是否健康?
9.为了加强HBase的安全性,你会采取哪些措施?
在Tcon分布式系统测试实践的分享中,笔者提到了测试人员参与线上问题分析的必要性:
1、测试工作中的问题定位提供了大量经验,可以直接应用于线上。
2、快速的解决问题可以避免大故障的发生。
3、从线上的问题可以帮助我们准确抓住测试的重点和不足。
因此在日常的线上维护工作中,积累和很多HBase的问题分析经验,这里于大家分享一下,如有错误和不足请指出。
问题分析的主要手段
1、监控系统:首先用于判断系统各项指标是否正常,明确系统目前状况
2、服务端日志:查看例如region移动轨迹,发生了什么动作,服务端接受处理了哪些客户端请求。
3、gc日志:gc情况是否正常
4、操作系统日志和命令:操作系统层面、硬件是否故障,当前状况如何
5、btrace:实时跟踪目前服务端的请求和处理情况
6、运维工具:通过内置于系统中的功能,查看服务器实时处理状况
其实以上手段,大部分系统都具备,不过各有各的用法,下面我会通过常见的问题来梳理这6大手段。
常见问题1:个别请求为什么很慢?
个别请求慢是用户遇到最多的问题,首先需要明确是客户端还是服务端原因,进而分析服务端状况以及捕获这些请求来明确定位。
1、通过客户端日志来初步分析下慢请求的规律,尝试在客户端确定请求的rowkey和操作类型。
2、确定是不是一段时间内集中出现慢请求,如果是那么可以参考常见问题2来解决。
3、查看服务端监控,观察响应时间是否平稳,maxResponseTime是否出现峰值。如果存在,那么可以初步确定是服务端问题。
4、客户端分析无效,可以通过运维工具在服务端捕获慢请求的rowkey和操作类型。
5、确定rowkey对应的region,初步查看是否存在数据表参数配置不合理(例如version设置过多、blockcache、bloomfilter类型不正确)、storefile过多、命中率过低等问题。
6、尝试重试这些请求或者直接分析hfile来查看返回结果是否过大,请求是否耗费资源过多。
7、查看服务端关于hdfs的监控和日志,以及datanode日志,来分析是否存在hdfs块读取慢或者磁盘故障。
常见问题2:客户端读写请求为什么大量出错?
读写请求大量出错的现象主要有两类:1、大量出现服务端exception
2、大量超时。其中第一种有异常信息较好判断问题所在。
1、大量服务端exception一般是region不在线导致的,可能是region在split但是时间很长超过预期,或是meta数据错误导致客户端获取region
location错误。以上现象均可通过日志来定位。
2、遇到大量超时,首先应该排除服务端是否出现了fullgc或者ygc时间过长。前者可能由于内存碎片、cms
gc速度来不及导致,后者一般是由于系统使用了swap内存。
3、通过系统命令和日志来查看是否有机器load过高,磁盘压力过大,磁盘故障。
4、查看监控是否出现callqueue积压,请求无法得到及时处理,进一步通过call查看工具或者jstack可以查看正在处理的call和进程堆栈信息。
5、通过datanode日志和hbase访问dfs的时间,来判断问题是否在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引起的以外,线上遇到最多的就是fullgc引起的zk节点超时和文件系统异常。
1、查看regionserver日志查询FATAL异常,确定异常类型
2、查看gc日志确定是否发生fullgc或者ygc时间过长
3、如果没有征兆,日志突然中断,首先需要考虑是否发生了OOM(0.94版本会直接kill
-9)。
4、可以通过系统内存监控判断是否出现被占满的情况
5、查看datanode是否出现异常日志,regionserver可能由于roll
log或者flush时的文件系统异常导致abort
6、排除人为调用stop的情况
HBase健康体检
一个集群似乎否健康,大体可以从以下几个方面来判断
1、单region的storefile数量是否合理
2、memstore是否得到合理的利用,此项指标与hlog的数量和大小相关
3、compact和flush的流量比值是否合理,如果每天仅flush
1G却要compact几十上百G就是明显的浪费
4、split似乎否过频,能否采取pre-sharding的方式来预分配region
5、集群的region是否过多,zk在默认参数下无法支撑12w以上的region个数,并且region过多也会影响regionserver
failover的时间
6、读写相应时间是否合理,datablock的读取延时是否符合预期
7、flush队列、callqueue长度、compact队列是否符合预期。前两者的积压都会造成系统不稳定。
8、failedRequest和maxResponseTime
9、gc状况,过长的ygc和过频的cms都需要警惕
运维工具
HBase官方版本的可运维性的确很差,为了能最大限度的保证线上系统安全,快速定位故障原因,阿里做了很多建设性的工作。
1、建立了完整的监控体系,根据日常测试和线上运行经验,加入了很多监控点。
2、监控的粒度达到region级别
3、call
dump和线上慢请求追踪功能
4、btrace脚本体系,出现问题直接运行查看程序内部信息
5、日志收集和报警
6、在线表维护工具和storefile、logs分析工具
(转)HBase工程师线上工作经验总结----HBase常见问题及分析
时间: 2024-11-03 05:33:26
(转)HBase工程师线上工作经验总结----HBase常见问题及分析的相关文章
HBase工程师线上工作经验总结----HBase常见问题及分析
阅读本文可以带着下面问题:1.HBase遇到问题,可以从几方面解决问题?2.HBase个别请求为什么很慢?你认为是什么原因?3.客户端读写请求为什么大量出错?该从哪方面来分析?4.大量服务端exception,一般原因是什么?5.系统越来越慢的原因是什么?6.Hbase数据写进去,为什么会没有了,可能的原因是什么?7. regionserver发生abort,遇到最多是什么情况?8.从哪些方面可以判断HBase集群是否健康?9.为了加强HBase的安全性,你会采取哪些措施? 在Tcon分布式系统
hbase 从hdfs上读取数据到hbase中
1 <dependencies> 2 <dependency> 3 <groupId>org.apache.hbase</groupId> 4 <artifactId>hbase-client</artifactId> 5 <version>2.0.2</version> 6 </dependency> 7 <dependency> 8 <groupId>org.apache
一个软件开发工程师的7年工作经验总结
这是在网上看到的一篇文章,写的是一个从事软件工程开发的大牛对从业七年的一些经验总结.感觉挺不错,转来与大家分享了,下面是正文. 1.分享第一条经验:"学历代表过去,能力代表现在,学习力代表未来." 其实这是一个来自国外教育领域的一个研究结果.相信工作过几年.十几年的朋友对这个道理有些体会吧.但我相信这一点也很重要:"重要的道理明白太晚将抱憾终生!"所以放在每一条,让刚刚毕业的朋友们早点看到哈! 2.一定要确定自己的发展方向,并为此目的制定可行的计划. 不要说什么,&
关于线上静态页面资源更新的一些经验分享
目录 关于线上静态页面资源更新的一些经验分享 关于Linux的Patch 关于git 关于Idea 关于线上静态页面资源更新的一些经验分享 最近在负责公司的后台项目,包括了后端和前端.后端直接编译完打成jar包直接上线运行没什么问题.但是前端的页面文件更新每次都要把页面给运维,然后告诉运维路径让运维挨个替换,当然也可以整包替换, 但是如果文件比较多的情况下,整包替换就不合适了.因为现在开发的项目版本控制基本必不可少了,这时候可以利用版本控制软件来生成Patch文件,然后直接交给运维,让运维在项目
【转】java线上程序排错经验2 - 线程堆栈分析
前言 在线上的程序中,我们可能经常会碰到程序卡死或者执行很慢的情况,这时候我们希望知道是代码哪里的问题,我们或许迫切希望得到代码运行到哪里了,是哪一步很慢,是否是进入了死循环,或者是否哪一段代码有问题导致程序很慢,或者出现了线程不安全的情况,或者是某些连接数或者打开文件数太多等问题,总之我们想知道程序卡在哪里了,哪块占用了大量的资源. 此时,或许通过线程堆栈的分析就能定位出问题. 如果能深入掌握堆栈分析的技术,很多问题都能迎刃而解,但是线程堆栈分析并不简单,设计到线上的排错问题,需要有一定的知识
分享下使用 svn,测试服务器代码自动更新、线上服务器代码手动更新的配置经验
分享下使用 svn,测试服务器代码自动更新.线上服务器代码手动更新的配置经验 利用SVN的POST-COMMIT钩子自动部署代码 Linux SVN 命令详解 Linux SVN 命令详解2
对线上系统维护工作的总结与思考
背景描述:目前在一家网站公司工作,2015年初研发中心部门改革,小组重组,被分配到了网站平台的维护组.下面内容是对近期维护工作的一个总结: 个人感受:以前也在老东家的团队也做线上系统的维护和新产品的研发,由于大家的认真负责,Leader的管理也很到位,线上的系统很少有bug反馈,不管是UI上迭代,还是系统逻辑的升级都很顺畅. 目前负责的平台运行了3年多,可能由于当时逻辑设计问题,也可能是执行问题,发现近期反馈的问题多是逻辑问题,在此对这些问题的原因不做探讨和深究,只是想讲讲面对线上问题的维护工作
线上问题排查-HBase写数据出现NotServingRegionException(Region ... is not online)异常
今天线上遇到一个问题:有一台服务器的cpu持续冲高,排查发现是我们的一个java应用进程造成的,该进程在向hbase中写入数据时,日志不断地打印下面的异常: org.apache.hadoop.hbase.NotServingRegionException: Region iot_flow_cdr_201811,4379692584601-2101152593-20181115072326-355,1536703383699.82804f639798d0502dd64e6e47d75d84. i
关于线上优化服务器视频笔记1-----调优线上服务器
linux服务器调优的经验 目录: 1.系统故障排除思路 重视报错信息 永远不要忘记日志文件 分析.定位.解决问题 2.影响linux性能的因素 服务器硬件因素 操作系统的相关因素 程序因素 3.系统性能优化工具 Cpu性能优化工具 vmstat,iosta,sar 内存性能检测工具 free,top,sar,pidstat 磁盘性能评估工具 iostat,sar 网络性能分析工具 ping,mtr,netstat 4.系统性能分析与标准 5.性能调优的思路与技巧分享 几个故障鼓励案例和性能优化