转载

使用sysbench压力测试MySQL（一）(r11笔记第3天)

今天用了下新版本的sysbench，发现和早期版本的差别还不小，确实有不少有趣的地方，是的，我们继续测试下MySQL。

如果大家看过《高性能MySQL》这本书，就会发现里面对于基准测试的描述非常全面和专业，里面的测试场景都是基于早期版本，这个版本有一个不太方便的地方就是无法抓取到更细节的数据，只有平均值，所以要不需要定制脚本，要不就需要更多的测试场景和时间来得到一个报告。

sysbench目前最新的版本是1.0.3，里面的interval参数确实很赞，也是驱动我尝试的最大动力，因为能够得到一个相对实时的数据变化。

sysbench的作者

在MySQL这个圈子里，Alexey Kopytov 很多人都知道，他是sysbench的作者，而且同时他就职于Percona,曾经在Oracle参与MySQL的研发工作。Percona Server和XtraBackup工具就是他们合理开发的。所以sysbench原生支持MySQL也就显得顺利成章，一个好的工具离不开那些低调的技术牛人。

Alexey Kopytov is a Principal Software Engineer at Percona. Before joining Percona in 2010 he was a member of the MySQL development team at Oracle. His focus at Percona is development of both Percona Server and Percona XtraBackup.

安装sysbench新版本的坑

安装sysbench的步骤常规就是四步：

运行autogent.sh脚本
./configure
make
make install

但是这样一个常规的工作在新版本中需要注意一些地方，可能会导致你安装失败，比如autoconf的版本需要在2.63以上，RedHat 5的版本中默认是2.59，满足不了，而且最重要的是如果你使用的版本低于RedHat 6，很可能遇到下面的这种错误信息：

lj_ir.c:64: error: ‘exp2’ undeclared here (not in a function)
lj_ir.c:64: error: ‘log2’ undeclared here (not in a function)
make[3]: *** [lj_ir.o] Error 1如果c功底很扎实，可以trace一把，也可能找到那些过期的设置，做一个屏蔽，我是最后果断放弃了。一来升级autoconf版本，二来调试这些边界问题，最关键的RedHat 5竟然默认没有安装Lua,这可是新版本中的标配。

所以安装新版还是直接在RedHat 6以上的版本使用为佳。

如果你使用sysbench抛出了MySQL链接库的问题，这个处理相对要常规一些。

# sysbench --test=oltp help
sysbench: error while loading shared libraries: libmysqlclient.so.20: cannot open shared object file: No such file or directory我们可以添加一个软链接

ln -s /usr/local/mysql/lib/libmysqlclient.so.20 /usr/lib/
如果没有生效，在ld.so.conf中配置生效即可

添加路径至/etc/ld.so.conf
ldconfig

Lua的安装

Lua脚本是sysbench新版本中的标配，所以你得熟悉下基本的安装，而且Lua语言相对比较简洁，源代码几百KB,用c开发，非常适合作为一门语言的完整学习捷径，总体看了下感觉很不错。

wget -c http://www.lua.org/ftp/lua-5.2.0.tar.gz
解压后切换到目录下
make linux
make install

压力参数前的准备

我们打算测试的MySQL默认的参数如下,如果猛然看看这个配置好像没有太大的问题，其实有几个，我们通过性能测试来说明。

port=3306
socket=/home/mysql/s1/s1.sock
server_id=3306
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
#log_bin=binlog
binlog_format=ROWsysbench中原来的test选项已经失效。

# sysbench --test=oltp help
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.我们开启sysbench的测试，可以使用如下的命令生成数据。

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=30 --events=5000000 --report-interval=5 prepare
这里有几个地方要提一下，首先新版的sysbench需要指定一个Lua模板，在sysbench安装目录下自带了一批模板,src/lua目录的文件如下,我们选择读写的oltp模板。

bulk_insert.lua
internal
Makefile
Makefile.am
Makefile.in
oltp_common.lua
oltp_delete.lua
oltp_insert.lua
oltp_point_select.lua
oltp_read_only.lua
oltp_read_write.lua
oltp_update_index.lua
oltp_update_non_index.lua
oltp_write_only.lua
select_random_points.lua
select_random_ranges.lua
原本的参数

--oltp-test-mode=complex已经失效，

--mysql-table-engine=innodb 选项也不存在
--oltp-num-tables=10 需要改为--tables=10
--oltp-table-size=5000000 需要改为--table-size=5000000

测试场景对比1

对于数据库是否开启binlog,开启前后对于数据库本身的性能影响到底有多大，这个我一直没有一个相对清晰的感受，决定逐步来测试一下，我首先设置了线程数为30,50,100,150为样本进行测试。

开启30个线程的测试。，对于50个，100个只需要调整--threads即可。

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=30 --report-interval=5 --time=300 run得到的结果类似下面的输出，每5秒钟输出一次，tps,qps这些一目了然。

使用sysbench压力测试MySQL（一）(r11笔记第3天)

我测试了3分钟之内（说实话时间有点短）。但是还能看出一些效果。对于线程30，线程50等的场景测试下，可以看到在线程100~150之间测试结果的数据结果有些不稳定，逐步呈现下降趋势。

使用sysbench压力测试MySQL（一）(r11笔记第3天)

然后我测试了开启binlog之后的数据。

使用sysbench压力测试MySQL（一）(r11笔记第3天)

这个数据可以基本看出线程100和线程150的TPS差别不大。

而是否开启binlog的差别在短时间内的比较来看，差别到底有多少？这样对比来看相对就清晰一些了。左边是未开启binlog,右边是开启之后的。

使用sysbench压力测试MySQL（一）(r11笔记第3天)
通过上面的测试我们可以看到一些瓶颈，而且在后期加压的时候，发现加不上去了，一个主要原因就在于支持的最大连接数不够。我们对此做了一个简单的优化，那就是调节innodb_buffer_pool_size，默认竟然是100多M,支持的连接数是151个。

调整innodb_buffer_pool_size为24G,支持的连接数为3000个，我们继续测试。

其它条件不变的情况下，TPS可以翻一倍，达到1200~1500，QPS为20000左右。

使用sysbench压力测试MySQL（一）(r11笔记第3天)

当然按照这种加压方式，当加压测试到线程数300就又扛不住了。所以通过这些测试能够马上发现很多潜在的问题。

FATAL: mysql_stmt_prepare() failed
FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 16382)"
FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:282: SQL API error
FATAL: mysql_stmt_prepare() failed后续进行更多的测试，也会延长时间来得到一个相对更细致的报告。

正文到此结束