云HBase的使用场景及HBase的发展前景

  • 时间:
  • 浏览:0
  • 来源:爱乐彩网站_爱乐彩下载_爱乐彩官网

常见现象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的情况

常见现象1:个别请求为那此很快?

个别请求慢是用户遇到最多的现象,首先时需明确是客户端还是服务端由于 ,进而分析服务端情况以及捕获那此请求来明确定位。

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

2、确定是也有一段时间内集中出现慢请求,可能性是没有都不能参考常见现象2来外理。

3、查看服务端监控,观察响应时间是不是 平稳,maxResponseTime是不是 出现峰值。可能性趋于稳定,没有都不能初步确定是服务端现象。

4、客户端分析无效,都不能通过运维工具在服务端捕获慢请求的rowkey和操作类型。

5、确定rowkey对应的region,初步查看是不是 趋于稳定数据表参数配置不合理(相似于version设置不多、blockcache、bloomfilter类型不正确)、storefile不多、命中率过高 等现象。

6、尝试重试那此请求可能性直接分析hfile来查看返回结果是不是 过大,请求是不是 耗费资源不多。

7、查看服务端关于hdfs的监控和日志,以及datanode日志,来分析是不是 趋于稳定hdfs块读取慢可能性磁盘故障。

常见现象4:数据为那此没哟,明明写进去过?

数据丢失也是HBase的常见bug,分为临时性和永久性两类。临时性的丢失往往是可能性hbase五种 的正确性现象由于 瞬间读取数据错误。永久性丢失一般是日志恢复bug可能性region的二次分配。

1、首先都不能通过hbck可能性master日志排查丢失的数据所在region是不是 趋于稳定过二次分配

2、集群中的regionserver是不是 出现过abort,日志是不是 正确恢复。

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

4、扫描logs可能性oldlogs中的文件来确定是不是 写入过那此数据,以及写入数据的时间,配合rs的日志来确定当时server的行为

5、根据写入数据的时间,确定regionserver是不是 正确完成了flush某些将数据写入磁盘

常见现象3:系统为那此没有慢了?

系统另却说 挺快的,为那此没有慢?多数是不合理的服务端配置由于 的,都不能通过以下十几个 方面来分析。

1、磁盘读写和系统load是也有比前一天高了,初步判断由于 系统变慢的由于 。

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

3、单个region的storefile个数是不是 有成倍提高

4、命中率是不是 有下降趋势

5、regionserver是不是 趋于稳定region分配不均衡由于 的读写集中,可能性读写handler的竞争

6、datablock的本地化率是不是 出现下降

7、是不是 趋于稳定datanode运行不正常,都不能通过监控查看是不是 有个别机器读取block时间明显偏高

运维工具

HBase官方版本的可运维性的确很差,为了能最大限度的保证线上系统安全,快速定位故障由于 ,阿里做了却说 建设性的工作。

1、建立了删改的监控体系,根据日常测试和线上运行经验,加入了却说 监控点。

2、监控的粒度达到region级别

3、call dump和线上慢请求追踪功能

4、btrace脚本体系,出现现象直接运行查看任务管理器结构信息

5、日志整理和报警

6、在线表维护工具和storefile、logs分析工具

常见现象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是不是 已接近系统设置的上限。

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都时需警惕