Sysbench（Bulk insert）测试报告

测试背景

XX通过TPC-DS与TPC-H的基准测试规则，主要验证了select的场景测试，TPC-DS与TPC-H的性能场景测试有限，无法满足点查、更新、批量写入的性能测试场景，因此采用Sysbench基准测试工具对AtomData进行批量写入的场景覆盖测试

sysbench介绍

sysbench是一个模块化的、跨平台、多线程基准测试工具，主要用于评估测试各种不同系统参数下的数据库负载情况，它主要包括以下几种方式的测试：磁盘io性能、数据库性能、内存分配及传输速度等，详细的介绍见https://github.com/akopytov/sysbench

测试场景

已行数为测试条件，主要验证测试在不同并发数量的情况下，AtomData针对不同的数据量的性能结果表现

	行数	并发	用途
场景一	10,0000	依据sysbench的策略( 注：平均每批写入3000行)	固定的数据量，向同一张表中写入的性能测试
	100,0000
	500,0000
	1000,0000
场景二	10,0000	5,10,20,30,40,50,100,500	固定的数据量，向不同表中插入的性能测试
	100,0000
	500,0000
	1000,0000

场景一结果结论

向同一张表中批量写入10,0000、100,0000、500,0000、1000,0000数据量下的性能表现如下：

100000		1000000		5000000		10000000
TPS	Latency(ms)	TPS	Latency(ms)	TPS	Latency(ms)	TPS	Latency(ms)
154031.67	242.85	98702.92	2808.09	136786.38	438.66	125196.21	690.95

TPS趋势图分析

Latency趋势图分析

 

场景二测试结论

不同并发条件下，向表中批量写入数据，分别在10,0000、100,0000、500,0000、1000,0000数据量下的性能表现如下：

	100000		1000000		5000000		10000000
并发	TPS	Latency(ms)	TPS	Latency(ms)	TPS	Latency(ms)	TPS	Latency(ms)
5	454013.50	0.28	535185.24	377.39	789788.56	314.64	634465.78	478.40
10	713894.61	0.60	1284609.86	309.55	1322141.07	922.95	1310269.59	495.18
20	711277.57	1.58	1644438.88	381.60	2681489.58	433.41	2461425.98	597.29
30	657665.59	2.28	1862380.81	444.81	3424732.11	537.54	3167016.87	887.52
40	714636.50	6.09	1930607.34	8.84	3116464.31	791.70	3671649.27	538.87
50	536183.74	12.53	1865576.52	9.09	2980255.46	918.57	3420850.26	882.68
60	488946.70	21.53	2006196.55	32.16	2968906.99	852.02	3442247.53	1029.51
100	489826.78	25.83	1954702.01	125.63	2472913.97	1711.91	3252786.63	1446.31
500			515567.16	401.69	1046660.33	1440.37	1559162.43	2403.95

备注：bulk_insert的Latency的取值为max时间

TPS趋势图分析

• 100000行数据测试结果

• 建议的并发数：10个并发，每秒的事务数为713894，此时批量写入到表的性能相对较好
• 峰值数：714636，之后，随着并发数的增加，性能有下降趋势，在并发数为60~100之间性能稳定

• 1000000行数据测试结果

• 建议的并发数：40~100个并发之间，事务数平均在2000000之间，此时批量写入到表的性能相对稳定
• 峰值数：2006196，之后随着并发数的增加，性能在下降

• 5000000行数据测试结果

• 建议的并发数：30个并发，每秒的事务数为3424732，此时批量写入到表的性能最佳
• 峰值数：3424732，之后随着并发数量的增加，性能在下降

• 10000000行数据测试结果

• 建议的并发数：40个并发，每秒的事务数可达3671649，此时写入的性能最佳
• 峰值数：3671649，之后随着并发数的增加，性能在逐渐的走下降趋势

Latency趋势图分析

• latency的最佳与TPS的测试结果相对应，不同数据量在不同并发下的最佳的延时对应着最佳的TPS
• 100000行数据：延时较低，可以忽略不计
• 1000000行数据：并发40时，延时最佳为8.84ms
• 5000000行数据：并发20或30时，延时最佳为433.41ms
• 10000000行数据：并发40时，延时最佳为538.87ms

压测环境

sysbench Version	1.0.18
OS	Ubuntu 20.04 （5.4.0-104-generic x86_64）
Memory	128GB
Cores	32C
Disk	200G HDD
Network	万兆

测试策略

• 手动创建数据库，示例命名为z_syw_sysbench
• 使用sysbench向数据库z_syw_sysbench的库中创建10张表
• 根据不同的测试维度，向每个表中插入测试场景表中给定的行数（如10万行）
• 每个配置下测试600秒
• 每10秒进行一次采样
• 重复执行三次，取平均值
• 针对不同的测试维度，按照sysbench给定的脚本进行测试

测试语法

INSERT INTO sbtest%u (id, k) VALUES (x,x),(x,x).......

测试脚本

###准备数据
sysbench /usr/share/sysbench/oltp_insert.lua --tables=5 --table_size=1 --mysql-host=192.168.30.118 --mysql-port=3001 --mysql-db=syw_sysbench --mysql-user=kepler --mysql-password=afdd0b4ad2ec172c586e2150770fbf9e  prepare
###运行workload
sysbench /usr/share/sysbench/oltp_insert.lua --tables=5 --table_size=1000000000 --threads=20  --mysql-host=192.168.30.118 --mysql-port=3001 --mysql-db=syw_sysbench --mysql-user=kepler --mysql-password=afdd0b4ad2ec172c586e2150770fbf9e --create_secondary=off --time=1600 --report-interval=3 run
###清空数据
sysbench /usr/share/sysbench/oltp_insert.lua --tables=5 --table_size=1 --mysql-host=192.168.30.118 --mysql-port=3001 --mysql-db=syw_sysbench --mysql-user=kepler --mysql-password=afdd0b4ad2ec172c586e2150770fbf9e  prepare

资源利用率

如下示例：5000000行数据进行测试时的资源利用率，其他的内容详见语雀记录

磁盘IO使用率

• 从IO的使用率曲线可以明确得出结论

1. 并发数从1增加到100时，IO使用率呈下降趋势
2. 当并发数是500时，IO使用率相比并发数是30到60之间有了增加的趋势
3. 并发数30到60之间，IO使用率最低

CPU使用率

• 从CPU的使用率曲线得出如下结论

1. 当并发数是20时，控制节点CPU使用率占比最高，达到了100%
2. 随着并发数的增加，控制节点CPU使用率在逐渐的呈下降趋势
3. 并发数越大，控制节点的CPU使用率越低

写入TPS

• 从写入TPS的曲线图得出如下结论

1. 最大的写入TPS在160000行每秒，且相对比较稳定，曲线的波动较小
2. 最低的写入TPS也在84235行每秒

• (补充)写入的TPS波动曲线与写入流量的曲线表现一致

 

写入响应时间

• 从写入响应时间的曲线得出如下结论

1. 随着并发数从2增加到100，写入的时间整体呈上升趋势
2. 并发数等于500时，写入响应时间相比并发数等于100有了明显了下降趋势

 

磁盘IO吞吐

• 从磁盘IO吞吐曲线图得出如下结论

1. 等并发数等于30时，磁盘worker_avg_read_bytes_ratio的IO吞吐达到了最高值，每秒153MB
2. 相比而言，并发数等于50之后，随着并发数的持续增加，磁盘worker_avg_read_bytes_ratio的IO吞吐呈下降趋势