HBASE偶尔挂 hbase waiting for actions

转载

编程小达人之心 2023-11-06 12:06:12

文章标签 HBASE偶尔挂 hbase java api性能测试 apache hadoop Server 文章分类 Hbase 数据库

本帖最后由 gefieder 于 2013-12-13 12:25 编辑

这个要根据你们的具体的情况，或则说你们的需求进行模拟.

比方你们是插入多，还是查询多。如果插入多，你可以通过程序执行批量插入。

如果既有插入，又有查询。这个压力测试，可能需要的任务量就多一些。

同时你可以使用集群监控工具：关心你所测试的指标。

下面给你一些性能测试的问题及解决办法：

一、HBase集群在读写过程中，可能由于Region Split或Region Blance等导致Region的短暂下线，此时客户端与HBase集群进行RPC操作时会抛出NotServingRegionException异常，从而导致读写操作失败。

1. 发现问题

在对HBase集群进行压力测试过程中发现，当实际写入HBase和从HBase查询的量是平时的若干倍时(集群规模10~20台，每秒读写数据量在几十万条记录的量级)，导致集群的读写出现一定程度的波动。具体如下：

1)写端抛出以下异常信息：

org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 150 actions: NotServingRegionException: 150 times, servers with issues: my161208.cm6:60020,

at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1600)

at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1376)

at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:916)

复制代码

2)读端也抛出类似异常信息：org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=10, exceptions:

Mon Oct 29 14:03:09 CST 2012, org.apache.hadoop.hbase.client.ScannerCallable@3740fb20, org.apache.hadoop.hbase.NotServingRegionException: org.apache.hadoop.hbase.NotServingRegionException: xxxxxx,\x0FP\x8D\xC3\xDB1053223266:\x00\x00V6,1351490475989.bd68113129f07163dc25e78fba17ad6c. is closing复制代码

以上异常，在压测期间周期性地出现，HBase集群由此出现了短暂的不可服务期。

2. 排查问题

通过查看HBase Master运行日志，结合客户端抛出异常的时刻，发现当时HBase集群内正在进行Region的Split和不同机器之间的Region Balance，那么，为什么会周期性频繁触发以上过程呢？而且是发生在压测期间(数据量与平时相比大几倍)。下面结合表的设计来分析一下：

1)由于表中rowkey有时间字段，因此每天都需要新创建Region，同时由于写入数据量大，进一步触发了HBase的Region Split操作，这一过程一般耗时较长(测试时从线上日志来看，平均为10秒左右，Region大小为4GB)，且Region Split操作触发较为频繁；

2)同时由于Region Split操作导致Region分布不均匀，进而触发HBase自动做Region Balance操作，Region迁移过程中也会导致Region下线，这一过程耗时较长(测试时从线上日志来看，平均为20秒左右)。

3. 解决问题

首先，从客户端考虑，其实就是要保证Region下线不可服务期间，读写请求能够在集群恢复后继续，具体可以采取如下措施：

1)对于写端，可以将未写入成功的记录，添加到一个客户端缓存中，隔一段时间后交给一个后台线程统一重新提交一次；也可以通过setAutoFlush(flase, false)保证提交失败的记录不被抛弃，留在客户端writeBuffer中等待下次writeBuffer满了后再次尝试提交，直到提交成功为止。

2)对于读端，捕获异常后，可以采取休眠一段时间后进行重试等方式。

3)当然，还可以根据实际情况合理调整hbase.client.retries.number和hbase.client.pause配置选项。

然后，从服务端考虑，需要分别针对Region Split和Region Balance进行解决：

1)由于建表时，我们已经考虑到了数据在不同Region Server上的均匀分布，而且预先在不同Region Server上创建并分配了相同数目的Region，那么考虑到为了集群能够在实际线上环境下提供稳定的服务，可以选择关掉HBase的Region自动Balance功能，当然关掉后可以选择在每天读写压力小的时候(如凌晨后)触发执行一次Balance操作即可。

2)接下来，Region总是被创建，不能被复用的问题该如何解决呢？根本原因是rowkey中包含了timestamp字段，而每时每刻timestamp总是向上增长的。但是，使用方确实需要能够根据timestamp字段进行顺序scan操作，因此，timestamp字段必须保留。据此，这里给出两种解决思路：一种常用方法是将表按照时间分表，例如按天进行分表，这样可以通过预先建表创建好Region分区，避免实际读写过程中频繁触发Region Split等过程，但是这一方法的缺点是每天需要预先建好表，而这一DDL过程可能出现问题进而导致读写出现问题，同时跨天时读写端也需要做出适应，调整为读写新创建的表。

其实，我们可以换一种思路，通过修改表的rowkey结构，将timestamp字段改成一个周期循环的timestamp，如取timestamp % TS_MODE后的值，其中TS_MODE须大于等于表的TTL时间周期，这样才能保证数据不会被覆盖掉。经过这样改造后，即可实现Region的复用，避免Region的无限上涨。对于读写端的变更也较小，读写端操作时只需将timestamp字段取模后作为rowkey进行读写，另外，读端需要考虑能适应scan扫描时处理[startTsMode, endTsMode]和[endTsMode, startTsMode]两种情况。

二、HBase解决Region Server Compact过程占用大量网络出口带宽的问题

HBase 0.92版本之后，Region Server的Compact过程根据待合并的文件大小分为small compaction和large compaction两种，由此可能导致在集群写入量大的时候Compact占用过多的网络出口带宽。本文将详细描述集群使用过程中遇到这一问题的排查过程及其解决方法。

1. 发现问题

HBase集群(版本为0.94.0)运行过程中，发现5台Region Server的网络出口带宽经常维持在100MB/s以上，接近到网卡的极限；同时Region Server的机器load负载也很高，高峰时候能够达到30~50。2. 排查问题

1、集群实际运行过程中，观察到Region Server服务端的网卡，平均每台写入流量大概60MB/s(此时写入量已经很大了)；读出流量90MB/s，有时甚至突破100MB/s(注：每台机器都是千兆网卡)；

2、观察实际的写入数据量在每秒5w tps左右，单条记录平均大小为1KB，大概会占用50MB/s左右的网卡入口带宽请求量，和观察到的现象一致；

3、观察查询量在每秒6w qps左右，单条记录平均大小为1KB，大概会占用60MB/s左右的网卡出口带宽请求量，奇怪的是实际观察到有接近甚至超过100MB/s的网络出口带宽请求量，多出了40MB/s左右的网络出口带宽；

4、经分析排查确定导致上述过程的原因，可能是HBase服务端由于写入量过大频繁触发compaction过程，而compaction是需要读HBase数据的，因此占据了相当部分的网络出口带宽；

5、结合对相关源码org/apache/hadoop/hbase/regionserver/CompactSplitThread.java的分析，决定对HBase集群配置做出变更(具体见下一小节)，主要目的是减少compaction的发生；

6、接下来，观察到Region Server的网络利用率明显降低，一般进出口带宽能维持在70MB/s以下。3. 解决问题

HBase 0.92版本之后增加了关于compact的配置选项，compact分为small compaction和large compaction两个线程池执行(默认都是各有1个线程，具体源代码见：org/apache/hadoop/hbase/regionserver/CompactSplitThread.java)，由于compact过程需要从HBase集群读取数据，因此实际运行中导致了compact占用大量网络出口流量，解决方案为选择性地关闭small compaction或large compaction。有以下两种变更方式均可解决：

1)方案一

(1) 修改hbase.regionserver.thread.compaction.throttle为一个很大的值(如50GB)，强制让所有compact都变为small compaction，减少compact的压力；

(2) 将small compaction和large compaction线程数均设置为1，减少compact的压力(可不配置，系统默认也会将其初始化为1)。

操作步骤：

准备hbase-site.xml文件，添加或修改如下选项：

hbase.regionserver.thread.compaction.throttle

53687091200

hbase.regionserver.thread.compaction.small

hbase.regionserver.thread.compaction.large

复制代码

重启集群使配置生效。

2)方案二