专栏首页杨建荣的学习笔记使用sysbench压力测试MySQL(三)(r12笔记第6天)

使用sysbench压力测试MySQL(三)(r12笔记第6天)

昨天使用gdb调试MySQL中事务临界状态的时候,发现其实有些场景可能比我想得还要复杂一些,所以我在昨天的测试中结尾也是快快扫过,但是表明了意思即可。这一点上我在后面会把Oracle的临界事务状态也拿出来对比一下,还是蛮有意思的。

今天简单写了几个脚本继续对一个测试环境的MySQL进行sysbench压力测试。

先突破1000连接资源设置的瓶颈

在上一次的基础上,我们保证了能够满足短时间内1000个连接的冲击,从各个方面做了调整,其中的一个重点逐渐落到了IO的吞吐率上,redo日志的大小设置一下子成了焦点和重中之重。

当然这次的测试中,我的思路还是保持性能持续的增长,边调整,边优化。

首先一点是我们能够突破1000连接的大关,先用下面的脚本来进行一个初步的测试,测试时长10秒钟,看看能否初始化1500个连接。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3306 --mysql-socket=/home/mysql/s1/s1.sock --mysql-host=localhost --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=1500 --report-interval=5 --time=10 run

没想到就跟约好似的,抛出了如下的错误。注意这里的错误看起来已经不是数据库层面了。

FATAL: unable to connect to MySQL server on socket '/home/mysql/s1/s1.sock', aborting... FATAL: error 2001: Can't create UNIX socket (24) PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files) PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files)

是不是支持的socket数的限制呢,我们已经调整了process的值。上面的命令我们可以换个姿势来写,那就是从socket连接改为常用的TCP/IP方式的连接.

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=perf_test --mysql-port=3306 --mysql-host=10.127.128.78 --mysql-password=perf_test --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=1500 --report-interval=5 --time=10 run

可以看到错误就显示不同了,但是已经能够看出意思来了。

FATAL: unable to connect to MySQL server on host '10.127.128.78', port 3306, aborting... FATAL: error 2004: Can't create TCP/IP socket (24) PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files) PANIC: unprotected error in call to Lua API (cannot open /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua: Too many open files)

对此应很明确了,那就是内核资源设置nofile调整一下。

修改/etc/security/limits.d/90-nproc.conf文件,添加如下的部分即可,重新登录后即可生效。

* soft nproc 65535 * soft nofile 65535 * hard nofile 65535

重启MySQL后可以看到设置生效了。# cat /proc/`pidof mysqld`/limits | egrep "(processes|files)" Max processes 65535 256589 processes Max open files 65535 65535 files

调整prepare

我们继续开启压测模式,马上错误就变了样。是我们熟悉的一个错误,最开始就碰到了。

FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:273: SQL API error (last message repeated 1 times) FATAL: mysql_stmt_prepare() failed FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 100000)" FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:273: SQL API error

这里得简单说说几个相关的额参数。

Com_stmt_close prepare语句关闭的次数 Com_stmt_execute prepare语句执行的次数 Com_stmt_prepare prepare语句创建的次数

这一类的场景可能不是通用的,因为在有些场景下,持续的连接,不是短时间内的大批量连接,这个参数max_prepared_stmt_count其实也不一定需要设置非常大。

比如我手头一个环境连接数有近500,但是max_prepared_stmt_count还是默认值16382,也稳定运行了很长时间了。# mysqladmin pro|wc -l 424 # mysqladmin var|grep max_prepared_stmt_count | max_prepared_stmt_count | 16382 我们的这个压测场景中,会短时间内创建大量的连接,而考虑到性能和安全,会使用prepare的方式,我们以10秒内的sysbench连接测试威力,看看prepare statement的数量变化。

使用show global status like '%stmt%'能够得到一个基本的数据变化。

mysql> show global status like '%stmt%'; +----------------------------+--------+ | Variable_name | Value | +----------------------------+--------+ | Com_stmt_execute | 477403 | | Com_stmt_close | 91000 | | Com_stmt_fetch | 0 | | Com_stmt_prepare | 298844 | | Com_stmt_reset | 0 | | Com_stmt_send_long_data | 0 | | Com_stmt_reprepare | 0 | | Prepared_stmt_count | 0 | +----------------------------+--------+

过几秒查看,可以看到Prepared_stmt_count已经接近阈值。

mysql> show global status like '%stmt%'; +----------------------------+--------+ | Variable_name | Value | +----------------------------+--------+ | Binlog_stmt_cache_disk_use | 0 | | Binlog_stmt_cache_use | 0 | | Com_stmt_execute | 477403 | | Com_stmt_close | 91000 | | Com_stmt_fetch | 0 | | Com_stmt_prepare | 398045 | | Com_stmt_reset | 0 | | Com_stmt_send_long_data | 0 | | Com_stmt_reprepare | 0 | | Prepared_stmt_count | 98091 | +----------------------------+--------+ 按照目前的一个基本情况,我们需要 设置为91*1500=136500,留有一定的富余,所以我们可以设置为150000

然后继续测试,就会看到这个参数逐步的飞升。

mysql> show global status like '%stmt%'; +----------------------------+--------+ | Variable_name | Value | +----------------------------+--------+ | Binlog_stmt_cache_disk_use | 0 | | Binlog_stmt_cache_use | 0 | | Com_stmt_execute | 624184 | | Com_stmt_close | 91000 | | Com_stmt_fetch | 0 | | Com_stmt_prepare | 537982 | | Com_stmt_reset | 0 | | Com_stmt_send_long_data | 0 | | Com_stmt_reprepare | 0 | | Prepared_stmt_count | 136500 | +----------------------------+--------+

整个加压的过程中,可以通过top看到负载还是有一定的潜力,离性能榨干还有距离。

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13417 mysql 20 0 34.8g 11g 12m S 1324.2 35.2 19:18.71 /usr/local/mysql/bin/mysqld --defaults-file=/home 23108 root 20 0 8924m 1.6g 2148 S 212.3 5.0 1:32.73 sysbench /home/sysbench/sysbench-1.0.3/src/lua/olt

下面的图是我使用100M,200M,500,1G的redo得到的TPS图。

通过这个图也能过看出一个基本的负载情况,在1G的时候,TPS相对比较平稳,但是redo切换还是多多少少都会有一定的抖动。当然redo不是越大越好,

5.5 中的设置是小于 4G, 5.6 以后是小于512G

我们持续进行优化。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:杨建荣

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-03-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • MySQL压力测试中定制sysbench的Lua模板

    对于sysbench的定制,自己给自己定了一个小目标,但是实践的时候发现,难度比想象的要大很多。 都说Lua很简单,性能很不错,但是定制sysb...

    jeanron100
  • MySQL慢日志优化平台初步设计

    这是一个初步的概览面板,能够通过这个面板实现大部分的慢日志提取需求,目的是能够通过可视化的方式更全面的展示慢日志的信息,如下:

    jeanron100
  • 通过闪回事务查看数据dml的情况 (r2笔记69天)

    昨天有一个网友问我,怎么能够查询一个表中最后一条插入的记录,我大概回复了,可以通过闪回事务来实现,但是得看什么时候插入的数据,也需要一定的运气。 如果通过闪回事...

    jeanron100
  • 微信小程序设置web-view的业务域名

    登录官方小程序后台,选择设置,选择开发设置,中间有个业务域名,添加业务域名后,小程序才能调用组件打开限定域名内的网页.

    达达前端
  • MySQL OOM(内存溢出)的排查思路及优化方法

    大部分情况下,会杀掉导致OOM的进程,然后系统恢复。通常我们会添加对内存的监控报警,例如:当memory或swap使用超过90%时,触发报警通知,需要及时介入排...

    用户1338460
  • php服务器意外死机,重启后 显示 apache2 test page

    php服务器意外死机,重启后 显示 apache2 test page ...

    似水的流年
  • 站在机器学习视角下来看主成分分析

    主成分分析(PCA)是一种降维算法,通常用于高维数据降维减少计算量以及数据的降维可视化。在本文中,我将从机器学习的角度来探讨主成分分析的基本思想。...

    深度学习与Python
  • 腾讯医疗AI新突破:提出器官神经网络,全自动辅助头颈放疗规划 | 论文

    这次跟美国加州大学合作,在国际权威期刊《Medical Physics》发表最新研究成果:

    量子位
  • 腾讯医疗AI新突破:提出器官神经网络,全自动辅助头颈放疗规划 | 论文

    这次跟美国加州大学合作,在国际权威期刊《Medical Physics》发表最新研究成果:

    量子位
  • Linq基础知识小记四之操作EF

    1、EF简介 EF之于Linq,EF是一种包含Linq功能对象关系映射技术.EF对数据库架构和我们查询的类型进行更好的解耦,使用EF,我们查询的对象不再是C#类...

    郑小超.

扫码关注云+社区

领取腾讯云代金券