如何把mysqld压测到崩溃重启
小编给大家分享一下如何把mysqld压测到崩溃重启,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!
一、压测环境工具准备:
centos7.5
sysbench2.0.9
mysql5.7.22
机器配置:宿主机是vmware esxi
DELL R730
硬盘:普通10K SAS
内存:18G
CPU:8核
非常普通的cpu:
[root@yw-gz-hd-test-211 log]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 8
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz
Stepping: 1
CPU MHz: 2399.361
BogoMIPS: 4799.99
Hypervisor vendor: VMware
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 25600K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
编译安装好mysql,设置 innodb_buffer_pool_size=5G innodb_buffer_pool_instance=5. 其他参数更改redo 为4组,io thread 为8 等等一些参数。
二、开始准备压测数据库:
插入10张表,每个表数据1000万,整个msyql库25G。
[root@yw-gz-hd-test-211 ~]# ls /data/mysql3308/sbtest/ -lh
total 25G
-rw-r----- 1 mysql mysql 61 Jul 17 19:24 db.opt
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest10.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest1.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest2.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest3.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest4.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest5.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest6.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest7.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest8.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jul 17 19:32 sbtest9.frm
-rw-r----- 1 mysql mysql 2.5G Jul 18 14:58 sbtest9.ibd
[root@yw-gz-hd-test-211 ~]# ls /data/mysql3308/ -lh
total 1.4G
-rw-r----- 1 mysql mysql 56 Jul 17 17:56 auto.cnf
-rw-r----- 1 mysql mysql 1.5K Jul 18 14:17 ib_buffer_pool
-rw-r----- 1 mysql mysql 384M Jul 18 15:13 ibdata1
-rw-r----- 1 mysql mysql 256M Jul 18 15:13 ib_logfile0
-rw-r----- 1 mysql mysql 256M Jul 18 14:50 ib_logfile1
-rw-r----- 1 mysql mysql 256M Jul 18 15:13 ib_logfile2
-rw-r----- 1 mysql mysql 256M Jul 18 14:49 ib_logfile3
-rw-r----- 1 mysql mysql 12M Jul 18 15:21 ibtmp1
drwxr-x--- 2 mysql mysql 4.0K Jul 17 17:56 mysql
srwxrwxrwx 1 mysql mysql 0 Jul 18 14:42 mysql.sock
-rw------- 1 mysql mysql 6 Jul 18 14:42 mysql.sock.lock
drwxr-x--- 2 mysql mysql 8.0K Jul 17 17:56 performance_schema
drwxr-x--- 2 mysql mysql 4.0K Jul 17 19:36 sbtest
drwxr-x--- 2 mysql mysql 8.0K Jul 17 17:56 sys
-rw-r----- 1 mysql mysql 6 Jul 18 14:42 yw-gz-hd-test-211.pid
三、开始压测:
首先300个线程,开始上。你会发现,立马报错:
FATAL: mysql_stmt_prepare() failed
FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 100000)"
百度一下,设置一下参数可以解决:max_prepared_stmt_count=150000
四、高潮出现:
错误排除,压测到线程300个,总共时长是240秒,等到压测到120秒的时候,mysql进程突然奔溃。错误日志中没有记录mysql奔溃的原因,只记录到mysql崩溃后,被mysqld_safe 进程监控,然后立即拉起mysqld 进程。mysqld_safe 进程会一直监控mysqld进程,发现死掉,立即拉起mysqld进程。我怀疑是内存不够。但是没有证据证明:是内存不够导致的mysqld进程奔溃。这个时候,我发现top命令还是很好用的。怎么用呢?让我娓娓道来。前面不是讲到了,压测刚开始的120秒,没有问题,你可以在这个压测0~120秒的时候,打开top,你观察mysqld线程使用内存情况。你观察RES这一列,你会发现,mysqld进程RES值,从500M一直增长,增长到5G的时候,duang~,崩溃了。看出来了吧,mysql也有承受不住的时候。
为了验证自己是猜想,很简单,不要更改任何参数,增加机器内存到18G。再一次压测,验证了我的想法,mysqld进程再300个并发线程中使用掉了6G内存。
来看下300个并发压测情况
[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=localhost --mysql-socket=/data/mysql3308/mysql.sock --mysql-port=3308 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=10000000 --tables=10 --threads=300 --time=240 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 300
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 300 tps: 189.42 qps: 3911.05 (r/w/o: 2753.06/769.16/388.83) lat (ms,95%): 3151.62 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 300 tps: 406.65 qps: 8146.63 (r/w/o: 5702.77/1630.57/813.30) lat (ms,95%): 1903.57 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 300 tps: 1027.51 qps: 20561.94 (r/w/o: 14391.74/4115.19/2055.01) lat (ms,95%): 909.80 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 300 tps: 915.33 qps: 18308.17 (r/w/o: 12818.23/3659.27/1830.67) lat (ms,95%): 802.05 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 300 tps: 848.33 qps: 16954.26 (r/w/o: 11865.99/3391.60/1696.67) lat (ms,95%): 787.74 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 300 tps: 1015.47 qps: 20327.15 (r/w/o: 14231.78/4064.44/2030.93) lat (ms,95%): 682.06 err/s: 0.00 reconn/s: 0.00
[ 210s ] thds: 300 tps: 1293.73 qps: 25882.66 (r/w/o: 18120.80/5174.40/2587.47) lat (ms,95%): 493.24 err/s: 0.00 reconn/s: 0.00
[ 240s ] thds: 300 tps: 1705.07 qps: 33979.32 (r/w/o: 23772.88/6803.07/3403.37) lat (ms,95%): 419.45 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 3110016
write: 888576
other: 444288
total: 4442880
transactions: 222144 (924.53 per sec.)
queries: 4442880 (18490.54 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 240.2250s
total number of events: 222144
Latency (ms):
min: 2.52
avg: 324.16
max: 50333.39
95th percentile: 1050.76
sum: 72010070.69
Threads fairness:
events (avg/stddev): 740.4800/78.20
execution time (avg/stddev): 240.0336/0.06
成绩还不错,QPS:18490,TPS:924。95%的响应时间是1050ms,就是1秒,可以接受
来看看600并发连接线程情况
[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=localhost --mysql-socket=/data/mysql3308/mysql.sock --mysql-port=3308 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=10000000 --tables=10 --threads=600 --time=240 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 600
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 600 tps: 177.45 qps: 3866.55 (r/w/o: 2740.46/751.20/374.88) lat (ms,95%): 6594.16 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 600 tps: 508.61 qps: 10190.12 (r/w/o: 7130.15/2042.76/1017.21) lat (ms,95%): 2828.87 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 600 tps: 833.10 qps: 16581.88 (r/w/o: 11603.42/3312.26/1666.20) lat (ms,95%): 1506.29 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 600 tps: 712.40 qps: 14275.18 (r/w/o: 9994.28/2856.20/1424.70) lat (ms,95%): 1589.90 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 600 tps: 828.53 qps: 16595.37 (r/w/o: 11637.94/3300.27/1657.17) lat (ms,95%): 1280.93 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 600 tps: 1152.15 qps: 23046.54 (r/w/o: 16115.87/4626.50/2304.17) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 210s ] thds: 600 tps: 1422.39 qps: 28470.31 (r/w/o: 19918.05/5707.53/2844.74) lat (ms,95%): 707.07 err/s: 0.00 reconn/s: 0.00
[ 240s ] thds: 600 tps: 1874.42 qps: 37511.54 (r/w/o: 26257.48/7505.04/3749.01) lat (ms,95%): 601.29 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 3161774
write: 903364
other: 451682
total: 4516820
transactions: 225841 (939.46 per sec.)
queries: 4516820 (18789.23 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 240.3923s
total number of events: 225841
Latency (ms):
min: 2.75
avg: 637.78
max: 44200.42
95th percentile: 1678.14
sum: 144036928.60
Threads fairness:
events (avg/stddev): 376.4017/48.51
execution time (avg/stddev): 240.0615/0.03
这个时候我们看到大量的慢查询语句,95%响应时间是1678ms,就是1.6秒,有些慢了。看看慢查询都是些什么语句:
# Time: 2018-07-18T14:22:07.662597+08:00
# User@Host: root[root] @ localhost [] Id: 592
# Query_time: 7.400737 Lock_time: 0.000028 Rows_sent: 0 Rows_examined: 1
SET timestamp=1531894927;
UPDATE sbtest5 SET k=k+1 WHERE id=5024619;
# Time: 2018-07-18T14:22:07.662786+08:00
# User@Host: root[root] @ localhost [] Id: 202
# Query_time: 4.220504 Lock_time: 0.000027 Rows_sent: 0 Rows_examined: 1
SET timestamp=1531894927;
UPDATE sbtest5 SET k=k+1 WHERE id=5024572;
# Time: 2018-07-18T14:22:07.662829+08:00
# User@Host: root[root] @ localhost [] Id: 544
# Query_time: 3.662601 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 1
SET timestamp=1531894927;
DELETE FROM sbtest5 WHERE id=5024577;
# Time: 2018-07-18T14:22:07.662634+08:00
# User@Host: root[root] @ localhost [] Id: 402
# Query_time: 4.832428 Lock_time: 0.000023 Rows_sent: 0 Rows_examined: 1
SET timestamp=1531894927;
UPDATE sbtest5 SET c='53575816661-90198037463-61731021712-17992612508-02527517402-89815419518-53211578757-17129425245-97225103738-94879199437' WHERE id=5024586;
都是更新语句。这些语句非常耗费IO的
再来看看900个并发线程的情况。
[root@yw-gz-hd-test-211 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host=localhost --mysql-socket=/data/mysql3308/mysql.sock --mysql-port=3308 --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --table_size=10000000 --tables=10 --threads=900 --time=240 --report-interval=30 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 900
Report intermediate results every 30 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 30s ] thds: 900 tps: 347.86 qps: 7432.37 (r/w/o: 5273.60/1433.11/725.65) lat (ms,95%): 5124.81 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 900 tps: 561.28 qps: 11176.43 (r/w/o: 7801.59/2252.28/1122.55) lat (ms,95%): 10158.80 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 900 tps: 643.33 qps: 12944.09 (r/w/o: 9077.29/2580.13/1286.67) lat (ms,95%): 2932.60 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 900 tps: 360.53 qps: 7200.07 (r/w/o: 5039.67/1439.33/721.07) lat (ms,95%): 6135.91 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 900 tps: 728.53 qps: 14524.71 (r/w/o: 10134.68/2933.03/1457.00) lat (ms,95%): 2585.31 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 900 tps: 1268.27 qps: 25410.63 (r/w/o: 17798.37/5075.80/2536.47) lat (ms,95%): 1561.52 err/s: 0.00 reconn/s: 0.00
[ 210s ] thds: 900 tps: 1676.04 qps: 33561.08 (r/w/o: 23477.06/6731.82/3352.21) lat (ms,95%): 1869.60 err/s: 0.00 reconn/s: 0.00
[ 240s ] thds: 900 tps: 2290.01 qps: 45719.85 (r/w/o: 31996.75/9148.79/4574.31) lat (ms,95%): 1352.03 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 3318098
write: 948028
other: 474014
total: 4740140
transactions: 237007 (985.74 per sec.)
queries: 4740140 (19714.74 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 240.4346s
total number of events: 237007
Latency (ms):
min: 2.76
avg: 911.43
max: 31437.18
95th percentile: 2778.39
sum: 216015485.39
Threads fairness:
events (avg/stddev): 263.3411/37.88
execution time (avg/stddev): 240.0172/0.02
看到了,95%响应时间是2.7秒,数据库mysql响应时间越来越慢,越来越不堪重负。崩溃就在一瞬间。如我所见,innodb_buffer_pool_size=18G时候,1000个并发线程导致mysqld崩溃了。终于承受不住。
我们来大概测算一下,100个并发需要多大的内存:
并发数 | innodb_buffer_pool_size | mysqld是否崩溃 |
200 | 5G | 否 |
300 | 5G | 崩溃 |
600 | 18G | 否 |
900 | 18G | 否 |
1000 | 18G | 崩溃 |
看来100并发线程,mysqld至少需要2G内存,另外考虑留给操作系统占用2G内存。所以一个4核8G机器,线程数不要设置超过250个。这个既是保护数据库不崩溃,保证响应时间在合理范围之内(1秒),又是,当连接达到上限的时候,程序有报错,提示DBA需要增加机器的内存。
看完了这篇文章,相信你对“如何把mysqld压测到崩溃重启”有了一定的了解,如果想了解更多相关知识,欢迎关注亿速云行业资讯频道,感谢各位的阅读!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341