现在的位置: 首页 > 云计算 > 正文

HBase性能测试小结

2013年03月02日 云计算 ⁄ 共 1293字 ⁄ 字号 评论关闭

性能测试小结:
测试环境:
机器:1 client 5 regin server 1 master 3 zookeeper
配置:8 core超到16 /24G内存,region server分配了4G heap /单seta磁盘,raid10后500GB
系统:Red Hat Enterprise Linux Server release 5.4
版本:hadoop-0.20.2+737 / hbase-0.90.1 / Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
htable假设:row key = 200 Byte;row value=1k Byte;1 family 1 column

前期主要测试了读写性能,非常满意。可以跑满网卡。

接下来进行了一些持续压力测试,下面是测试的一些结论
1、master启动时会读取和恢复所有hlog,这一步的工作是读取所有hlog放在内存中。在集群比较大写入比较频繁时需要配置较大内存
2、dns配置必须保证一致,在启动时dns解析不一致,运行不会报错,但是balance和recovery时会产生很大的问题,因为master无法准确地判断region server的状态。这个问题非常严重
3、LRU引起的性能消耗非常大,因为一旦内存不能命中,则需要从网络上其它主机请求数据,性能的下降是一到两个数量级。因此需要严格计算内存的使用情况,默认的计算公式是heap of regionserver * 0.2 * 0.85,其中0.2那个因子是可以配置的,建议配置到0.4-0.5
4、update时会引起读写锁互斥,目前测试可以得到互斥会引起读的性能下降一倍。当然对写是无影响的。insert也不会有影响
5、balancer将定期检查,默认是5分钟。balance主要将平衡各台机器的总region数量,有三种平衡算法,效果都差不多,由于balance时会改变region对应的server的信息,因此会有短暂的服务不可用时间,抛出NotServingRegion异常。该异常在客户端进行处理,目前默认的处理办法是阻塞。经压力测试得到balance时的region不可用时间为20ms以内,6小时内balance次数约12次
6、balancer不会以table为粒度进行工作。这会导致如果一张表的row key长期没有发生变化,则数据有可能倾斜在某个region server上
7、compact时虽然复杂,但几乎不会阻塞读写,因为region的状态并没有改变,而只是生成了一个新的store file再做一次rename操作,只在rename时会加一个写锁,但是很快解锁。在平均3500qps写入的压力测试中统计了3个小时内某个region server中的compact次数为195次,其中40次<1s,110次1-2s,32次2-3s,10次3-4s,1次4s,1次7s
8、split耗时在10ms级别,对访问正在split的region的请求抛出NotServingRegion异常

转载:http://koven2049.iteye.com/category/148316

抱歉!评论已关闭.