性能测试小结:
测试环境:
机器: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异常
hbase 实时写入 hbase写入性能测试
转载本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
分布式数据库 HBase实践
07 手机云服务数据存储
数据存储 云服务 -
hbase 高速写 hbase写入性能
1.hbase的特点 (1)随机读写操作 (2)大数据上高并发操作,例如每秒PB级数据的数千次的读写操作 (3)读写均是非常简单的操作,例如没有join操作
hbase 高速写 hbase 数据 github 搜索 -
hbase 高并发写入 hbase批量写入性能对比
背景:mysql不适合存储非常巨大的数据量,不利于扩展,影响性能。(包括oracle数据库十分巨大)我们就需要考虑HBase作为存储工具。HBase具有非常高的读写性能,支持无上限的数据存储容量
hbase 高并发写入 hbase 分布式 spring cloud hadoop