您的位置:首页 > 数据库

数据库中间件-分库分表压测报告

2017-05-11 21:13 786 查看

测试环境

软硬件环境

4个彼此相互独立阿里rds实例:硬件配置相同,每个配置为:4核心、8GB内存、20GB磁盘、2000 IOPS,每个实例创建一个数据库名称为dbproxy

一个中间件节点,硬件配置相同,配置为:8核心、8GB内存、20GB磁盘 中间件默认工作线程数:32

一个客户端节点,硬件配置相同,配置为:4核心、8GB内存、20GB磁盘

压力测试工具:基于sysbench-0.5开源定制扩展版

一个表:表名为为sbtest1用hash算法切分到4个rds数据库中

测试方法:每次压力测试时,分别在2个节点近乎同时各启动一个sysbench客户端。

中间件日志级别设置:Mycat和Altas日志级别设置为error

Mycat jvm堆内存配置:4GB heap 1GB堆外内存

测试数据:每次执行insert操作向空表中写入400w条记录,select、update以此数据为基础进行操作

数据库Sharding

数据库Sharding

测试报告

Atlas与Mycat比较

一个sysbench客户端,利用sysbench测试并发线程个数不同的情况下,分别执行insert、select,update三种操作,执行400w次。 测试连接Atlas和Mycat这两种情况下的QPS(QPS越大,系统性能越好)、每条记录请求响应耗时, 每组数据重复测试三次后取平均值,具体数据对比如下表所示:

所有下面测试Mycat执行操作过程中,为了获得最佳效果性能和吞吐量,使用不同gc垃圾回收算法进行基准压力测试且都是jit热代码(多次调用后再测试),取出表格中最佳一组数据用于趋势图对比,经过实验数据得出不同gc算法对Mycat吞吐量影响很小,高级gc算法有些吞吐量还降低了,影响较大因素为新生代堆大小配置。

统计QPS

(记录数/sec、T95数据)



统计QPS趋势图

上表数据对应的Atlas和Mycat执行insert操作QPS对比趋势图



结合以上图表和数据可以看出,当sysbench达到64线程数出现拐点,Mycat吞吐量上升比较平缓,Altas则近似直线上升,与Mycat相比Altas吞吐量高近40%

上表数据对应的Atlas和Mycat执行select操作QPS对比趋势图



结合以上图表和数据可以看出,当sysbench达到64线程出现拐点,经过业务和场景分析得出中间件转发数据为短生命周期,且多次测试验证,当调大新生代堆大小会有一些改善。以128线程压测为例,默认新生代堆大小为350MB时QPS是34351/sec,当新生代堆大小改为1500MB时QPS是35076/sec,改为2500MB则QPS是37376,吞吐量提升8%左右。总体上atlas吞吐量高于Mycat一倍以上

上表数据对应的Atlas和Mycat执行update操作QPS对比趋势图



结合以上图表和数据可以看出,当sysbench达到64线程出现拐点,Mycat吞吐量遇到瓶颈上升不明显,以128线程压测为例,默认新生代堆大小为350MB时QPS是30377/sec,当新生代堆大小改为1500MB时QPS是31922/sec,改为2500MB则QPS是37970/sec,吞吐量提升25%左右

统计记录请求响应耗时

(每条记录请求响应耗时、单位毫秒、T95数据):



统计记录请求响应耗时趋势图

上表数据对应的Atlas和Mycat执行insert操作耗时对比趋势图



结合以上图表和数据可以看出,Atlas和Mycat耗时相近,原因是瓶颈在于rds的IOPS限制,insert性能依赖于rds的IOPS能力,不能充分发挥Atlas能量

上表数据对应的Atlas和Mycat执行select操作耗时对比趋势图



结合以上图表和数据可以看出,当sysbench达到64线程出现拐点,Mycat耗时陡然增加且增速比Atlas快

上表数据对应的Atlas和Mycat执行update操作耗时对比趋势图



结合以上图表和数据可以看出,Atlas和Mycat耗时较为相近,原因是瓶颈在于rds的IOPS限制,update性能依赖于rds的IOPS能力,不能充分发挥Atlas能量

统计硬件资源消耗

一个sysbench客户端,利用sysbench测试并发线程个数不同的情况下,分别执行400w次insert、select、update操作,中间件部署机器资源消耗(cpu消耗、load负载),每组数据重复测试三次后取平均值,具体数据对比如下表所示:



统计硬件资源消耗趋势图

cpu消耗趋势图:

上表数据对应的Atlas和Mycat执行insert操作cpu消耗对比趋势图



结合以上图表和数据可以看出,当sysbench达到64线程出现拐点,Mycat的cpu消耗更大,通过jstack + top分析java进程消耗cpu最多线程(开源工具),原因为jvm内置线程消耗较大(gc等线程)

上表数据对应的Atlas和Mycat执行select操作cpu消耗对比趋势图



结合以上图表和数据可以看出,虽然客户端64线程压测Atlas的吞吐量远大于Mycat,但cpu消耗却相近,Atlas相比Mycat消耗cpu少很多。

上表数据对应的Atlas和Mycat执行update操作cpu消耗对比趋势图



结合以上图表和数据可以看出,当sysbench达到32线程出现拐点,Mycat的cpu消耗更大,通过jstack + top分析java进程消耗cpu最多线程(开源工具),原因为jvm内置线程消耗较大(gc等线程)

load负载趋势图

上表数据对应的Atlas和Mycat执行insert操作load负载对比趋势图



结合以上图表和数据以及QPS、cpu综合分析可以看出,当sysbench达到32线程出现拐点,rds遇到IOPS瓶颈,Atlas很多线程处于wait状态,性能无法充分发挥,随着客户端线程增加,所以导致Atlas待调度执行的任务较多

上表数据对应的Atlas和Mycat执行select操作load负载对比趋势图



同理select分析

上表数据对应的Atlas和Mycat执行update操作load负载对比趋势图



同理select分析

mycat jvm监控

当Mycat用默认gc算法时,用java提供可视化工具jvisualvm,监控了jvm heap、cpu等情况,综合分析转发数据生命周期短,堆内存占用较少,很少fullgc,在400w数据测试中也就出现1~2次fullgc,mingc相对较多,cpu波峰值地方是sysbench初始化时候发生的。

insert



select



update



综合分析

本次测试时中间件线程数为机器4倍,基本能充分发挥中间件性能。从执行SQL类型、记录请求响应耗时、cpu消耗、cpu load负载等多个维度综合评估Atlas和Mycat的性能及吞吐量,最大限度保证数据和性能尽量接近真实值。在同等软硬件环境下,Atlas能充分利用硬件资源,极限吞吐量为Mycat一倍以上(个人觉得25~40%比较正常,但是测试select确实大一倍),通过商业中间件OneProxy与Mycat对比,也可以作出印证,OneProxy测试报告地址。

OneProxy与Atlas一样,用c语言开发



某Java类的Proxy,就是指的Mycat,因为平民软件迁移了好几个Mycat的客户端

用sysbench测试的缺点就是模拟的表结构太简单,而且每条记录最大为200字节,因此无法验证gc对Mycat影响,400w数据操作过程中只有1~2次fullgc,如果真实环境中是不是数据量大些fullgc会频繁些呢?

方案选型

关于中间件方案选型,要从多个维度考虑,例如性能和吞吐量、关键功能完善度,公司投入力量,单纯从吞吐量考虑Atlas无疑胜出,如果自动化(运维化)、服务化、产品化角度考虑Mycat是必然选择。不过Mycat优势也明显;

关于吞吐量和性能问题,Mycat虽然吞吐量较差,但线上一般都是通过中间件前面加一层lvs代理部署来做ha的,就是可以多部署Mycat实例弥补不足。

个人观点:我没有特定倾向,任意语言都可以,主要是结合公司业务场景、需求、功能要求、资源投入程度、紧急程度等综合因素来做决定。如果这方面清晰了(方向和目标定了),就容易选择了。

中间件上线准备工作

Atlas和Mycat测试的版本都支持分库但不分表,一个数据库只能建立一张表,但不支持单库多表,如果业务需要支持分库分表,就要在一个数据库内可以切分多张表情况。上线需要适配改造,1.通过DBA运维手段解决 2.修改中间件代码实现单库分表功能,二者选其一。

注明:Atlas开源有2个版本,一个版本支持只支持单库分表,另外一个版本支持跨库分表不支持单库多表
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: