第4章 压力测试
压力测试是指在MySQL上线前，需要进行大量的压力测试，从而达到交付的标准。压力测试不仅可以测试MySQL服务的稳定性，还可以测试出MySQL和系统的瓶颈。
4.1 TPC-C模型
TPC（Transaction Processing Performance Council）是一系列事务处理和数据库基准测试的规范。其中TPC-C是针对OLTP的基准测试模型，一方面可以衡量数据库的性能，另一方面可以衡量硬件性价比，也是广泛应用并关注的一种测试模型。
TPC-C模型是以一个在线零售业为例，设计的一种模型。具体架构如下所示：
TPC-C测试模型给基准测试提供了一种统一的测试标准，并非实际应用系统中的真实测试结果，但通过测试结果，可以大体观察出MySQL数据库服务稳定性、性能以及系统性能等一系列问题。
4.2 测试工具
TPC-C仅仅是一个测试模型，而在实际测试中，需要参考和使用一些测试工具，对系统和MySQL数据库进行压力测试、稳定性测试。以下内容，将介绍常用的系统测试和MySQL数据库测试常用的一些工具。
4.2.1 fio
fio是系统IO测试的工具，覆盖多种不同类型、不同方式的IO测试，并且简单易用。fio在压力测试中，常用于了解不同文件操作的IOPS极限，可以更加全面的了解系统IO处理能力。
1、编译安装
fio是开源的工具，可以在官方网址 http://freecode.com/projects/fio 查看相关的内容，源码编译和安装如下所示：
| 1、安装依赖
yum install libaio yum install libaio-devel 2、获取源码 wget http://brick.kernel.dk/snaps/fio-2.1.7.tar.bz2 3、编译安装 tar -xjf fio-2.1.7.tar.bz2; cd fio-2.1.7 ./configure make & make install |
2、使用说明
fio工具支持多种类型的测试，并且参数非常多，可以通过帮助文档获得使用信息。以下内容简单说明如何查看帮助文档。
| 主要参数说明：
–help：获得帮助信息。 –cmdhelp：获得命令的帮助文档。 –enghelp：获得引擎的帮助文档。 –debug：通过debug方式查看测试的详细信息。（process, file, io, mem, blktrace, verify, random, parse, diskutil, job, mutex, profile, time, net, rate） –output：测试结果输出到文件。 –output-format：设置输出格式。（terse, json, normal） –crctest：测试crc性能。（md5, crc64, crc32, crc32c, crc16, crc7, sha1, sha256, sha512, xxhash:） –cpuclock-test ：CPU始终测试。 |
3、测试
fio测试的类型和选项非常多，但是通常情况下，对于MySQL数据库服务器，一般测试随机读、随机写、随机读写三种情况下，sync、fsync的ioengine方式下，IO的性能指标情况。通过测试这些指标，可以对系统的IO处理能力进行资源评估和分配。
| fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -rw=randread -ioengine=sync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest
参数说明 filename：测试的系统盘目录。 direct：测试绕过机器自带的buffer，使测试结果更真实。 iodepth：设置IO队列的深度。 rw：测试读写类型。 ioengine：io引擎方式。 bs：数据块大小。 size：测试文件的大小。 numjobs：测试次数。 runtime：测试时间。 rwmixwrite：在混合读写的模式下，写占的权重。 group_reporting：测试结果汇总每个进程的信息。 lockmem：测试使用内存大小。 zero_buffers：测试过程使用0初始化系统buffer。 nrfiles：测试过程中每个进程生成文件的数量。 |
4、测试结果
测试结果显示了详细的系统信息，包括io、latency、bandwidth、cpu等信息，详细如下所示：
| mytest: (groupid=0, jobs=10): err= 0: pid=10775: Thu Jun 12 08:47:28 2014
read : io=262560KB, bw=22965KB/s, iops=1435, runt= 11433msec clat (usec): min=108, max=57601, avg=488.40, stdev=483.77 lat (usec): min=108, max=57601, avg=488.62, stdev=483.78 clat percentiles (usec): | 1.00th=[ 112], 5.00th=[ 314], 10.00th=[ 334], 20.00th=[ 414], | 30.00th=[ 442], 40.00th=[ 462], 50.00th=[ 486], 60.00th=[ 506], | 70.00th=[ 532], 80.00th=[ 556], 90.00th=[ 620], 95.00th=[ 684], | 99.00th=[ 812], 99.50th=[ 868], 99.90th=[ 1144], 99.95th=[ 5024], | 99.99th=[10048] bw (KB /s): min= 1, max=42144, per=83.52%, avg=19179.29, stdev=16716.64 lat (usec) : 250=3.02%, 500=53.40%, 750=41.37%, 1000=2.04% lat (msec) : 2=0.08%, 4=0.03%, 10=0.05%, 100=0.01% cpu : usr=0.05%, sys=88.55%, ctx=17703, majf=0, minf=379 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=16410/w=0/d=0, short=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs): READ: io=262560KB, aggrb=22965KB/s, minb=22965KB/s, maxb=22965KB/s, mint=11433msec, maxt=11433msec
Disk stats (read/write): sdb: ios=16418/55, merge=57/69, ticks=7780/39, in_queue=7816, util=18.80% |
4.2.2 tpcc-mysql
tpcc-mysql是percona基于TPC-C模型，针对MySQL数据库开发的测试工具。从基准测试角度来说，tpcc-mysql是测试MySQL数据库相对权威的工具。
1、编译安装
由于tpcc-mysql使用bazaar进行源码管理，因此需要首先安装bazaar工具，才能获取源码。具体如下：
| 1、安装bazaar工具
yum install bzr 2、获取源码 bzr branch lp:~percona-dev/perconatools/tpcc-mysql 3、编译安装 cd tpcc-mysql/ & make |
2、常见问题
编译安装过程中，经常会遇到以下问题，一般通过变量声明即可编译通过，为了避免类似问题，建议将这些这些声明追加到bash_profile中。
| 1、找不到mysql的头文件
解决：export C_INCLUDE_PATH=$MYSQL_HOME/include 2、找不到mysql_config程序 解决：export PATH=$MYSQL_HOME/bin:$PATH 3、运行时找不到mysql库 解决：export LD_LIBRARY_PATH=$MYSQL_HOME/lib:$LD_LIBRARY_PATH |
3、数据准备
创建测试数据库，执行建表语句，通过编译生成的tpcc_load工具产生测试数据，测试数据根据数据库实例的配置，生成测试数据。
| 1、创建库
shell>mysql -e ‘create database tpcc300’ 2、创建表 shell>mysql tpcc300 < create_table.sql 3、添加外键 shell>mysql tpcc300 < add_fkey_idx.sql 4、加载数据 4.1、单进程加载： shell>./tpcc_load localhost tpcc300 root “” 300 |主机||数据库||用户||密码||warehouse| 4.2、并发加载：（推荐，但需要修改一下） shell>./load.sh tpcc300 300 |数据库||warehouse| |
4、测试
根据生成的测试数据，通过编译生成的tpcc_start工具，进行压力测试。根据测试数据量的不同，数据预热时间（避免由于数据没有预热，影响测试结果）也不同。测试时间根据测试要求不同，指定不同的测试时间。具体命令如下所示：
| ./tpcc_start -h localhost -d tpcc300 -u root -w 300 -c 32 -r 300 -l 7200 >> result.txt
参数说明： -h：测试主机 -d：测试的数据库 -u：测试的用户 -p：测试用户的密码 -w：测试的warehouse数 -c：测试的连接线程数 -r：预热时间 -l：测试时间 |
5、测试结果
测试期间，tpcc_start工具会输出实时的日志信息，这些信息包含了TPC-C模型中的五个业务逻辑：New-Order：新订单、Payment：支付、Order-Status：订单查询、Delivery：发货、Stock-Level：库存，在指定响应时间内，事务处理和完成情况。除了MySQL的输出日志之外，还需要关心系统的性能指标，因此需要借助iostat、vmstat等系统工具，查看系统的性能特征。
4.2.3 DBT2
DBT2也是一个优秀的压测工具，实现了TPC-C模型，不仅支持MySQL数据库，还支持其他类型的数据库。
1、编译安装
编译安装DBT2工具与普通C的源码编译安装基本没有什么差别，但是由于内部使用了一些脚本，因此需要安装这些依赖。
| 1、源码地址
http://osdldbt.sourceforge.net/ 2、安装依赖 安装所需要的perl包 sudo cpan Statistics::Descriptive sudo cpan Test:Parser sudo cpan Test::Reporter 3、编译 tar-xzf dbt2-<version>.tar.gz cd dbt2-<version>; ./configure –prefix=/usr/local/dbt2 –with-mysql=/usr/local/mysql –with-mysql-includes=/usr/local/mysql/include –with-mysql-libs=/usr/local/mysql/lib make & sudo make install |
2、数据准备
DBT2编译完成后，生成datagen工具，用于生成测试的数据文件，需要通过脚本进行加载。具体如下所示：
| 1、生成数据
datagen -w 300 -d /home/q/data300 –mysql 参数说明： -w：指定了数据仓库的个数 -d：指定了生成的数据所在的目录 2、加载数据 cd scripts/mysql sudo ./build_db.sh -d dbt2 -f /home/q/data300 -s /tmp/mysql.sock -h localhost-u root 参数说明： -d：数据库名 -f：数据文件地址 -g：生成数据文件 -m：数据库模式[OPTIMIZED|ORIG] (默认 OPTIMIZED) -s：UNIX socket -h：数据库主机 -u：用户名 -p：密码 -e：存储引擎[MYISAM|INNODB|BDB] (默认 INNODB) -l：使用LOCAL关键字加载数据 -v：verbose -w：warehouse |
3、测试
数据加载完成后，调用脚本进行压力测试，具体如下所示：
| cd scripts
sudo ./run_workload.sh 参数说明： -c：连接数 -d：持续时间 -w：WAREHOUSES -H：主机 -h：help -l：端口 -n：NO-THINK -o：USE_OPROFILE=1 -p：DB_PARAMS -s：SLEEPY -t：每个warehouse的线程数 -u：用户名 -x：用户密码 -z：注释COMMENT |
4、测试结果
测试结果比较直观简单，同样为了能够体现系统的运行状态，仍然需要采集系统的参数，进行统计和对比，发现系统的变化。
4.2.4 sysbench
Sysbench工具是集系统测试和数据库测试一体的测试工具，但是传统的sysbench在数据库测试方面，没有遵循TPC-C测试模型，仅仅支持单个表的数据。而在实际的业务场景中，业务逻辑复杂的多。开源的优势就是，会有很多人参与进来，共同完善。Sysbench目前支持多个表的压测，并且通过自定义lua业务测试模型，使得测试更符合业务场景。
1、编译安装
由于sysbench多表压测的源码使用bazaar进行管理，因此需要首先安装bazaar工具，才能获取源码。
| 1、安装bazaar工具
yum install bzr 2、获取源码 bzr branch lp:sysbench 3、编译安装 cd sysbench/; ./configure –prefix=/usr/local/sysbench –with-mysql-includes=/usr/local/mysql/include –with-mysql-libs=/usr/local/mysql/lib make & make install |
2、数据准备、测试
Sysbench通过调用parallel_prepare.lua脚本，进行并行数据准备。数据准备就绪后，调用oltp.lua脚本进行压力测试。有大量的测试参数，可以指定不同类型的操作比例，从而控制业务模型。参数可以参考说明文档，不在赘述。
| 1、数据准备
./sysbench –test=tests/db/parallel_prepare.lua –max-time=100 –oltp-dist-type=uniform –max-requests=0 –mysql-user=test –mysql-password=test –mysql-table-engine=innodb –oltp-table-size=100 –oltp-tables-count=32 –oltp-range-size=90 –oltp-point-selects=1 –oltp-simple-ranges=1 –oltp-sum-ranges=1 –oltp-order-ranges=1 –oltp-distinct-ranges=1 –oltp-non-index-updates=10 –num-threads=20 –mysql-host=127.0.0.1 –mysql-port=3306 prepare 2、测试 ./sysbench –test=tests/db/oltp.lua –max-time=100 –oltp-dist-type=uniform –max-requests=0 –mysql-user=test –mysql-password=test –mysql-table-engine=innodb –oltp-table-size=100 –oltp-tables-count=32 –oltp-range-size=90 –oltp-point-selects=1 –oltp-simple-ranges=1 –oltp-sum-ranges=1 –oltp-order-ranges=1 –oltp-distinct-ranges=1 –oltp-non-index-updates=10 –num-threads=20 –mysql-host=127.0.0.1 –mysql-port=3306 run |
Sysbench还可以测试系统资源的性能，测试过程中，往往会首先通过sysbench测试系统的IO、内存、线程并发等性能。而MySQL的测试由于不是统一的测试模型，因此测试的结果会根据测试方法的不同，表现出较大的差异。
4.3 基准测试
基准测试不单单指TPC-C测试模型，在实际测试过程中，需要适当考虑业务场景，使用合适的测试工具进行测试，更广泛意义上算是业务模型交付测试。
基准测试主要测试不同用户连接数，不同数据压力，在常用MySQL数据库实例配置下的性能指标。
不同用户连接数：如果web应用有统一的配置，那么可以根据web应用的连接池情况，进行梯度设置。例如10台web服务器，每个web服务器的连接池最小限制为5，最大限制为30，增长为5，那么用户连接数的设置可以按照50~300，梯度为50进行测试。如果web应用无统一的配置，可以通过设定进行测试，一般为设定为16~256，梯度为2^5~8指数增长进行测试。
不同数据压力：不同数据量，对MySQL不同实例配置（INNODB_BUFFER_POOL_SIZE），内存命中率会有较大差异，从而性能指标也会有所不同。在数据压力测试时，一般测试数据量分为：测试数据量小于INNODB_BUFFER_POOL_SIZE，主要用于测试完全内存操作时，MySQL的性能指标；测试数据量为INNODB_BUFFER_POOL_SIZE的1.1倍（内存命中率大约为90%左右）时，MySQL的性能指标；测试数据量为INNODB_BUFFER_POOL_SIZE的1.25倍（内存命中率大约为80%）时，MySQL的性能指标。过分的降低INNODB_BUFFER_POOL_SIZE的命中率进行测试，对基准测试并没有很大的参考价值，如果命中率较低，那么应该考虑提高MySQL实例的配置，提高MySQL的性能。
常用MySQL数据库实例配置：正如机器选型中所说，提供单机处理能力，降低IDC的成本，但是不同业务场景、不同MySQL数据库实例所需的配置不同。为了能充分发挥服务器的性能，会根据需求在单台服务器上部署多个实例。因此，测试过程中，会根据INNODB_BUFFER_POOL_SIZE的大小，分成不同规格的MySQL实例，进行基准测试。例如：按照100G内存，一般按照INNODB_BUFFER_POOL_SIZE占用内存的70%计算，即70G内存。测试中分别测试1个实例（70G），2个实例（35G）下单个实例测试，2个实例（35G）下两个实例测试。
基准测试时，需要固定两个参数，变化另一个参数进行基准测试，从而得出不同条件下MySQL实例的性能指标。否则测试不能反映不同条件下的基准，也不能反映不同条件下的性能变化。
由于基准测试与业务场景有较大关系，因此在测试模型选择上，可以分为只读测试、TPC-C测试、读写比自定义测试。
4.3.1 只读测试
只读测试是对只读业务场景（例如读写分离的备库、历史数据、统计汇总数据等）进行模拟，测试MySQL数据库实例的基准性能。
只读测试目前已知开源工具有sysbench，支持多种只读测试场景，可以根据测试需求，进行多种场景的测试或者组合测试。Sysbench目前支持：
点查询（oltp-point-selects）测试：是指通过主键或者唯一键，唯一确定一条记录的查询场景。对于只读测试，由于不同业务系统的查询模型不同，而基准测试也无法模拟所有的只读场景，因此通常将点查询测试作为基准测试。
范围查询（oltp-simple-ranges）测试：是指通过查询条件过滤，获取条件范围内的查询场景。
范围统计查询（oltp-sum-ranges）测试：是指在范围查询基础上，对查询范围内的记录进行sum()获得统计结果的查询场景。
范围排序查询（oltp-order-ranges）测试：是指在范围查询基础上，对查询范围内的记录进行排序（order by）的查询场景。
范围唯一查询（oltp-distinct-ranges）测试：是指在范围测试基础上，对查询范围内的记录进行去重操作（distinct或group by）的查询场景。
4.3.2 TPC-C测试
TPC-C标准测试模型，是作为OLTP系统常用的基准测试。常用的TPC-C测试工具有TPCC-MySQL和DBT2，一般选择TPCC-MySQL作为TPC-C基准测试的首选工具。
TPC-C测试中需要根据测试的指标和参数，调整MySQL的性能参数，测试出不同实例配置和压力下，给出最佳的性能指标。
4.3.3 读写比自定义测试
读写比自定义测试主要是根据不同的业务情况，自定义读写比进行测试。不同于TPC-C测试，自定义读写比测试可以相对真实的模拟业务。目前开源工具中，可以通过sysbench定义不同的类型的操作，设置权重，灵活控制读写比例。
4.4 定制测试
定制测试是指现有的工具和测试模型，不能尽可能的模拟线上业务场景，为了能够真实的反应业务场景下MySQL数据库的性能，对测试工具和模型进行定制化。
4.4.1 定制SQL模型
定制SQL模型主要是通过了解业务场景，将调用的SQL语句和调用的逻辑提取出来，作为SQL测试的模型。然后对当前业务场景的MySQL数据库实例进行数据恢复，将SQL模型应用在数据库实例上，测试出MySQL数据库实例所能承担的最大压力。
这种方法的优点是：真实的测试业务场景下，MySQL数据库实例的性能指标。不足之处：每个业务场景都要进行单独抽象，很难构建一个统一的模型；需要进行数据恢复，会消耗较多数据准备时间。
4.4.2 定制开发工具
定制开发工具是对现有工具改造，或者通过设计开发一套灵活、便于配置、并且最大可能的符合不同业务场景的需求。
sysbench工具非常灵活，可以通过根据业务模型定制lua脚本，进行数据准备和压力测试。因此，在定制开发工具时，基于sysbench提供的基础功能，定制开发不同业务场景的测试脚本，既可以节省开发成本，也可以尽可能的模拟业务场景。
如果sysbench无法满足需求，或者定制成本较高，可以设计开发测试工具。一种设计思路是：
1、配置SQL模型。为了适合不同的业务场景，可以通过配置SQL模型的方式，提高工具的灵活性，而不需要单独去开发定制业务模型。
2、配置压力。大多数情况下，压力测试往往是进行极限测试，而在极限测试时，很多性能指标已经使得业务不能接受。因此，在设计开发中，可以通过灵活配置压力，对测试的真实反映有较好的帮助。
4.4.3 流量加速回放
流量加速回放是指对当前业务的MySQL数据库实例的压力进行录制，然后通过数据恢复的方式准备测试数据，进行数据回放。为了能够测试MySQL数据库实例承担的压力，对流量进行加速回放测试。
流量加速回放有两种方式，一种是通过抓包的方式，对MySQL数据库实例进行流量回放。另一种方式是记录所有执行的SQL语句，对MySQL数据库实例进行流量回放。
抓包方式，目前可以通过tcpcopy开源工具进行流量加速回放的方式进行测试。这种方式可以实现在线流量回放，但是抓包和回放过程中，有可能会丢包，而在加速回放过程中，丢包情况会比较严重，会表现出抖动比较严重的情况。但是这种设计思路，处理策略，非常值得借鉴。
记录执行的SQL语句的方式有很多方法，常用的方式：一种是打开general log，记录所有的SQL记录；另一种是通过MySQL进行插件开发，通过审计接口实现SQL记录。其中general log对现有的数据库实例有一定的性能影响，并且录制结束后，需要对general log进行处理后再进行流量回放。而插件开发的方式，可以精细化控制和定制，流量回放可以通过设计，实现在线流量回放。
4.4.4 全链路测试
全链路测试是通过在业务层模拟业务场景，从而产生数据库的压力。一方面可以验证数据库的压力情况，另一方面可以定位整个业务流程中，业务系统的瓶颈。
目前全链路测试有两种方式：一种是业务系统复制，重新搭建一套完整的业务系统，对业务系统进行压力测试；另一种是影子系统，对现有的系统建立影子系统，数据库建立规则影子表，通过一定的路由规则，进行压力测试。业务系统复制，需要消耗大量的成本投入，仅仅用于测试非常浪费。而影子系统，是在现有的系统之上，进行在线的压力测试，因此这种方式风险巨大。
4.5 性能评估
通过压力测试，需要对一些指标进行评估，测试的指标包括：TPS、QPS、RT、稳定性、CPU、IO、内存、网络。通过各种测试，还需要定位瓶颈是什么，如果是MySQL数据库的瓶颈，可以通过参数优化的方式，提高性能；如果是系统瓶颈，需要对机器选型提出新的建议和要求。
如果所有的测试过程都通过部署采集脚本，对测试指标进行采集并离线处理和展示，会浪费大量的时间在后期处理中。为了能够实时显示测试的指标，避免离线数据处理，可以部署监控系统，一劳永逸。
4.7 参考资料
1、《TPC Benchmarks》http://www.tpc.org/information/benchmarks.asp
2、《TPC BENCHMARK™ C》
3、《fio》http://freecode.com/projects/fio
4、《Fio Output Explained》http://tobert.github.io/post/2014-04-17-fio-output-explained.html
5、《TPCC-MySQL使用说明》http://blog.chinaunix.net/uid-26896862-id-3188313.html
6、《TPCC-MySQL输出结果详解 》http://blog.chinaunix.net/uid-26896862-id-3563600.html
7、《DBT》http://sourceforge.net/apps/mediawiki/osdldbt/index.php?title=Main_Page
8、《DBT2使用说明 》http://blog.chinaunix.net/uid-26896862-id-3188314.html
9、《Sysbench》http://sysbench.sourceforge.net/
10、《SysBench: a system performance benchmark》https://code.launchpad.net/sysbench
11、《Using Lua-enabled sysbench》https://blog.mariadb.org/using-lua-enabled-sysbench/
12、《oltp.lua》http://www.percona.com/docs/wiki/benchmark:sysbench:olpt.lua
13、《Sysbench with support of multi-tables workload》http://www.mysqlperformanceblog.com/2011/04/29/sysbench-with-support-of-multi-tables-workload/
14、《tcpcopy》http://code.google.com/p/tcpcopy/
15、《阿里2013双十一备战中的技术突破》http://www.kankanews.com/ICkengine/archives/73645.shtml
相关文章
转载请注明：爱开源 » MySQL数据库运维