对Aurora进行压力测试_一切皆有过往归于过往

对Aurora进行压力测试

一、前言

Amazon Aurora 是一种为云打造并与 MySQL 和 PostgreSQL 兼容的关系数据库，既具有高端商用数据库的性能和可用性，又具有开源数据库的简单性和成本效益。相比起 MYSQL, Aurora 在只读副本延迟，可扩展性，备份恢复速度以及存储空间扩展等方面都有很大优势，更有回溯，aurora serverless 等实用的新功能，除了以上功能和管理方面的优点外，Aurora 的速度最高可以达到标准 MySQL 数据库的五倍、标准 PostgreSQL 数据库的三倍。

随着宁夏区推出 Aurora，中国区客户终于可以体验 Aurora 的独特魅力了，在迁移数据库之前，有些客户也想进行性能比对测试，做到知己知彼。针对这种需求，这里我将给大家介绍如何用 sysbench 对 MYSQL RDS 和 Aurora 进行测试，讲解不同测试参数的含义，分析不同测试案例的结果，希望对大家今后测试数据库的工作有所帮助。

二、环境准备

2.1 环境信息

测试端

机型	内存(GiB)	磁盘	网络
4台db.r4.8xlarge EC2	通用SSD 40G	高

数据库

数据库	DB instance class	内存(GiB)	磁盘	网络
Aurora mysql5.6 RDS	db.r4.8xlarge	高
mysql5.6 RDS	db.r4.8xlarge	IOPS 10000 SSD 40G	高

2.2 安装和配置 sysbench

在四台测试客户端安装 sysbench

安装 Sysbench Version 0.5，执行以下步骤:

yum -y install bzr yum -y install automake yum -y install libtool

2.以 root 用户安装 MySQL 客户端程序 (Red Hat 用 mysql‐devel, Debian/Ubuntu 用 libmysqlclient‐dev ):

yum -y install mysql-devel yum –y install mysql

下载 Sysbench:

bzr branch lp:sysbench

cd sysbench ./autogen.sh ./configure make cd sysbench

2.3 打开限制

在 Sysbench 客户端执行以下网络配置，告诉 Linux kernel 可以用所有的 CPU cores 去处理 packets, 默认只可以用两个, 并且减少 cores 之间的 context switching. 这两个设置是为了用更少的 Sysbench 客户端达成吞吐目标.

`sudo sh -c ‘for x in /sys/class/net/eth0/queues/rx-*; do echo ffffffff > $x/rps_cpus; done’

sudo sh -c “echo 32768 > /proc/sys/net/core/rps_sock_flow_entries”

sudo sh -c “echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt”

sudo sh -c “echo 4096 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt”

vim /etc/security/limits.conf

2.4 模拟数据注入

首先通过 sysbench 客户端在测试数据库上生成测试表，这里生成 250 个表，每个表有行数 25000 条，您也可以根据您的目标，调整表的数目和大小，请替换<>之中的各种连接信息，再执行命令，同时拷贝的时候请注意格式，后面的命令注意事项相同，不再赘述

./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --oltp-tables-count=250 --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --oltp-table-size=25000 --mysql-db=<aurora db> --db-driver=mysql prepare

其输出类似：

同样的，在 mysql 上生成相同的测试集

其输出类似：

参数含义

–test=tests/db/oltp.lua 表示调用 tests/db/oltp.lua 脚本进行 oltp 模式测试

–oltp_tables_count=250 表示会生成 250 个测试表

–oltp-table-size=25000 表示每个测试表填充数据量为 25000

–rand-init=on 表示每个测试表都是用随机数据来填充的

加载测试数据时长视数据量而定，若过程比较久需要稍加耐心等待。

2.5 监控脚本

我们生成如下脚本来监控数据库，每秒一次输出 QPS/Commit/Rollback/TPS/Threads_con/ Threads_run 的信息，协助我们掌握数据库每秒的负载变化

vi aurora_monitor.sh #!/bin/bash mysqladmin -h -u -p"" extended-status –i1 |awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "} $2 ~ /Queries$/ {q=$4-lq;lq=$4;} $2 ~ /Com_commit$/ {c=$4-lc;lc=$4;} $2 ~ /Com_rollback$/ {r=$4-lr;lr=$4;} $2 ~ /Threads_connected$/ {tc=$4;} $2 ~ /Threads_running$/ {tr=$4; if(local_switch==0) {local_switch=1; count=0} else { if(count>10) {count=0;print "------------------------------------------------------- \nQPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- ";} else{ count+=1; printf "%-6d %-8d %-7d %-8d %-10d %d \n", q,c,r,c+r,tc,tr; } } }'

同样地，为 MYSQL 生成类似的脚本

vi mysql_monitor.sh #!/bin/bash mysqladmin -h <mysql server> -u <mysql user> -p"<mysql password>" extended-status –i1 |awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "} $2 ~ /Queries$/ {q=$4-lq;lq=$4;} $2 ~ /Com_commit$/ {c=$4-lc;lc=$4;} $2 ~ /Com_rollback$/ {r=$4-lr;lr=$4;} $2 ~ /Threads_connected$/ {tc=$4;} $2 ~ /Threads_running$/ {tr=$4; if(local_switch==0) {local_switch=1; count=0} else { if(count>10) {count=0;print "------------------------------------------------------- \nQPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- ";} else{ count+=1; printf "%-6d %-8d %-7d %-8d %-10d %d \n", q,c,r,c+r,tc,tr; } } }'

三、测试

3.1 只读压力测试

在所有 sysbench client 同时执行命令模拟负载，每次持续 5 分钟，同时使用监控脚本监视数据库的性能，从 console 查看 CPU，IO，网络等 metrics。在这里我们将通过修改 num_threads 参数连续测试 4250,4750,41250 和 4*1500 多种并发连接的场景。

./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --mysql-db=<aurora db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=on --num-threads=1000 --report-interval=10 run>>aurora_r.log

参数说明

–num-threads=100 表示 sysbench client 发起 100 个并发连接

–oltp-read-only=on 表示是只读测试，off 表示不要进行只读测试，也就是会采用读写混合模式测试，

–report-interval=10 表示每 10 秒输出一次测试进度报告

–rand-type=uniform 表示随机类型为固定模式，其他几个可选随机模式：uniform(固定),gaussian(高斯),special(特定的),pareto(帕累托)，special 表示存在热点数据，uniform 表示非热点数据模式, 默认是 special

–mysql-table-engine=xxx：表的存储引擎类型，innodb、myisam 这些都可以

–max-time=3600 表示最大执行时长为 3600 秒

–max-requests=0 表示总请求数为 0，因为上面已经定义了总执行时长，所以总请求数可以设定为 0；也可以只设定总请求数，不设定最大执行时长

–percentile=99 表示设定采样比例，默认是 95%，即丢弃 1%的长请求，在剩余的 99%里取最大值

即：模拟对 10 个表并发 OLTP 测试，每个表 1000 万行记录，持续压测时间为 1 小时。

注意，针对不同的选项取值就会有不同的子选项。比如 oltp-dist-type=special，就有比如 oltp-dist-pct=1、oltp-dist-res=50 两个子选项，代表有 50%的查询落在 1%的行（即热点数据）上，另外 50%均匀的(sample uniformly)落在另外 99%的记录行上。

再比如 oltp-test-mode=nontrx 时, 就可以有 oltp-nontrx-mode，可选值有 select（默认）, update_key, update_nokey, insert, delete，代表非事务式模式下使用的测试 sql 类型。

从监控脚本看

通过监控脚本可以看到类似结果

从 console 看数据库性能

我们可以关注数据库实例的 CPU 利用率，连接数，IO 和网络性能指标

Sysbench 结果

在每个 sysbench 客户端可以看到类似输出：

同样地，在所有 sysbench client 同时执行命令模拟负载，每次持续 5 分钟，同时使用监控脚本监视数据库的性能，从 console 查看 CPU，IO，网络等 metrics。在这里我们将通过修改 num_threads 参数连续测试 4250,4750,41250 和 4*1500 多种并发连接的场景。

./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-tablesize=25000 --mysql-db=<mysql db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=on --num-threads=1000 --report-interval=10 run >> mysql_r.log

从监控脚本看

通过监控脚本可以看到类似结果

从 console 看数据库性能

我们可以关注数据库实例的 CPU 利用率，连接数，IO 和网络性能指标

Sysbench 结果

在每个 sysbench 客户端可以看到类似输出：

3.2 读/写混合压力测试

./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --mysql-db=<aurora db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=off --num-threads=1000 --oltp-tablesize=25000 --oltp-tables-count=250 --report-interval=10 run>>aurora_w.log

./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-tablesize=25000 --mysql-db=<mysql db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=off --num-threads=1000 --report-interval=10 run >> mysql_w.log

3.3 结果分析

只读负载

在不同并发连接数下，Aurora 和 MYSQL 只读混合负载测试数据如下：

| 400并发| 1000并发| 2000并发| 3000并发| 4000并发| 5000并发| 6000并发

复制代码

QPS mysql| 112K| 108K| 95K| 88K| 44K| 17K| 8.9K

QPS aurora| 440K| 680K| 776K| 748K| 726K| 683K| 659K

CPU mysql| 98| 99| 99| 99| 90| 57| 39

CPU aurora| 90| 96| 97| 98| 98| 98| 98

Response time mysql| 39.27ms | 103.08ms | 230.70ms | 365.23ms | 974.83ms | 4106.50ms | 8076.35ms

Response time aurora | 11.71ms | 19.12ms| 33.10ms| 51.32ms| 72.03ms| 93.36ms| 114.96ms

读/写混合负载

在不同并发连接数下，Aurora 和 MYSQL 读/写混合负载测试数据如下：

| 400并发| 1000并发| 2000并发| 3000并发| 4000并发| 5000并发| 6000并发

复制代码

QPS/TPS mysql| 84K| 88K| 76K| 56K| 29K| 28K| 16K

QPS/TPS aurora| 160K| 188K| 184K| 172K| 152K| 140K| 128K

CPU mysql| 75| 81| 90| 69| 73| 81| 87

CPU aurora| 77| 92| 97| 97| 98| 98| 98

Response time mysql| 68.94ms | 168.17ms | 384.80ms | 778.60ms | 2073.83ms | 2569.24ms | 5815.39ms

Response time aurora | 38.89ms | 81.51ms| 163.37ms | 259.77ms | 391.70ms| 534.18ms| 638.33ms

分析

通过以上测试数据，我们可以得出以下结论

四、清除环境

参考资料

《Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational>

《Amazon Aurora Performance Assessment》

总结

本文主要是为大家梳理用 sysbench 对 Aurora 和 MYSQL 进行性能测试的流程，启发大家做数据库性能测试的思路，当您按本文步骤进行测试的时候，随着环境，测试步骤的不同，需要对命令参数进行微调，测试结果也会相应变化，但测试的思路以及测试结果变化的客观规律却是共通的。除了 sysbench，我们还有其他的性能测试工具，譬如 mysqlslap 或 tpcc-mysql，本篇限于篇幅，没有介绍，在以后的 blog 中，我们再做介绍。

作者介绍：

吕琳

AWS解决方案架构师，负责基于 AWS 的云计算方案的咨询与架构设计，同时致力于数据库和大数据方面的研究和推广。在加入AWS 之前曾在Oracle担任高级讲师并在Amazon担任高级DBA，在数据库设计运维调优、DR解决方案、大数据以及企业应用等方面有丰富的经验。

复制代码

原文链接：

对Aurora进行压力测试

一、前言

二、环境准备

2.1 环境信息

测试端

数据库

2.2 安装和配置 sysbench

2.3 打开限制

2.4 模拟数据注入

参数含义

2.5 监控脚本

三、测试

3.1 只读压力测试

参数说明

从监控脚本看

从 console 看数据库性能

Sysbench 结果

从监控脚本看

从 console 看数据库性能

Sysbench 结果

3.2 读/写混合压力测试

3.3 结果分析

只读负载

读/写混合负载

分析

四、清除环境

参考资料

总结

MySQL数据库安全之审计 (mysql数据类型)

没有了！

一、前言

二、环境准备

2.1 环境信息

测试端

数据库

2.2 安装和配置 sysbench

2.3 打开限制

2.4 模拟数据注入

参数含义

2.5 监控脚本

三、测试

3.1 只读压力测试

参数说明

从监控脚本看

从 console 看数据库性能

Sysbench 结果

从监控脚本看

从 console 看数据库性能

Sysbench 结果

3.2 读/写混合压力测试

3.3 结果分析

只读负载

读/写混合负载

分析

四、清除环境

参考资料

总结

相关文章

MySQL数据库安全之审计 (mysql数据类型)

没有了！