-|--010-56122325
js28.com
您的位置: » » 数据库MySQL的机能基线收集及压力测试

常见问题

数据库MySQL的机能基线收集及压力测试
2014-10-26 14:18

竖立基线的感化:
计算机科学中,基线是项目储存库中每一个工件版本正在特定期间的一个“快照”。

好比我们如今有并发事物,那么正在某时刻提议一个事物会发生当前数据的快照,那么这个快照便相称明白为一个基线,那么所谓的机能数据的基线就是一般数据收集后的一段时间大概业务数据的负载,将它供应一个正式尺度,随后的事情基于此尺度,而且只要经由受权后才气调换这个尺度。竖立一个初始基线后,今后每次对其停止的调换皆将纪录为一个差值,直到建成下一个基线。

 

什么是基线

1.当前运转状况纪录、快照,其感化是将其取将来的状况做对照,那么将来的时候发生的关键时刻的新状况则作为下一次的状况做对照

2.将来时候发生要害事宜后的新状况,作为下一个基线

 

基线收集,需存眷的重点

1.体系负载
2.MySQL运转状况

 

纪录以上两个重点以便用于优化,好比做一次优化之前先纪录一周的状况,好比最高、最低、均匀等

优化的事情完毕以后,我们再去逐步视察,如许我们便能晓得也许状况是怎样

然则有些时刻有些误区,好比正在优化之前tps能够1000 ,优化后能够照样1000,然则但从tps来看的话能够没有甚么,然则我们借需求存眷它的iops等信息有所下落,那也是一种优化,以是要多纬度的去对照

 

发起收集基线数据的状况信息(需求存眷的瓶颈

体系层需存眷的信息:

·CPU:%user、%idle、%sys、%iowait      #最通用的几个目标
·IO:tps、await、svctm、%util

·内存:free(free、shared、buffers、cached)、used,和swap

    内存的利用率越多越好,以是我们重要存眷余暇、运用、另有swap ,si so

    当前是不是运用swap 是不是频仍运用swap 也需求存眷     

 

数据库层需存眷的信息:

MySQL:tps、rt、lock、hit ratio、waits

rt = response time          
lock = row lock
、table lock
hit ratio = cache/buffer hit ratio
waits = Innodb_buffer_pool_wait_free / Innodb_log_waits / Table_locks_waited / Innodb_row_lock_current_waits / Innodb_row_lock_waits

正在找瓶颈的时刻优先那几个中央停止剖析,针对剖析效果再界说优化计划

 

事情结果量化

所谓的量化,实在不过是对照(雷同条件下、雷同场景下)

    雷同条件下:比如说同一套硬件,之前之能跑tps到1000,然则优化后tps能到达5000,那是很大的转变

雷同场景下:之前的资源利用率是10% 但优化后降到了5%

 

雷同业务负载下,基线数据发生转变

好比一样的用户量 一样的装备,经由优化的以后,tps是低落照样提拔,util、cpu等

 

雷同基线数据状况下,业务数据发作转变

 

竖立目的,考据计划可行及总结

我们需求竖立一套尺度去考证我们的要领是不是可行
·竖立目的
·针对当前基线中存在的瓶颈停止优化
·常见瓶颈以IO为主(磁盘IO、网络IO)
·制订相对应的计划,找到优化的实验途径
·CPU:%user、%idle、%sys、%iowait
·IO:tps、await、svctm、%util
·内存:free(free、shared、buffers、cached)、used,和swap
·MySQL:tps、rt、lock、hit ratio、waits

 

假定做的优化,针对IO 那么重点纪录的是io相干的状况,然后正在优化完再判定util等io相干的数值是不是发生了转变

也就是说优化事情是需求针对当前基线数据中的瓶颈停止的,

一般的瓶颈,现在来讲照样磁盘IO和网络IO

 

 

优化IO路子的发起:

1. 换SSD,PCIE-SSD(进步IO效力,一般SAS盘5000之内的iops,而新装备可到达数万大概数十万iops)
2. 少做IO的活(兼并屡次读写为一次,大概前端加内存CACHE;大概优化业务,消弭IO)
3. 加大内存(更多hot data和dirty data放正在内存中,削减物理IO)
4. 调解文件系统为xfs(比拟ext3、ext4进步IOPS才能,下io负载下显示更佳)
5. 调解raid级别为raid 1+0(比拟raid1、raid5等进步IOPS才能)
6. 调解写cache战略为wb或force wb(应用阵列卡cache,进步iops)
7. io scheduler(优先运用deadline,若是是SSD,则运用noop

 

以是我们想要优化IO(磁盘IO或网络IO,)的瓶颈,一般是只要能用钱处理的事变一般便不是事变了,换个装备一般比大量工夫破费正在优化上要来的强

 

网络IO很少,由于一般状况下mysql的tps现实能到达1-2000算是不错的,除非用高配服务器,那么这种情况下它的网络交互也不是题目,以是这种情况下网络IO一样平常不会成为瓶颈,若是是高配的话,一样平常网卡的机能要进步上去,好比多网卡绑定的体式格局,大概换成万兆网卡,一般状况下千兆网卡便够了

 

正在找瓶颈的时刻优先那几个中央停止剖析,针对剖析效果再界说优化计划

 

 

通用的优化计划
·CPU:改换更好(将主频更高一些)、更多中心的CPU(重要看硬件不够用照样中心数不够用,好比频仍切换cpu)

   好比在在多实例的状况下,最好是有多核心的cpu,另一种,若是运算义务对照重的话这时候我们借同时需求进步单CPU的运算才能,也就是进步主频

·IO:改换IOPS机能更高的装备,比方SSD,PCI-E SSD

 

·内存:增添内存,公道分派

 

·MySQL效劳:晋级版本,运用Percona/MariaDB分支版本以支撑更高TPS大概低落锁合作粒度(重要是低落锁的力度,将大锁拆成小锁,如许能够观察其均衡怎样,若是这些小锁拆分对照好,会带来比较大的tps的提拔,大概个体参数的调解,由于有可能我们某些参数设置欠妥而致使tps上不去也是有可能的)

 

一般状况下优先晋级IO装备,好比硬盘,之前的硬盘用的是7200转的盘,如今将其改换为SATA硬盘,或则间接换SSD等;内存也是一样的,间接加内存便可,如许能够有用的应用内存去缓存数据削减IOPS,进步整体TPS

 

 

mysql的压力测试

基准压力测试目标
·采购新装备,评价新装备机能

扔去装备的新旧架构等,我们需求对其停止评价新装备的机能


·开辟新项目,评价数据库容量_j

8.com

     新项目上线,我们需求评价新项目存在哪些瓶颈


·新体系上线前,预估/模仿数据库负载

好比新的操作系统,好比centos7 ,那么我们念试一试换成7的话机能取之前的版本的机能差异正在那里

并且借需求模仿新项目的并发等,我们需求判定一下我们的单台服务器可否扛住若干,多台服务器能扛住若干

 

·改换数据库版本,评价机能转变

 

·除机能,借需求存眷可靠性

数据库运转一段时间是不是稳固,是不是可持续

若是发明一些非常,好比数据库不开释内存等也是异常贫苦的事变,最怕的就是内存溢出

 

测试模子设想

·明白测试的中心目的、诉求

测试新版本机能/可靠性

测试新系统性能/可靠性

测试新机械机能/可靠性 

测试新业务机能

·扫除滋扰,专注测试目标

    不要跑分外的效劳,致使机能遭到影响

·肯定测试情况

  构建一个公道、适宜、科学的测试情况,不会和实际情况差异太大,硬件、体系、设置相称

·肯定测试历程中的权衡和变量

每一次对照测试轮回中,只调换少数身分,不要一次性调换太多身分

·包管测试效果的可重复性

包管每一个轮回皆最少有3次测试,每次连续最少30分钟,扫除最好和最差的测试效果

 

压测需求注意事项
·不克不及只正在当地停止压测

压力测试东西不克不及跟数据库在一起,由于压力测试东西自己便会发生一些负载,也会发生一些cpu大概斲丧一些内存,如许便不科学,以是发起将其支解开来

 

·压测数据量小

内存能够有32G,然则压力测试数据能够有10G,如许它会能够将数据悉数放正在内存内里,那若是将一切数据放正在内存里

 

·压测时间过短

瓶颈刚泛起的时刻压测曾经完毕了,一定是不靠谱的

·压测形式太少

一定要求有对照庞大的读写、随机读写、递次读写平分别都要压力测试

 

·压力负载过大或过小

一般需求存眷的值:

    %user, %iowati, %util, svctm, iops, tps

    尤其是 : %user, %iowati, %util, svctm rt(相应工夫) 不要过大

 

· 每轮测试终了要净化情况,若是有条件的话要将数据从新天生一次,若是出有条件的话无论如何要清算cache并重启mysqld:

     #消灭 OS cache

     echo 3 > /proc/sys/vm/drop_caches

     service mysqld restart

 

 

MySQL测试东西的运用

常用测试东西:
·sysbench
Primarily for MySQL OLTP benchmarking,By MySQL AB

老牌测试东西,若是只做一些cpu测试却是能够运用这个东西,模仿形式和表的模仿轻微偏偏简朴一些

重要针对于:cpu、threads、mutex、memory、fileio、oltp

 

·tpcc-mysql(重点)
Primarily for MySQL OLTP benchmarking,By Percona

 

·tpch
Primarily for OLAP benchmarking

 

·tcpcopy
  模仿消费情况实在恳求

·其他
   mysqlslap
   sql-bench

以上东西泛起的常见场景:

·fio做专业的IO压力测试

·用tpcc-mysql做MySQL的OLTP压力测试

·用tcpcopy做在线压力模仿测试

    好比我们当前业务每秒的生意业务数到达一千个,如今念模仿每秒生意业务数为一万个,一种是能够写一个剧本停止模仿,另一种运用tcpcopy将线上用户的恳求引入到某个测试情况下,好比当前有10台服务器将其悉数引到某个服务器上,好比之前有10台服务器而测试机只要一台服务器,如今将它悉数引到某个测试服务器上,相当于压力霎时大了10倍

大概将线上的前端服务器上的恳求复制到其他服务器上然后这些前端服务器将压力施加到测试服务器上,也是能够的

 

运用tpcc-mysql对数据库做压力测试

TPC-C是专门针对联机生意业务处置惩罚体系(OLTP体系)的范例,一般情况下我们也把这类体系称为业务处置惩罚体系。

tpcc-mysql是percona基于TPC-C(上面简写成TPCC)衍生出来的产物,公用于MySQL基准测试。其源码放正在launchpad上,用bazaar管理。

 

下载tppc-mysql

 

官方下载:
安装epel源后以便安装bzr客户端:

[root@mysql_node1 tools]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

[root@mysql_node1 tools]# rpm -ivh epel-release-6-8.noarch.rpm

 

然后便能够最先安装bzr客户端了:

[root@mysql_node1 tools]#  yum install bzr

 

以后,便能够最先用bzr客户端下载tpcc-mysql源码了

cd /tmp
bzr branch  percona-dev/perconatools/tpcc-mysql

 

或运用直达下载:

wget  http://imysql.com/wp-content/uploads/2014/09/tpcc-mysql-src.tgz

 

tpcc-mysql的重要事情流程

重要是模仿生意业务,流程以下:

起首需求定单--发生领取--堆栈发货--物流--确认收货

等类似于电商的历程,然后去模仿下并发去完成一个典范电商的业务

 

tpcc-mysql的业务逻辑及其相干的几个表感化以下:
  ·New-Order:新定单,重要对应 new_orders 表
  ·Payment:领取,重要对应 orders、history 表
  ·Order-Status:定单状况,重要对应 orders、order_line 表
  ·Delivery:发货,重要对应  order_line 表
  ·Stock-Level:库存,重要对应 stock 表

其他相干表:
 ·客户:重要对应 customer 表
 ·区域:重要对应 district 表
 ·商品:重要对应 item 表
 ·堆栈:重要对应 warehouse 表

 

我们做的只需求指定堆栈的数目便可,好比一个堆栈支持若干个地区的用户等

 

安装tpcc-mysql

安装历程不过就是解压并实行make 便可

无论是运用源码包、rpm、二进制包 只要能到达目标便可,凭据本身需求去停止安装

[root@mysql_node1 tpcc-mysql]# cd /tmp/

[root@mysql_node1 tmp]# wget http://imysql.com/wp-content/uploads/2014/09/tpcc-mysql-src.tgz

[root@mysql_node1 tmp]# tar xf tpcc-mysql-src.tgz

[root@mysql_node1 tpcc-mysql]# ll

total 36

-rw-r--r--. 1 root root  851 Sep 14 15:05 README

-rw-r--r--. 1 root root 1621 Sep 14 15:05 add_fkey_idx.sql

-rw-r--r--. 1 root root  317 Sep 14 15:05 count.sql

-rw-r--r--. 1 root root 3105 Sep 14 15:05 create_table.sql

-rw-r--r--. 1 root root  763 Sep 14 15:05 drop_cons.sql

-rw-r--r--. 1 root root  477 Sep 14 15:05 load.sh

drwxr-xr-x. 2 root root 4096 Oct 20 15:51 schema2

drwxr-xr-x. 5 root root 4096 Oct 20 15:51 scripts

drwxr-xr-x. 2 root root 4096 Oct 20 15:51 src

[root@mysql_node1 tpcc-mysql]# make

 

TPCC压测前的预备

初始化测试库情况

[root@mysql_node1 tmp]# cd /tmp/tpcc-mysql

[root@mysql_node1 tpcc-mysql]# ls

README  add_fkey_idx.sql  count.sql  create_table.sql  drop_cons.sql  load.sh  schema2  scripts  src

建立库并导入表构造

[root@mysql_node1 tpcc-mysql]# mysqladmin -uroot -p 'mypass' -f create  tpcc1000

[root@mysql_node1 tpcc-mysql]# mysql -uroot -pmypass -f tpcc1000 < create_table.sql

初始化终了后,便能够最先加载测试数据了
tpcc_load用法以下:

tpcc_load [server] [DB] [user] [pass] [warehouse]

大概

tpcc_load [server] [DB] [user] [pass] [warehouse] [part] [min_wh] [max_wh]

选项 warehouse 意为指定测试库下的堆栈数目。

 

若是默许不是3306端口的话能够运用以下体式格局:

#由因而实机以是这里先建立30个库,一样平常发起正在现实天生情况上建立的库要大于500

 [root@node1 tpcc-mysql]# ./tpcc_load 10.12.33.61:3306 tpcc1000 root mypass 30

*************************************

*** ###easy### TPC-C Data Loader  ***_7727金沙娱乐

*************************************

<Parameters>

     [server]: 10.12.33.61

     [port]: 3306

     [DBname]: tpcc1000

       [user]: root

       [pass]: mypass

  [warehouse]: 100

TPCC Data Load Started...

Loading Item

.................................................. 5000

.................................................. 10000

###略####

若是不是运用tcp/ip体式格局去衔接数据库的话,它默许会间接读取当地mysql.sock文件

以是我们最好运用ip:prot的体式格局去衔接数据库

500 为初始化若干个库的数据量,这里由因而虚拟机以是量轻微少一些

 

停止TPCC测试

tpcc_start 东西用于tpcc压测,其用法以下

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

 

参数注释

-w     指定堆栈数目
-c     指定并发衔接数
-r     指定最先测试前停止warmup的工夫,停止预热后,测试结果更好
-l     指定测试持续时间
-i     指定天生讲演距离时少
-f     指定天生的讲演文件名

-r     指定最先测试前停止warmup的工夫,停止预热后,测试结果更好
-l     指定测试持续时间

 

一个完好的测试案例

起首正在数据库停止受权

mysql> GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY 'mypass';

运用tpcc停止压测

#由因而实机以是这里先建立30个库,一样平常发起正在现实天生情况上建立的库要大于500

#tpcc_start -hlocalhost -d tpcc1000 -u tpcc_user -p "tpcc_password" -w 30 -c 32 -r 120 -l 3600 \

  -f tpcc_mysql_20140921.log >> tpcc_caseX_$(date +%F).log 2>&1

将其停止简化:

[root@node1 tpcc-mysql]# ./tpcc_start -h10.12.33.61 -d tpcc1000 -u root -p 'mypass' -w 30 -c 32 -r 120 -l 1800 >> /tmp/tpcc_caseX_$(date +%F).log 2>&1

以上的意义是只将效果输出出来没有必要将整个过程输出, 3600 示意1小时

 

检察输出的效果

本轮tpcc压测的一些基本信息
[root@node1 ~]# more /tmp/tpcc_caseX_$(date +%F).log

***************************************

*** ###easy### TPC-C Load Generator ***

***************************************

option h with value '10.12.33.61'           #目的主机

option d with value 'tpcc1000'              #需求停止压测的数据库

option u with value 'root'                  #用户名

option p with value 'mypass'                #暗码

option w with value '30'                    #数据库数目

option c with value '32'                    #并发线程数目

option r with value '120'                   #预热时少

option l with value '1800'                  #压测总时长,半小时

<Parameters>

     [server]: 10.12.33.61

     [port]: 3306

     [DBname]: tpcc1000

       [user]: root

       [pass]: mypass

  [warehouse]: 30

 [connection]: 32

     [rampup]: 120 (sec.)

    [measure]: 1800 (sec.)

 

RAMP-UP TIME.(120 sec.)

预热完毕而且最先停止压测,为了模仿历程以是收缩了一点

MEASURING START.

#每10秒钟输出一次压测数据

 

  10, 117(104):17.862|21.403, 108(1):4.954|6.161, 10(0):3.733|5.880, 12(0):19.999|41.257, 13(13):19.999|54.707

  20, 104(92):14.839|16.684, 106(0):2.932|4.367, 12(0):1.042|1.083, 10(0):15.888|16.643, 12(12):19.999|47.363

  30, 94(89):15.864|19.204, 101(0):3.613|4.152, 9(0):0.999|1.039, 9(0):19.232|20.073, 8(8):19.999|40.352

  40, 105(89):14.086|15.177, 99(0):3.690|4.408, 9(0):1.180|2.024, 12(0):19.999|21.756, 11(11):19.999|46.144

#############以下略过################_9446.com

 

离别示意的意义:

统共6列 以逗号停止分开

-- 第一列,第N次10秒_金沙7817

-- 第二列,总胜利实行压测的次数(总推延实行压测的次数):90%事件的相应工夫|本轮测试最大相应工夫
-- 第三列,新定单业务胜利实行次数(推延实行次数):90%事件的相应工夫|本轮测试最大相应工夫
-- 第四列,领取业务的效果,前面几个的意义同上
-- 第五列,发货业务的效果,前面几个的意义同上
-- 第六列,库存业务的效果,前面几个的意义同上

#若是凌驾5毫秒便会发作一次推延

 

 

压测完毕效果解读

 

[root@node1 ~]# tail -100  /tmp/tpcc_caseX_$(date +%F).log

 

找到以下效果信息

 

<Raw Results>

  [0] sc:1264  lt:14714  rt:0  fl:0         # New-Order,新定单业务胜利(success,简写sc)次数,提早(late,简写lt)次数,重试(retry,简写rt)次数,失利(failure,简写fl)次数

  [1] sc:15834  lt:138  rt:0  fl:0          # Payment,领取业务统计,其他同上

  [2] sc:1580  lt:17  rt:0  fl:0            # Order-Status,定单状况业务统计,其他同上

  [3] sc:1598  lt:0  rt:0  fl:0             # Delivery,发货业务统计,其他同上

  [4] sc:0  lt:1602  rt:0  fl:0             # Stock-Level,库存业务统计,其他同上

 in 1800 sec.

 

#一次的采样结果是不可信的

 

#以下第二次大略统计效果,其他同上

<Raw Results2(sum ver.)>

  [0] sc:1264  lt:14714  rt:0  fl:0    

  [1] sc:15835  lt:138  rt:0  fl:0

  [2] sc:1580  lt:17  rt:0  fl:0

  [3] sc:1598  lt:0  rt:0  fl:0

  [4] sc:0  lt:1602  rt:0  fl:0

 

上面一切业务逻辑效果皆必需为 OK 才止,若是哪怕有一个不是OK那么暂是NG,若是有任何一个结果是NG的话注解本次结果是不克不及采信的,

 

<Constraint Check> (all must be [OK])

 [transaction percentage]

        Payment: 43.46% (>=43.0%) [OK]      #领取胜利次数(上述统计效果中 sc + lt)总胜利+提早的效果 必需大于43.0%,不然效果为NG,而不是OK,以是若是不是大于43%那么效果也是不克不及采信的

   Order-Status: 4.35% (>= 4.0%) [OK]       #定单状况,其他同上

       Delivery: 4.35% (>= 4.0%) [OK]       #发货

    Stock-Level: 4.36% (>= 4.0%) [OK]       #库存

 

 [response time (at least 90% passed)]      #相应耗时目标必需凌驾90%经由过程才止,所谓的响应经常就是小于5毫秒的测试尺度,凌驾5毫秒一定是弗成以的,若是有10%以上的相应经常阐明本次效果弗成采信的

#上面几个相应耗时目标悉数 100% 经由过程才能够,若是低于90%的话,那么一定是NG ,我这里泛起了2个NG

        New-Order: 7.91%  [NG] *           

        Payment: 99.14%   [OK]

        Order-Status: 98.94%  [OK]

        Delivery: 100.00%   [OK]

        Stock-Level: 0.00%  [NG] *

 

<TpmC>

                 532.600 TpmC           # tpmc示意每分钟的tps