主要内容:
1.MySQL压力测试基准值;
2.mysqlslap的介绍及使用;
3.sysbench的介绍及使用;
4.tpcc-mysql的介绍及使用;
MySQL压力测试基准值
1.压力测试的目的:
1.确认新的MySQL版本性能相比之前差异多大;比如从5.6变成5.7,或者从官方版本改成Percona分支版本;
2.确认新的服务器性能是否更高,能高多少;比如CPU升级了,阵列卡cache加大了,从机械盘换成SSD盘了;
3.确认一些新的参数调整后,对性能影响多少;比如innodb_flush_log_at_trx_commit,sync_binlog等参数;
4.确认即将上线的新业务对MySQL负载影响多少,是否能承载得住,是否需要对服务器进行扩容或升级配置;
2.针对不同的压测目的,相应的测试方法也有所不同:
1.先说第四种,需要和线上业务结合起来,这时候就需要自行开发测试工具,或者利用tcpcopy(https://github.com/session-replay-tools/tcpcopy)将线上实际用户请求导向测试环境,进行仿真模拟测试;
2.对于前三种,我们通常采用基准测试就可以;比较常用的MySQL基准压力测试工具有tpcc-mysql,sysbench,mysqlslap等几个;
3.如何避免压测时受到缓存的影响:
1.填充测试数据比物理内存还要大,至少超过innodb_buffer_pool_size值,不能将数据全部装载到内存中,除非你的本意就想测试全内存状态下的MySQL性能;
2.每轮测试完成后,都重启mysqld实例,并且用下面的方法删除系统cache,释放swap(如果用到了swap的话),甚至可以重启整个OS;
1.将脏数据刷新到磁盘:sync;
2.清除OS Cache:echo 3 > /proc/sys/vm/drop_caches
3.释放swap:swapoff -a && swapon -a;
4.如何尽可能体现线上业务真实特点:
1.其实上面已经说过了,就是自行开发测试工具或者利用tcpcopy(或类似交换机的mirror功能)将线上实际用户请求导向测试环境,进行仿真模拟测试;
2.利用http_load或siege工具模拟真实的用户请求URL进行压力测试;
5.压测结果如何解读:
1.压测结果除了tps/TpmC指标外,还应该关注压测期间的系统负载数据,尤其是iops,iowait,svctm,%util,每秒I/O字节数(I/O吞吐),事务响应时间(tpcc-mysql/sysbench打印的测试记录中均有);另外,如果I/O设备能提供设备级IOPS,读写延时数据的话,也应该一并关注;
2.假如两次测试的tps/TpmC结果一样的话,那么谁的事务响应时间,iowait,svctm,%util,读写延时更低,就表示那个测试模式有更高的性能提升空间;
6.如何加快tpcc_load加载数据的效率:
1.tpcc_load其实是可以并行加载的,一方面是可以区分ITEMS,WAREHOUSE,CUSTOMER,ORDERS四个维度的数据并行加载;
2.另外,比如最终想加载1000个warehouse的话,也可以分开成1000个并发并行加载的;
3.github上有并行加载的项目tpcc_load_parallel.sh,加载效率至少提升10倍以上;
mysqlslap的介绍及使用
1.mysqlslap简介:
1.它是MySQL从5.1.4版开始自带的一个基准测试工具,该工具可以模拟多个客户端同时并发的向服务器发出查询更新,给出了性能测试数据而且提供了多种引擎的性能比较;
2.mysqlslap为MySQL性能优化前后提供了直观的验证依据,从而帮助DBA准确的掌握线上数据库支撑的用户流量上限及其抗压性等问题;
3.查看帮助:mysqlslap –help
4.使用方法:mysqlslap [OPTIONS];
5.默认的读取配置文件的顺序:/etc/my.cnf,/etc/mysql/my.cnf,/usr/local/mysql/etc/my.cnf,~/.my.cnf;
2.参数说明:
–defaults-file:指定从配置文件中读取选项配置;
-?, –help:查看帮助;
-a, –auto-generate-sql:自动生成测试表和数据;
–auto-generate-sql-add-autoincrement:自动生成的表中添加自增列;
–auto-generate-sql-execute-number=#:自动生成的查询的个数;
–auto-generate-sql-guid-primary:自动在表上添加基于GUID的主键;
–auto-generate-sql-load-type=name:指定测试负载的类型,取值包括:mixed(默认,一半插入一半查询),update,write,key(读主键)和read;
–auto-generate-sql-secondary-indexes=#:在自动生成的表上添加第二索引的个数,默认0;
–auto-generate-sql-unique-query-number=#:生成基于唯一键查询的测试语句数量,默认10;
–auto-generate-sql-unique-write-number=#:生成基于唯一键写的测试语句数量,默认100;
–auto-generate-sql-write-number=#:每个线程执行插入的记录数量,默认100;
–commit=#:多少条DML后提交一次;
-C, –compress:如果服务器和客户端支持都压缩,则压缩信息传递;
-c, –concurrency=name:模拟查询的客户端并发数量,多个可以使用逗号分割;
–create=name:创建表的SQL语句或者文本文件;
–create-schema=name:指定测试的数据库,不指定就自动创建一个mysqlslap的schema;
–csv[=name]:生成CSV格式的结果,如果不指定名字就打印到标准输出,指定名字就打印到指定的文件中;
-#, –debug[=#]:指定debug模式;
–debug-check:退出时检查相关的内存和打开文件使用信息;
-T, –debug-info:额外输出CPU以及内存的相关信息;
–default-auth=name:默认的客户端插件验证文件;
-F, –delimiter=name:定义SQL使用的分隔符;
–detach=#:执行N条语句后断开重连;
–enable-cleartext-plugin:开启/禁用明文验证插件,具体查看MySQL几种身份验证方式;
-e, –engine=name:创建测试表使用的引擎,多个引擎用逗号分割;
-h, –host=name:连接到的服务器信息;
-i, –iterations=#:运行测试的次数;
–no-drop:在测试完成之后不删除测试表;
-x, –number-char-cols=name:测试表中VARCHAR类型列的个数,默认1个,仅当指定–auto-generate-sql参数时有效;
-y, –number-int-cols=name:测试表中VARCHAR类型列的个数,默认1个,仅当指定–auto-generate-sql参数时有效;
–number-of-queries=#:总的测试查询次数(并发客户数×每客户查询次数);
–only-print:不连接到数据库,只打印相应的SQL语句,即测试过程的SQL语句;
-p, –password[=name]:密码信息;
–plugin-dir=name:客户端插件目录;
-P, –port=#:连接的端口号;
–post-query=name:在测试脚本运行后执行的脚本,这个过程不影响时间计算;;
–post-system=name:在测试脚本运行后执行的系统命令;
–pre-query=name:在测试脚本运行前执行的脚本;
–pre-system=name:在测试脚本运行前执行的系统命令;
–protocol=name:用户连接时使用的协议,eg:tcp,socket,pipe,memory;
-q, –query=name:用自定义脚本执行测试
–secure-auth:安全验证,拒绝客户端使用旧的协议连接服务器,默认开启,但是可以指定–skip-secure-auth参数来关闭;
-s, –silent:静默模式下运行程序;
-S, –socket=name:连接时指定socket文件;
–ssl:连接时开启SSL;
-u, –user=name:用户名信息;
-v, –verbose:输出信息的详细的级别,eg:-vvv;
-V, –version:版本信息;
3.查看测试过程:mysqlslap -a –only-print;
4.测试实例(多线程测试):
mysqlslap -uroot -p –concurrency=100 –iterations=1 –auto-generate-sql –auto-generate-sql-load-type=mixed –auto-generate-sql-add-autoincrement –engine=InnoDB –number-of-queries=10 –debug-info
说明:测试100个并发线程;测试次数1次;自动生成SQL测试脚本;读,写,更新混合测试;自增长字段;测试引擎为InnoDB;共运行10次查询;输出CPU资源信息;
5.测试实例(迭代测试,多次测试得出平均值):
mysqlslap -uroot -p –concurrency=50,100,200 –iterations=20 –number-int-cols=4 –number-char-cols=35 –auto-generate-sql –auto-generate-sql-load-type=mixed –auto-generate-sql-add-autoincrement –engine=MyISAM,InnoDB –number-of-queries=200 –debug-info -v
说明:测试50,100,200个并发线程;测试次数20次;四个int列和35个varchar列;自动生成SQL测试脚本;读,写,更新混合测试;自增长字段;测试引擎为M有ISAM,InnoDB;共运行200次查询;输出CPU资源信息;想要输出所有信息加-vvv;
TIPS:并发数越多,执行完所有查询的时间越长,为了准确起见,可以多迭代测试几次;
6.总结:
1.无法规定表中测试数据的数量;
2.可以使用压力测试工具super-smack for MySQL,但是却一直没有人维护了;
— 补充:
MySQL的几种身份验证方式:MySQL主要是用自身的User Table作身份认证,但可以加入其它plugin authentication;
1.The Native Authentication Plugins;
2.The PAM Authentication Plugin;
3.The Windows Native Authentication Plugin;
4.The Clear-Text Client-Side Authentication Plugin:在客户端发送明文给服务端验证,http://dev.mysql.com/doc/refman/5.5/en/cleartext-authentication-plugin.html;
5.The Socket Peer-Credential Authentication Plugin;
6.The Test Authentication Plugin;
sysbench的介绍及使用
1.sysbench简介:
1.sysbench是一个模块化的,跨平台,多线程基准测试工具,主要用于评估测试各种不同系统参数下的数据库负载情况;
2.sysbench的目的是1)不需要设置复杂的数据库基准测试,2)甚至根本不需要安装一个数据库的情况下,可以快速了解系统性能状况;
3.目前sysbench代码托管在github上(https://github.com/akopytov/sysbench),在之前还经历了由sourceforge(http://sysbench.sourceforge.net)到launchpad(https://launchpad.net/sysbench)的迁移;
4.最新版本为0.5;
5.使用C语言写的一个工具;
2.sysbench支持以下几种测试模式:
1.CPU运算性能;
2.磁盘IO性能;
3.调度程序性能;
4.内存分配及传输速度;
5.POSIX线程性能;
6.数据库性能(OLTP基准测试),eg:MySQL,Drizzle(精简版的MySQL分支),PostgreSQL,Oracle等几种数据库;
3.安装sysbench:
1.安装依赖包:sysbench依赖automake和libtool两个包,yum -y install automake libtool;
2.解压缩:unzip sysbench-0.5.zip;
3.自动配置:./autogen.sh;
4.指定编译配置:./configure –prefix=/usr/local/sysbench –with-mysql-includes=/usr/local/mysql/include –with-mysql-libs=/usr/local/mysql/lib;默认支持MySQL,如果需要测试Oracle/PostgreSQL,则在configure时需要加上–with-oracle或者–with-pgsql参数;如果想要默认不支持MySQL,需要添加–without-mysql参数;
5.编译安装:make && make install;
6.修改PATH环境变量;
7.报错修复,[./sysbench: error while loading shared libraries: libmysqlclient.so.18: cannot open shared object file: No such file or directory],是因为sysbench无法找到mysql的库文件,可能是环境变量LD_LIBRARY_PATH没有设置,export LD_LIBRARY_PATH=/usr/local/mysql/lib即可;
4.参数介绍:
1.使用方法:sysbench [general-options]… –test= [test-options]… command;
2.一般选项:
–num-threads=N:使用的测试线程数,默认为1;
–max-requests=N:最大请求数量,默认为1W,0表示不限制;
–max-time=N:最大执行时间,单位是s,默认0为不限制;与–max-requests二选一;
–forced-shutdown=STRING:超过–max-time指定时间后强制中断,默认为off;
–thread-stack-size=SIZE:每个线程使用的栈大小,默认是64K;
–tx-rate=N:target transaction rate (tps) [0];
–report-interval=N:阶段性的报告中间统计信息,单位为s,默认0为禁用此阶段性的报告;
–report-checkpoints=[LIST,…]:在指定的时间点,导出所有的统计信息,并且重置所有的计数器;可以指定用逗号分割的列表,单位是s,默认是关闭的;
–percentile=N:表示设定采样比例,默认是95%;可以设置99%即丢弃1%的长请求,在剩余的99%里取最大值;
–test=STRING:指定测试的项目;
–debug=[on|off]:是否打印调试信息,默认为off;
–validate=[on|off]:在可能的情况下执行验证检查,默认为off;
–help=[on|off]:查看帮助信息;
–version=[on|off]:打印版本信息;
–rand-init=[on|off]:测试开始时是否初始化随机数生成器,默认为off;
–rand-type=STRING:随机数分布模式,eg:uniform(固定),gaussian(高斯),special(特定的,默认),pareto(帕累托);
1.special表示存在热点数据;
2.uniform表示非热点数据模式;
–rand-spec-iter=N:数字生成器中使用迭代器的数量,默认是12;
–rand-spec-pct=N:special类型数据的比率,默认是1;
–rand-spec-res=N:special值使用的比率,默认是75;
–rand-seed=N:随机数生成器的种子,默认为0;
–rand-pareto-h=N:pareto数据分布模式下参数h的值,默认是0.2;
3.日志选项:
–verbosity=N:日志级别,5是debug级别,0是只打印严重错误信息,默认为3;
–percentile=N: percentile rank of query response times to count [95]
4.测试的项目:
1.fileio – File I/O test
2.cpu – CPU performance test
3.memory – Memory functions speed test
4.threads – Threads subsystem performance test
5.mutex – Mutex performance test
6.oltp – OLTP test,在0.5版本之前有,已被替换掉;
5.命令:
1.prepare:执行测试前的准备工作;比如fileio测试时在磁盘上创建必要的文件,或者在oltp测试时填充测试数据库;
2.run:执行真实的测试;
3.cleanup:测试后移除运行时产生的临时数据;
4.help:查看指定测试项目的帮助;eg:sysbench –test=cpu help;
5.CPU测试:
1.相关选项:
–cpu-max-prime=N:最大质数发生器数量,即产生N个素数,默认为10000;
2.测试计算产生2000个素数所需要的时间:sysbench –test=cpu –cpu-max-prime=2000 run;
3.查看CPU相关信息:less /proc/cpuinfo;
6.线程(threads)测试:
1.测试线程调度器的性能,对于高负载情况下测试线程调度器的行为非常有用;
2.相关选项:
–thread-yields=N:每个请求产生多少个线程,默认为1000;
–thread-locks=N:每个线程的锁的数量,默认为8;
3.使用64个线程,每个请求产生100个线程,线程锁数为2:sysbench –test=threads –num-threads=64 –thread-yields=100 –thread-locks=2 run;
7.文件IO性能测试:
1.相关选项:
–file-num=N:创建测试文件的数量,默认为128;
–file-block-size=N:测试时文件块的大小,默认是16384(16K);
–file-total-size=SIZE:测试文件的总大小,默认是2G;
–file-test-mode=STRING:文件测试模式,eg:seqwr(顺序写),seqrewr(顺序读写),seqrd(顺序读),rndrd(随机读),rndwr(随机写),rndrw(随机读写);
–file-io-mode=STRING:文件操作模式,eg:sync(同步,默认),async(异步),fastmmap(快速map映射),slowmmap(慢map映射);
–file-extra-flags=STRING:使用额外的标志来打开文件,eg:sync,dsync,direct;默认为空;
–file-fsync-freq=N:执行fsync()的频率,默认是100,0表示不使用fsync();
–file-fsync-all=[on|off]:每执行完一次写操作就执行一次fsync,默认是off;
–file-fsync-end=[on|off]:在测试结束时才执行fsync,默认是on;
–file-fsync-mode=STRING:使用哪种方法进行同步,eg:fsync(默认),fdatasync;
–file-merged-requests=N:如果可以,合并最多的IO请求数,默认是0表示不合并;
–file-rw-ratio=N:测试时的读写比例,默认是1.5;
2.测试:文件总大小为2G,20个并发线程,随机读写;
1.prepare阶段:sysbench –test=fileio –num-threads=20 –file-total-size=2G –file-test-mode=rndrw prepare
2.run阶段:sysbench –test=fileio –num-threads=20 –file-total-size=2G –file-test-mode=rndrw run
3.清理测试时生成的文件:sysbench –test=fileio –num-threads=20 –file-total-size=2G –file-test-mode=rndrw cleanup
8.互斥锁(Mutex)测试:
1.相关选项:
–mutex-num=N:数组互斥的总大小,默认是4096;
–mutex-locks=N:每个线程互斥锁的数量,默认是50000;
–mutex-loops=N:内部互斥锁的空循环数量,默认是10000;
2.测试互斥锁的性能,方式是模拟所有线程在同一时刻并发运行,并都短暂请求互斥锁:sysbench –-test=mutex –-num-threads=100 –-mutex-num=1000 –-mutex-locks=100000 –-mutex-loops=10000 run
9.内存测试:
1.相关选项:
–memory-block-size=SIZE:测试时内存块大小,默认是1K;
–memory-total-size=SIZE:传输数据的总大小,默认是100G;
–memory-scope=STRING:内存访问范围,eg:global(默认),local;
–memory-hugetlb=[on|off]:从HugeTLB池内存分配,默认是off;
–memory-oper=STRING: 内存操作类型,eg:read,write(默认),none;
–memory-access-mode=STRING:存储器存取方式,eg:seq(默认),rnd;
2.内存测试测试了内存的连续读写性能:sysbench –test=memory –memory-block-size=8k –memory-total-size=1G run
10.MySQL数据库测试:
1.sysbench v0.5通过一系列LUA脚本来替换之前的oltp,从而来模拟更接近真实的基准测试环境;
2.脚本在//sysbench-0.5/sysbench/tests/db/目录下,这些测试脚本包含:insert.lua,oltp.lua,parallel_prepare.lua,select_random_points.lua,update_index.lua,delete.lua,oltp_simple.lua,select.lua,select_random_ranges.lua,update_non_index.lua,脚本使用方式基本类似;
3.sysbench v0.5默认使用sbtest库,但是需要自己手工先创建好,也可以使用–mysql-db指定,其他非默认项指定选项:
–mysql-host=[LIST,…]:MySQL服务器地址,默认为localhost;
–mysql-port=N:MySQL服务器端口号,默认为3306;
–mysql-socket=STRING:MySQL socket;
–mysql-user=STRING:MySQL用户,默认为sbtest;
–mysql-password=STRING:MySQL密码;
–mysql-db=STRING:MySQL数据库名称,默认为dbtest;
–mysql-table-engine=STRING:使用的引擎,eg:myisam,innodb(默认),bdb,heap,ndbcluster,federated;
–mysql-engine-trx=STRING:存储引擎是否使用事务,eg:yes,no,auto(默认);
–mysql-ssl=[on|off]:是否使用ssl连接,默认为off;
–mysql-create-options=:创建脚本是否添加CREATE TABLE,默认为空;
4.准备阶段:生成表并插入数据,可使用parallel_prepare.lua脚本来并行准备数据;
–db-driver:服务器类型,eg:mysql(默认),drizzle;
–mysql-table-engine:表存数引擎;
–myisam-max-rowsMyISAM引擎表的最大记录数,默认为100W;
–oltp-table-count:生成表数量,名字为:sbtest1、sbtest2…;
–oltp-table-size:生成表的行数;
–oltp-secondary:ID列生成二级索引而不是主键;
–oltp-auto-inc=[on|off]:设置ID列是否自增,默认为on;
5.运行阶段:
–oltp-tables-count=N:表的数量;
–oltp-read-only=[on|off]:是否仅执行SELECT测试;默认为off,表示不要进行只读测试,也就是会采用读写混合模式测试;
–oltp-dist-type:随机数分布状态,eg:uniform(均匀分布),gauss(高斯分布),special(特殊分布);
–oltp-dist-pct:特殊分布的百分比值;
–oltp-dist-res:特殊分布的百分比;
–oltp-point-selects:单个事务中指定的selec查询个数;
–oltp-range-size:范围查询的范围大小,该值应比oltp-table-size小;
–oltp-simple-ranges:单个事务中指定的简单范围查询个数;
–oltp-sum-ranges:单个事务中指定的SUM范围查询个数;
–oltp-order-ranges:单个事务中指定的ORDER范围查询个数;
–oltp-distinct-ranges:单个事务中指定的DISTINCT范围查询个数;
–oltp-index-updates:单个事务中指定的使用索引更新的个数;
–oltp-non-index-updates:单个事务中指定的不使用索引更新的个数;
6.清理阶段;
7.测试:
1.准备(方法1):sysbench –mysql-db=test –mysql-user=root –mysql-password= –test=/tools/sysbench-0.5/sysbench/tests/db/oltp.lua –mysql-table-engine=innodb –oltp-table-size=100000 prepare
2.准备(方法2,准备数据后运行):也可使用parallel_prepare.lua脚本并行准备测试数据,线程数应该为运行表的倍数;sysbench –mysql-db=sbtest –mysql-user=root –mysql-password= –test=/tools/sysbench-0.5/sysbench/tests/db/parallel_prepare.lua –mysql-table-engine=innodb –oltp-table-size=100000 –num-threads=10 –oltp-tables-count=10 run
3.运行:sysbench –mysql-db=test –mysql-user=root –mysql-password= –test=/tools/sysbench-0.5/sysbench/tests/db/oltp.lua –num_threads=10 –oltp-tables-count=10 –oltp-table-size=100000 –num-threads=8 –report-interval=10 –rand-type=uniform –max-time=100 –percentile=99 run
4.清理:sysbench –mysql-db=test –mysql-user=root –mysql-password= –test=/tools/sysbench-0.5/sysbench/tests/db/oltp.lua –oltp-table-size=100000 –oltp-tables-count=10 cleanup
8.可以对数据库进行调优后,再使用sysbench对OLTP进行测试,看看TPS是不是会有所提高;
9.TIPS:
1.sysbench的测试只是基准测试,并不能代表实际企业环境下的性能指标;
2.真实测试场景中,数据表建议不低于10个,单表数据量不低于500万行,当然了,要视服务器硬件配置而定;如果是配备了SSD或者PCIE SSD这种高IOPS设备的话,则建议单表数据量最少不低于1亿行;
3.真实测试场景中,建议持续压测时长不小于30分钟,否则测试数据可能不具参考意义;
10.参考文档:https://www.percona.com/docs/wiki/benchmark:sysbench:olpt.lua
— 运行报告解读;
Threads started!
— 每10秒钟报告一次测试结果:tps,每秒读,每秒写,99%以上的响应时长统计;
[ 10s] threads: 8, tps: 1111.51, reads/s: 15568.42, writes/s: 4446.13, response time: 9.95ms (99%)
[ 20s] threads: 8, tps: 1121.90, reads/s: 15709.62, writes/s: 4487.80, response time: 9.78ms (99%)
[ 30s] threads: 8, tps: 1120.00, reads/s: 15679.10, writes/s: 4480.20, response time: 9.84ms (99%)
[ 40s] threads: 8, tps: 1114.20, reads/s: 15599.39, writes/s: 4456.30, response time: 9.90ms (99%)
[ 50s] threads: 8, tps: 1114.00, reads/s: 15593.60, writes/s: 4456.70, response time: 9.84ms (99%)
[ 60s] threads: 8, tps: 1119.30, reads/s: 15671.60, writes/s: 4476.50, response time: 9.99ms (99%)
OLTP test statistics:
queries performed:
read: 938224 — 读总数
write: 268064 — 写总数
other: 134032 — 其他操作总数(SELECT,INSERT,UPDATE,DELETE之外的操作,例如COMMIT等)
total: 1340320 — 全部总数
transactions: 67016 (1116.83 per sec.) — 总事务数(每秒事务数)
deadlocks: 0 (0.00 per sec.) — 发生死锁总数
read/write requests: 1206288 (20103.01 per sec.) — 读写总数(每秒读写次数)
other operations: 134032 (2233.67 per sec.) — 其他操作总数(每秒其他操作次数)
General statistics: — 一些统计结果
total time: 60.0053s — 总耗时
total number of events: 67016 — 共发生多少事务数
total time taken by event execution: 479.8171s — 所有事务耗时相加(不考虑并行因素)
response time: — 响应时长统计
min: 4.27ms — 最小耗时
avg: 7.16ms — 平均耗时
max: 13.80ms — 最长耗时
approx. 99 percentile: 9.88ms — 超过99%平均耗时
Threads fairness:
events (avg/stddev): 8377.0000/44.33
execution time (avg/stddev): 59.9771/0.00
tpcc-mysql的介绍及使用
1.tpcc-mysql简介:
1.TPC-C是专门针对联机交易处理系统(OLTP系统)的规范,一般情况下我们也把这类系统称为业务处理系统;
2.tpcc-mysql是percona基于TPC-C(下面简写成TPCC)衍生出来的产品,专用于MySQL基准测试;
3.tpcc-mysql通过模拟一个电商的业务,主要包含的业务有新增订单,库存查询,发货,支付等模块的测试,用来测试典型的复杂OLTP系统的性能;
4.其源码放在launchpad上,用bazaar管理,项目地址:https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql;
2.安装:
1.解压缩:gunzip tpcc-mysql-src.tgz;tar -xvf tpcc-mysql-src.tar;
2.安装:cd /path/tpcc-mysql/src; make; 之后会在/path/tpcc-mysql目录下生成两个tpcc 命令行工具:tpcc_load,tpcc_start;
1.tpcc_load:提供初始化数据的功能;
2.tpcc_start:进行压力测试;
3.移动工具位置:mv /tools/tpcc-mysql/tpcc_start /tools/tpcc-mysql/tpcc_load /usr/local/bin/;
3.查看帮助:
1.tpcc_load –help:
usage: tpcc_load [server] [DB] [user] [pass] [warehouse]
OR
tpcc_load [server] [DB] [user] [pass] [warehouse] [part] [min_wh] [max_wh]
* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS
1.Server:服务器名;
2.DB:数据库名;
3.user:用户名;
4.pass:密码;
5.warehouse:测试库下仓库的数量;
6.part:tpcc_load其实是可以并行加载的,可以区分ITEMS/WAREHOUSE/CUSTOMER/ORDERS四个维度的数据并行加载(github上已经实现的并行加载的项目tpcc_load_parallel.sh:https://gist.github.com/sh2/3458844);
2.tpcc_start –help:
Usage: tpcc_start -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -c connections -r warmup_time -l running_time -i report_interval -f report_file -t trx_file
1.-h server_host:服务器名;
2.-P port:端口号,默认为3306;
3.-d database_name:数据库名;
4.-u mysql_user:用户名;
5.-p mysql_password:密码;
6.-w warehouses:仓库的数量;
7.-c connections:线程数,默认为1;
8.-r warmup_time:预热时间,预热是为了将数据加载到内存,单位s,默认为10s;
9.-l running_time:测试时间,单位s,默认为20s;
10.-i report_interval:指定生成报告间隔时长;
11.-f report_file:测试结果输出文件;
12.-t trx_file:事务文件;
4.测试前准备工作:
1.创建测试数据库:mysql -uroot -p -e “CREATE DATABASE tpcc”;
2.创建表:mysql -uroot -p tpcc < /tools/tpcc-mysql/create_table.sql;
3.添加外键:mysql -uroot -p tpcc < /tools/tpcc-mysql/add_fkey_idx.sql;
4.查看tpcc-mysql的业务逻辑及其相关的几个表作用如下:
1.customer:客户表;
2.district:地区表;
3.history:支付信息表;
4.item:商品信息表;
5.new_orders:新订单表,其它信息还是存在orders表中;
6.order_line:发货信息表;
7.orders:订单表;
8.stock:库存信息表;
9.warehouse:仓库表;
5.测试:
1.单进程加载数据:tpcc_load localhost tpcc root "" 5;
2.对5个数据仓库,预热10秒,100个并发连接,运行60秒:tpcc_start -h localhost -d tpcc -u root -p "" -w 5 -c 100 -r 10 -l 60 -i 10 -f rpt_tpcc -t tr;
6.不足:
1.没有自增列作为主键:如果仅作为基准测试问题不大,但和我们实际生产中的设计模式可能有一定区别,相信大多数人还是习惯使用自增列作为主键的;
2.使用外键:个人认为MySQL对外键支持并不是太好,并且一定程度上影响并发性能,因此建议取消外键,仅保留一般的索引;
7.其它:
1.真实测试场景中,仓库数一般不建议少于100个;视服务器硬件配置而定,如果是配备了SSD或者PCIE SSD这种高IOPS设备的话,建议最少不低于1000个;
2.真实测试场景中,建议预热时间不小于5分钟,持续压测时长不小于30分钟,否则测试数据可能不具参考意义;
3.需要注意的是tpcc默认会读取/var/lib/mysql/mysql.sock这个socket文件,如果你的socket文件不在相应路径的话,可以做个软连接;或者通过TCP/IP的方式连接测试服务器;
4.script目录下的一些脚本主要是一些性能数据采集以及分析的;
5.可以使用gunpolt工具画图;
-- 测试结果解读;
[root@ocp ~]# tpcc_start -h localhost -d tpcc -u root -p "" -w 5 -c 100 -r 10 -l 60 -i 10 -f rpt_tpcc -t tr;
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value 'localhost'
option d with value 'tpcc'
option u with value 'root'
option p with value ''
option w with value '5'
option c with value '100'
option r with value '10'
option l with value '60'
option i with value '10'
option f with value 'rpt_tpcc'
option t with value 'tr'
[server]: localhost
[port]: 3306
[DBname]: tpcc
[user]: root
[pass]:
[warehouse]: 5
[connection]: 100
[rampup]: 10 (sec.)
[measure]: 60 (sec.)
RAMP-UP TIME.(10 sec.)
— 预热结束,开始进行压测;
MEASURING START.
— 为了能够清晰的说明以下内容,首先定义一些变量,便于以下的计算和说明:
1.success:执行成功的记录数;
2.late:执行延迟的记录数;
3.pre_success:上一次执行成功的记录数;
4.pre_late:上一次执行失败的记录数;
— 根据以上定义的变量,计算相应字段的结果和说明相应字段的含义:
1.时间间隔内成功的事务(包括成功和延迟的事务):sl=success+late-pre_success-pre_late;
2.时间间隔内延迟的事务:l=late-pre_late;
3.时间间隔内前90%记录(实际为99%)的平均响应时间:rt90;
4.时间间隔内最大的响应时间:max_rt;
— Count New-Order Payment Order-Status Delivery Stock-Level
— #, sl(l):rt90|max_rt , sl(l):rt90|max_rt , sl(l):rt90|max_rt, sl(l):rt90|max_rt, sl(l):rt90|max_rt
— 新订单成功执行压测的次数(推迟执行压测的次数):90%事务的响应时间|本轮测试最大响应时间;
10, 485(0):2.431|3.536, 505(0):0.709|1.550, 49(0):0.331|0.363, 48(0):3.061|3.162, 49(0):5.823|6.181
20, 511(0):2.544|3.928, 517(0):0.813|1.757, 52(0):0.204|0.235, 52(0):2.543|2.725, 52(0):5.964|6.062
30, 516(0):2.109|3.152, 510(0):0.493|1.421, 51(0):0.257|0.415, 50(0):2.684|2.855, 51(0):5.783|5.875
40, 480(2):3.008|8.578, 479(0):1.688|1.882, 47(0):0.241|2.038, 47(0):2.869|3.197, 48(0):6.349|6.550
50, 478(1):2.926|10.509, 481(0):1.080|1.795, 48(0):0.406|1.721, 47(0):2.810|2.877, 48(0):6.247|7.598
60, 434(4):3.783|7.095, 426(0):1.258|1.724, 44(0):0.398|1.789, 45(0):3.080|3.604, 45(0):7.136|8.169
— 压测结束;
STOPPING THREADS……………………………………………………………………………………….
— 第一次结果统计;
— 成功(success,sc)次数,延迟(late,lt)次数,重试(retry,rt)次数,失败(failure,fl)次数;
[0] sc:2897 lt:7 rt:0 fl:0 — New-Order:新订单业务;
[1] sc:2918 lt:0 rt:0 fl:0 — Payment:支付业务统计;
[2] sc:291 lt:0 rt:0 fl:0 — Order-Status:订单状态业务统计;
[3] sc:289 lt:0 rt:0 fl:0 — Delivery:发货业务统计;
[4] sc:293 lt:0 rt:0 fl:0 — Stock-Level:库存业务统计;
in 60 sec.
— 第二次统计结果;
[0] sc:2897 lt:7 rt:0 fl:0
[1] sc:2918 lt:0 rt:0 fl:0
[2] sc:291 lt:0 rt:0 fl:0
[3] sc:289 lt:0 rt:0 fl:0
[4] sc:293 lt:0 rt:0 fl:0
— 下面所有业务逻辑结果都必须为OK才行;
(all must be [OK])
[transaction percentage]
Payment: 43.58% (>=43.0%) [OK] — 支付成功次数(sc + lt)必须大于43.0%,否则结果为NG,而不是OK;
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.32% (>= 4.0%) [OK]
Stock-Level: 4.38% (>= 4.0%) [OK]
— 响应耗时指标必须超过90%通过才行;
[response time (at least 90% passed)]
New-Order: 99.76% [OK]
Payment: 100.00% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 100.00% [OK]
2904.000 TpmC
— TpmC结果值(每分钟事务数,该值是第一次统计结果中的新订单事务数除以总耗时分钟数,eg:(2897+7)/1 = 2904.000;
