一、环境:京东云Centos6.8 ,cpu16核,内存32G,SAS 3G,转速未知 ,SSD云盘300G
mysql 版本是:5.7.20 ,默认rpm安装,单实例。
压测工具是:tpcc-mysql5.0
mysql压力测试在京东云ssd云盘
首先加载数据,加载10个warehouse,现在数据库tpcc1000有9张表,warehouse10条记录,stock表有100万,item表有10万,order_line299万,new_orders11万,orders30万, customer30万。
二、测试一下云盘的iops。
三、所有参数不改变,默认安装,以此作为压力测试的基准线,进行对比分析,同时附上iostat 和压测结果
四、更改几个核心参数,可以看到tps大幅度提高到1217(75035/60).
五、测试3,增加参数innodb_io_capacity,按照理论,tps应该增加的,但是反而下降。
六、增加并发连接到128个
七、开启二进制日志功能,以及刷盘方式,对tps影响都是巨大的。这个结论也可以理解,不停的写二进制日志。假如整个数据库只用innodb一种引擎,又写二进制日志,又写innodb日志,不是重复吗?但是在线日志对数据库的性能影响是绝对巨头的,甚至可以认为是决定性的。
八、把数据量增加到50个warehouse.这个时候,数据量是这样的:
现在数据库tpcc1000有 9张表,warehouse10条记录,stock表有500万,item表有10万,order_line1499万,new_orders45万,orders150万, customer150万,查看一下实际表空间的大小3.9G:
九、来做一个压测,这里要说明一下测试7参数配置和测试6配置一样。从结果来看,增加数据量,对tps影响不大。主要参数如下:
innodb_buffer_pool_size = 22938M
innodb_buffer_pool_instances = 8
skip-name-resolve
transaction_isolation=READ-COMMITTED
innodb_log_file_size = 512M
innodb_log_buffer_size = 128M
innodb_log_files_in_group=5
innodb_temp_data_file_path=ibtmp1:512M:autoextend
#autocommit=0
server_id=1
binlog_format=row
log_bin = binlog
sync_binlog=0
十、把warehouse 增加到500个,
把数据量增加到50个warehouse.这个时候,数据量是这样的:
现在数据库tpcc1000有 9张表,warehouse10条记录,stock表有5000万,item表有10万,order_line1.49亿,new_orders450万,orders1500万, customer1500万,查看一下实际表空间的大小38G:
十一、先做一个测试线,看看情况有报错,报错如下:
1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382)
mysql 版本是:5.7.20 ,默认rpm安装,单实例。
压测工具是:tpcc-mysql5.0
mysql压力测试在京东云ssd云盘
首先加载数据,加载10个warehouse,现在数据库tpcc1000有9张表,warehouse10条记录,stock表有100万,item表有10万,order_line299万,new_orders11万,orders30万, customer30万。
- 现在数据库tpcc1000有9张表,warehouse10条记录,stock表有100万,item表有10万,order_line1186万,new_orders11万,orders118万, customer30万,查看一下实际表空间的大小:
- [mysql@mysql3 mysql1]$ ls -lhS tpcc1000/
- total 2.3G
- -rw-r----- 1 mysql mysql 1.6G Jan 5 18:51 order_line.ibd
- -rw-r----- 1 mysql mysql 352M Jan 5 18:51 stock.ibd
- -rw-r----- 1 mysql mysql 188M Jan 5 18:51 customer.ibd
- -rw-r----- 1 mysql mysql 96M Jan 5 18:51 history.ibd
- -rw-r----- 1 mysql mysql 68M Jan 5 18:51 orders.ibd
- -rw-r----- 1 mysql mysql 17M Jan 5 17:47 item.ibd
- -rw-r----- 1 mysql mysql 13M Jan 5 18:51 new_orders.ibd
- -rw-r----- 1 mysql mysql 96K Jan 5 18:51 district.ibd
- -rw-r----- 1 mysql mysql 96K Jan 5 18:51 warehouse.ibd
- -rw-r----- 1 mysql mysql 9.2K Jan 5 17:44 customer.frm
- -rw-r----- 1 mysql mysql 9.0K Jan 5 17:44 stock.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 5 17:44 order_line.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 5 17:44 district.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 warehouse.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 orders.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 history.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 5 17:44 item.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 5 17:44 new_orders.frm
- -rw-r----- 1 mysql mysql 65 Jan 5 17:40 db.opt
二、测试一下云盘的iops。
点击(此处)折叠或打开
- 在京东云上面的高效云盘测试,首先测试云盘的SSD的iops随机读写是4144
- [root@mysql3 data]# fio --name=myjob --filename=/dev/vdb --ioengine=libaio --direct=1 --bs=4k --rw=randrw --iodepth=32 --runtime=60
- myjob: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
- fio-2.0.13
- Starting 1 process
- Jobs: 1 (f=1): [m] [100.0% done] [1408K/1332K/0K /s] [352 /333 /0 iops] [eta 00m:00s]
- myjob: (groupid=0, jobs=1): err= 0: pid=10136: Fri Jan 5 16:31:42 2018
- read : io=999840KB, bw=16578KB/s, iops=4144 , runt= 60310msec
- slat (usec): min=2 , max=191 , avg= 6.23, stdev= 3.63
- clat (usec): min=177 , max=727001 , avg=3576.38, stdev=23287.21
- lat (usec): min=208 , max=727011 , avg=3583.03, stdev=23287.50
- clat percentiles (usec):
- | 1.00th=[ 270], 5.00th=[ 302], 10.00th=[ 322], 20.00th=[ 350],
- | 30.00th=[ 374], 40.00th=[ 394], 50.00th=[ 418], 60.00th=[ 438],
- | 70.00th=[ 466], 80.00th=[ 502], 90.00th=[ 572], 95.00th=[ 660],
- | 99.00th=[150528], 99.50th=[171008], 99.90th=[246784], 99.95th=[350208],
- | 99.99th=[399360]
- bw (KB/s) : min= 680, max=81632, per=100.00%, avg=16654.07, stdev=29344.48
- write: io=976.74MB, bw=16584KB/s, iops=4145 , runt= 60310msec
- slat (usec): min=2 , max=768 , avg= 8.32, stdev= 6.68
- clat (usec): min=126 , max=730161 , avg=4122.61, stdev=24096.23
- lat (usec): min=360 , max=730172 , avg=4131.36, stdev=24096.59
- clat percentiles (usec):
- | 1.00th=[ 482], 5.00th=[ 540], 10.00th=[ 580], 20.00th=[ 620],
- | 30.00th=[ 660], 40.00th=[ 692], 50.00th=[ 724], 60.00th=[ 756],
- | 70.00th=[ 788], 80.00th=[ 836], 90.00th=[ 932], 95.00th=[ 1080],
- | 99.00th=[154624], 99.50th=[175104], 99.90th=[248832], 99.95th=[350208],
- | 99.99th=[399360]
- bw (KB/s) : min= 720, max=81520, per=100.00%, avg=16658.87, stdev=29264.19
- lat (usec) : 250=0.12%, 500=40.73%, 750=36.85%, 1000=17.52%
- lat (msec) : 2=2.07%, 4=0.16%, 10=0.03%, 20=0.04%, 50=0.64%
- lat (msec) : 100=0.01%, 250=1.75%, 500=0.10%, 750=0.01%
- cpu : usr=2.24%, sys=8.53%, ctx=142694, majf=0, minf=24
- IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
- issued : total=r=249960/w=250039/d=0, short=r=0/w=0/d=0
-
- Run status group 0 (all jobs):
- READ: io=999840KB, aggrb=16578KB/s, minb=16578KB/s, maxb=16578KB/s, mint=60310msec, maxt=60310msec
- WRITE: io=976.74MB, aggrb=16583KB/s, minb=16583KB/s, maxb=16583KB/s, mint=60310msec, maxt=60310msec
-
- Disk stats (read/write):
- vdb: ios=250022/250028, merge=0/0, ticks=881619/1016273, in_queue=1902612, util=99.90%
三、所有参数不改变,默认安装,以此作为压力测试的基准线,进行对比分析,同时附上iostat 和压测结果
点击(此处)折叠或打开
- 测试1 基准测试线。使用mysql5.7.20,所有的参数不改变,默认安装,开始压测,做为基准线。
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '10'
- option c with value '64'
- option r with value '60'
- option l with value '180'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 10
- [connection]: 64
- [rampup]: 60 (sec.)
- [measure]: 180 (sec.)
-
- RAMP-UP TIME.(60 sec.)
-
-
- <Raw Results>
- [0] sc:35014 lt:1 rt:0 fl:0
- [1] sc:35002 lt:0 rt:0 fl:0
- [2] sc:3501 lt:0 rt:0 fl:0
- [3] sc:3497 lt:0 rt:0 fl:0
- [4] sc:3501 lt:0 rt:0 fl:0
- in 180 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:35014 lt:1 rt:0 fl:0
- [1] sc:35015 lt:0 rt:0 fl:0
- [2] sc:3501 lt:0 rt:0 fl:0
- [3] sc:3497 lt:0 rt:0 fl:0
- [4] sc:3501 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.47% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.34% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 100.00% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 11671.667 TpmC
- iostat 统计信息
- avg-cpu: %user %nice %system %iowait %steal %idle
17.86 0.00 5.91 9.87 0.02 66.34
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.00 0.00 0.12 0.00 1.00 8.00 0.00 3.00 0.00 3.00 3.00 0.04
vdb 0.00 19211.00 0.00 6432.75 0.00 202909.00 31.54 11.59 1.80 0.00 1.80 0.15 95.75
四、更改几个核心参数,可以看到tps大幅度提高到1217(75035/60).
点击(此处)折叠或打开
- 测试2:增加参数,tps大幅增加,是有原因的,增大了内存
- innodb_buffer_pool_size = 22938M
innodb_buffer_pool_instances = 8
skip-name-resolve
transaction_isolation=READ-COMMITTED - innodb_log_file_size = 512M
innodb_log_buffer_size = 128M
innodb_log_files_in_group=5
innodb_temp_data_file_path=ibtmp1:512M:autoextend - [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '10'
- option c with value '64'
- option r with value '60'
- option l with value '180'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 10
- [connection]: 64
- [rampup]: 60 (sec.)
- [measure]: 180 (sec.)
-
- RAMP-UP TIME.(60 sec.)
-
- MEASURING START.
-
- <Raw Results>
- [0] sc:219107 lt:0 rt:0 fl:0
- [1] sc:219072 lt:0 rt:0 fl:0
- [2] sc:21909 lt:0 rt:0 fl:0
- [3] sc:21908 lt:0 rt:0 fl:0
- [4] sc:21912 lt:0 rt:0 fl:0
- in 180 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:219108 lt:0 rt:0 fl:0
- [1] sc:219108 lt:0 rt:0 fl:0
- [2] sc:21909 lt:0 rt:0 fl:0
- [3] sc:21911 lt:0 rt:0 fl:0
- [4] sc:21912 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.47% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.35% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 100.00% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 73035.664 TpmC
iostat 统计数据
avg-cpu: %user %nice %system %iowait %steal %idle
74.08 0.00 11.53 1.19 0.01 13.19
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.75 0.00 0.50 0.00 5.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 5584.00 0.00 1509.38 0.00 28306.00 37.51 1.43 0.95 0.00 0.95 0.49 73.60
avg-cpu: %user %nice %system %iowait %steal %idle
74.08 0.00 11.53 1.19 0.01 13.19
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.75 0.00 0.50 0.00 5.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 5584.00 0.00 1509.38 0.00 28306.00 37.51 1.43 0.95 0.00 0.95 0.49 73.60
- 测试3:增加参数,主要增加innodb_io_capacity,按照理论,tps应该增加的,但是反而下降10000,具体查看下,看看是有没有锁。
- innodb_io_capacity = 10000
innodb_io_capacity_max = 20000
innodb_flush_neighbors = 0
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_purge_threads = 4
innodb_page_cleaners = 4
innodb_open_files = 65535
innodb_max_dirty_pages_pct = 50
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '10'
- option c with value '64'
- option r with value '60'
- option l with value '180'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 10
- [connection]: 64
- [rampup]: 60 (sec.)
- [measure]: 180 (sec.)
-
- RAMP-UP TIME.(60 sec.)
-
- MEASURING START.
-
- <Raw Results>
- [0] sc:201891 lt:0 rt:0 fl:0
- [1] sc:201850 lt:0 rt:0 fl:0
- [2] sc:20190 lt:0 rt:0 fl:0
- [3] sc:20187 lt:0 rt:0 fl:0
- [4] sc:20186 lt:0 rt:0 fl:0
- in 180 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:201895 lt:0 rt:0 fl:0
- [1] sc:201884 lt:0 rt:0 fl:0
- [2] sc:20190 lt:0 rt:0 fl:0
- [3] sc:20189 lt:0 rt:0 fl:0
- [4] sc:20187 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.47% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.35% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 100.00% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 67297.000 TpmC
iostat 的统计信息
avg-cpu: %user %nice %system %iowait %steal %idle
70.27 0.00 11.00 1.60 0.01 17.12
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 1.33 0.00 2.00 0.00 13.33 13.33 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 8142.89 0.00 2545.33 0.00 42552.89 33.44 5.40 2.12 0.00 2.12 0.31 77.98
avg-cpu: %user %nice %system %iowait %steal %idle
70.27 0.00 11.00 1.60 0.01 17.12
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 1.33 0.00 2.00 0.00 13.33 13.33 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 8142.89 0.00 2545.33 0.00 42552.89 33.44 5.40 2.12 0.00 2.12 0.31 77.98
这次tps下降了。所以我们要恢复原来的参数。把这些参数清除继续下面的测试
六、增加并发连接到128个
- 测试4.参数不调整,但是增加并发连接到128个。看tps77476,没有很大的提高,并发可以撑得住。对系统影响较小
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c128 -r60 -l180 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '10'
- option c with value '128'
- option r with value '60'
- option l with value '180'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 10
- [connection]: 128
- [rampup]: 60 (sec.)
- [measure]: 180 (sec.)
- RAMP-UP TIME.(60 sec.)
- MEASURING START.
-
- STOPPING THREADS................................................................................................................................
- <Raw Results>
- [0] sc:232429 lt:0 rt:0 fl:0
- [1] sc:232379 lt:0 rt:0 fl:0
- [2] sc:23247 lt:0 rt:0 fl:0
- [3] sc:23246 lt:0 rt:0 fl:0
- [4] sc:23246 lt:0 rt:0 fl:0
- in 180 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:232430 lt:0 rt:0 fl:0
- [1] sc:232417 lt:0 rt:0 fl:0
- [2] sc:23247 lt:0 rt:0 fl:0
- [3] sc:23246 lt:0 rt:0 fl:0
- [4] sc:23246 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.47% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.35% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 100.00% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 77476.336 TpmC
- iostat 统计信息
- avg-cpu: %user %nice %system %iowait %steal %idle
78.48 0.00 11.64 0.77 0.00 9.11
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 6027.25 0.00 1488.25 0.00 59964.00 40.29 1.41 0.95 0.00 0.95 0.45 67.21
七、开启二进制日志功能,以及刷盘方式,对tps影响都是巨大的。这个结论也可以理解,不停的写二进制日志。假如整个数据库只用innodb一种引擎,又写二进制日志,又写innodb日志,不是重复吗?但是在线日志对数据库的性能影响是绝对巨头的,甚至可以认为是决定性的。
点击(此处)折叠或打开
- 测试5:增加参数,表示开启二进制日志功能,tps性能大幅下跌到17523,我查看binlog日志,有个1.1Gbinlog.000001,还有一个276M的binlog.0000002日志文件。所有的性能损耗在写二进制日志文件上。测试6:如果sync_binlog变为0,我的tps测试结果为44691.332 TpmC 。所以说不控制的话,tps应该有提高,提高效果还是很明显的哦。
- server_id=1
- binlog_format=row
- log_bin = binlog
- sync_binlog=1
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '10'
- option c with value '64'
- option r with value '60'
- option l with value '180'
- option f with value 'tpcc_mysql_20180102.log'
-
- <Raw Results>
- [0] sc:52564 lt:5 rt:0 fl:0
- [1] sc:52560 lt:0 rt:0 fl:0
- [2] sc:5257 lt:0 rt:0 fl:0
- [3] sc:5257 lt:0 rt:0 fl:0
- [4] sc:5258 lt:0 rt:0 fl:0
- in 180 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:52565 lt:5 rt:0 fl:0
- [1] sc:52571 lt:0 rt:0 fl:0
- [2] sc:5258 lt:0 rt:0 fl:0
- [3] sc:5257 lt:0 rt:0 fl:0
- [4] sc:5258 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.47% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.35% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 99.99% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 17523.000 TpmC
现在数据库tpcc1000有 9张表,warehouse10条记录,stock表有500万,item表有10万,order_line1499万,new_orders45万,orders150万, customer150万,查看一下实际表空间的大小3.9G:
- [root@mysql3 ~]# ll /data/mysql1/tpcc1000/ -hS
- total 3.9G
- -rw-r----- 1 mysql mysql 1.7G Jan 10 11:13 stock.ibd
- -rw-r----- 1 mysql mysql 1.1G Jan 10 11:40 order_line.ibd
- -rw-r----- 1 mysql mysql 920M Jan 10 11:22 customer.ibd
- -rw-r----- 1 mysql mysql 108M Jan 10 11:22 history.ibd
- -rw-r----- 1 mysql mysql 68M Jan 10 11:40 orders.ibd
- -rw-r----- 1 mysql mysql 20M Jan 10 11:40 new_orders.ibd
- -rw-r----- 1 mysql mysql 17M Jan 10 11:03 item.ibd
- -rw-r----- 1 mysql mysql 144K Jan 10 11:13 district.ibd
- -rw-r----- 1 mysql mysql 96K Jan 10 11:11 warehouse.ibd
- -rw-r----- 1 mysql mysql 9.2K Jan 10 11:01 customer.frm
- -rw-r----- 1 mysql mysql 9.0K Jan 10 11:01 stock.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 10 11:01 order_line.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 10 11:01 district.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 warehouse.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 orders.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 history.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 10 11:01 item.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 10 11:01 new_orders.frm
- -rw-r----- 1 mysql mysql 67 Jan 8 16:28 db.opt
innodb_buffer_pool_size = 22938M
innodb_buffer_pool_instances = 8
skip-name-resolve
transaction_isolation=READ-COMMITTED
innodb_log_file_size = 512M
innodb_log_buffer_size = 128M
innodb_log_files_in_group=5
innodb_temp_data_file_path=ibtmp1:512M:autoextend
#autocommit=0
server_id=1
binlog_format=row
log_bin = binlog
sync_binlog=0
- 测试7.增加warehouse到50个
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w50 -c128 -r30 -l90 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '50'
- option c with value '128'
- option r with value '30'
- option l with value '90'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 50
- [connection]: 128
- [rampup]: 30 (sec.)
- [measure]: 90 (sec.)
-
- RAMP-UP TIME.(30 sec.)
-
-
- <Raw Results>
- [0] sc:83245 lt:2 rt:0 fl:0
- [1] sc:83233 lt:3 rt:0 fl:0
- [2] sc:8324 lt:0 rt:0 fl:0
- [3] sc:8322 lt:0 rt:0 fl:0
- [4] sc:8323 lt:0 rt:0 fl:0
- in 90 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:83245 lt:2 rt:0 fl:0
- [1] sc:83250 lt:3 rt:0 fl:0
- [2] sc:8324 lt:0 rt:0 fl:0
- [3] sc:8322 lt:0 rt:0 fl:0
- [4] sc:8323 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 43.48% (>=43.0%) [OK]
- Order-Status: 4.35% (>= 4.0%) [OK]
- Delivery: 4.35% (>= 4.0%) [OK]
- Stock-Level: 4.35% (>= 4.0%) [OK]
- [response time (at least 90% passed)]
- New-Order: 100.00% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 55498.000 TpmC
- iostat 统计
- avg-cpu: %user %nice %system %iowait %steal %idle
70.65 0.00 10.26 2.04 0.01 17.04
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vdb 0.00 11602.88 27.00 1049.25 1300.00 100851.00 94.91 2.44 2.30 5.16 2.22 0.60 64.59
把数据量增加到50个warehouse.这个时候,数据量是这样的:
现在数据库tpcc1000有 9张表,warehouse10条记录,stock表有5000万,item表有10万,order_line1.49亿,new_orders450万,orders1500万, customer1500万,查看一下实际表空间的大小38G:
- [root@mysql3 ~]# ll /data/mysql1/tpcc1000/ -hS
- total 38G
- -rw-r----- 1 mysql mysql 17G Jan 10 16:11 stock.ibd
- -rw-r----- 1 mysql mysql 11G Jan 10 19:27 order_line.ibd
- -rw-r----- 1 mysql mysql 8.9G Jan 10 16:52 customer.ibd
- -rw-r----- 1 mysql mysql 988M Jan 10 16:52 history.ibd
- -rw-r----- 1 mysql mysql 608M Jan 10 19:27 orders.ibd
- -rw-r----- 1 mysql mysql 128M Jan 10 19:27 new_orders.ibd
- -rw-r----- 1 mysql mysql 17M Jan 10 15:03 item.ibd
- -rw-r----- 1 mysql mysql 9.0M Jan 10 16:11 district.ibd
- -rw-r----- 1 mysql mysql 144K Jan 10 16:10 warehouse.ibd
- -rw-r----- 1 mysql mysql 9.2K Jan 10 15:02 customer.frm
- -rw-r----- 1 mysql mysql 9.0K Jan 10 15:02 stock.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 10 15:02 order_line.frm
- -rw-r----- 1 mysql mysql 8.8K Jan 10 15:02 district.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 warehouse.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 orders.frm
- -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 history.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 10 15:02 item.frm
- -rw-r----- 1 mysql mysql 8.5K Jan 10 15:02 new_orders.frm
- -rw-r----- 1 mysql mysql 67 Jan 8 16:28 db.opt
1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382)
1040, 08004, Too many connections
这个问题比较好解决,更改两个参数不报错了。set global max_prepared_stmt_count=1048576;
压力测试结果出来了,是5700TpmC.明显,这个结果是非常低的。问题出在哪里呢?
这个比较有意思。你对比iostat,和以前测试相比,r/s由0变成了2605,w/s由1488变成了615,avgqu-sz变成了48,等待队列很多
%util变成了99.99,io是满负荷的。这说明什么呢?写变少了,读大量增加。为什么呢?因为数据量变大了,查询耗时了。
现在要解决的问题是,优化查询语句后再进行压力测试。
十二、我开启了mysql的慢查询,分析哪些语句执行慢。摘录部分查询结果如下:
我们看到,这里面慢查询都是发生在表orders,有执行7秒的,有执行4秒的,3秒的,有insert语句。我把这些语句单独拿到
mysql中执行,执行非常快。打印出执行计划,我看到了所有的语句都走了索引,而且每个语句执行速度很快。这个会是什么原因呢?我猜测是并发线程多,有锁住情况。但是mysql的查询是非阻塞的,插入也是非阻塞的,这又是什么原因呢?先做个验证:使用256个并发线程连接,看看有什么表现。
十三、我先后做如下压测,后面附上tps: 当库存数量达到450的时候,性能急剧下降,不清楚mysql哪个指标受限制了。
最后点评:
- 测试8 数据量有38G,很大
- [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w500 -c512 -r10 -l10 -ftpcc_mysql_20180102.log
- ***************************************
- *** ###easy### TPC-C Load Generator ***
- ***************************************
- option h with value 'localhost'
- option d with value 'tpcc1000'
- option u with value 'tpcc_user'
- option p with value 'tpcc_password'
- option w with value '500'
- option c with value '512'
- option r with value '10'
- option l with value '10'
- option f with value 'tpcc_mysql_20180102.log'
- <Parameters>
- [server]: localhost
- [port]: 3306
- [DBname]: tpcc1000
- [user]: tpcc_user
- [pass]: tpcc_password
- [warehouse]: 500
- [connection]: 512
- [rampup]: 10 (sec.)
- [measure]: 10 (sec.)
-
- RAMP-UP TIME.(10 sec.)
-
- <Raw Results>
- [0] sc:949 lt:1 rt:0 fl:0
- [1] sc:865 lt:0 rt:0 fl:0
- [2] sc:85 lt:0 rt:0 fl:0
- [3] sc:67 lt:0 rt:0 fl:0
- [4] sc:57 lt:0 rt:0 fl:0
- in 10 sec.
-
- <Raw Results2(sum ver.)>
- [0] sc:949 lt:1 rt:0 fl:0
- [1] sc:865 lt:0 rt:0 fl:0
- [2] sc:85 lt:0 rt:0 fl:0
- [3] sc:67 lt:0 rt:0 fl:0
- [4] sc:57 lt:0 rt:0 fl:0
-
- <Constraint Check> (all must be [OK])
- [transaction percentage]
- Payment: 42.74% (>=43.0%) [NG] *
- Order-Status: 4.20% (>= 4.0%) [OK]
- Delivery: 3.31% (>= 4.0%) [NG] *
- Stock-Level: 2.82% (>= 4.0%) [NG] *
- [response time (at least 90% passed)]
- New-Order: 99.89% [OK]
- Payment: 100.00% [OK]
- Order-Status: 100.00% [OK]
- Delivery: 100.00% [OK]
- Stock-Level: 100.00% [OK]
-
- <TpmC>
- 5700.000 TpmC
- iostat 统计信息:
- avg-cpu: %user %nice %system %iowait %steal %idle
14.18 0.00 4.84 63.26 0.01 17.71
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 0.38 0.12 0.88 2.00 10.00 12.00 0.00 0.12 0.00 0.14 0.12 0.01
vdb 1.25 10116.38 2605.50 615.88 204808.00 86800.00 90.52 48.55 14.97 15.37 13.28 0.31 99.99
这个比较有意思。你对比iostat,和以前测试相比,r/s由0变成了2605,w/s由1488变成了615,avgqu-sz变成了48,等待队列很多
%util变成了99.99,io是满负荷的。这说明什么呢?写变少了,读大量增加。为什么呢?因为数据量变大了,查询耗时了。
现在要解决的问题是,优化查询语句后再进行压力测试。
%util变成了99.99,io是满负荷的。这说明什么呢?写变少了,读大量增加。为什么呢?因为数据量变大了,查询耗时了。
现在要解决的问题是,优化查询语句后再进行压力测试。
十二、我开启了mysql的慢查询,分析哪些语句执行慢。摘录部分查询结果如下:
- # Query_time: 4.743248 Lock_time: 0.000053 Rows_sent: 0 Rows_examined: 0
- SET timestamp=1515661062;
- INSERT INTO orders (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES(3002, 4, 138, 2870, '2018-01-11 16:57:37', 7, 1);
-
- # Query_time: 3.139345 Lock_time: 0.000102 Rows_sent: 1 Rows_examined: 3001
- SET timestamp=1515661062;
- SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 345 AND o_d_id = 8 AND o_c_id = 1069 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 345 AND o_d_id = 8 AND o_c_id = 1069);
-
- # Query_time: 4.433704 Lock_time: 0.000241 Rows_sent: 1 Rows_examined: 3002
- SET timestamp=1515661062;
- SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 408 AND o_d_id = 7 AND o_c_id = 760 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 408 AND o_d_id = 7 AND o_c_id = 760);
-
- # Query_time: 7.391263 Lock_time: 0.000151 Rows_sent: 1 Rows_examined: 3003
- SET timestamp=1515661062;
- SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 253 AND o_d_id = 4 AND o_c_id = 1272 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 253 AND o_d_id = 4 AND o_c_id = 1272)
我们看到,这里面慢查询都是发生在表orders,有执行7秒的,有执行4秒的,3秒的,有insert语句。我把这些语句单独拿到
mysql中执行,执行非常快。打印出执行计划,我看到了所有的语句都走了索引,而且每个语句执行速度很快。这个会是什么原因呢?我猜测是并发线程多,有锁住情况。但是mysql的查询是非阻塞的,插入也是非阻塞的,这又是什么原因呢?先做个验证:使用256个并发线程连接,看看有什么表现。
mysql中执行,执行非常快。打印出执行计划,我看到了所有的语句都走了索引,而且每个语句执行速度很快。这个会是什么原因呢?我猜测是并发线程多,有锁住情况。但是mysql的查询是非阻塞的,插入也是非阻塞的,这又是什么原因呢?先做个验证:使用256个并发线程连接,看看有什么表现。
mysql中执行,执行非常快。打印出执行计划,我看到了所有的语句都走了索引,而且每个语句执行速度很快。这个会是什么原因呢?我猜测是并发线程多,有锁住情况。但是mysql的查询是非阻塞的,插入也是非阻塞的,这又是什么原因呢?先做个验证:使用256个并发线程连接,看看有什么表现。
十三、我先后做如下压测,后面附上tps: 当库存数量达到450的时候,性能急剧下降,不清楚mysql哪个指标受限制了。
-
- 测试9 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w100 -c64 -r10 -l30 -ftpcc_mysql_20180104.log
- 33200.000 TpmC
-
- 测试10 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w100 -c256 -r10 -l30 -ftpcc_mysql_20180104.log
- 32594.000 TpmC
-
- 测试11 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w250 -c256 -r10 -l30 -ftpcc_mysql_20180104.log
- 30148.000 TpmC
- 测试12 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w450 -c256 -r10 -l30 -ftpcc_mysql_20180104.log
- 17996.000 TpmC
当库存数量达到450的时候,性能急剧下降,不清楚mysql哪个指标受限制了。
最后点评:
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30393770/viewspace-2149755/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30393770/viewspace-2149755/