sysbench压测小记(r11笔记第99天)

对于很多线上业务而言,如果有新服务器,新的环境,新的业务,到底资源和预期的承载压力是否匹配,这个得用数据说话,或是通过严谨的论证来阐述。

比如一台新的服务器,一般都需要经过压力测试,我们也叫拷机测试。一般都会从多个维度来进行加压(比如CPU,内存,IO等等),看看服务器是否依旧坚挺,虽然这一点上如果产生了懈怠或者懒惰还是会被轻视,但是从身边的例子来看,还是会测试出一些问题来,如果发现了问题,就避免了后续的很多被动。

sysbench就是这么一个工具,功能非常全面。是一个标准模块化,多线程的基准测试工具。

安装的过程相对比较简单,下载之后参考README文档即可,我就直接略过了。

这个工具能够测试哪些方面呢,我们用命令来说明。

 sysbench --help
。。。
Compiled-in tests:
 fileio - File I/O test
 cpu - CPU performance test
 memory - Memory functions speed test
 threads - Threads subsystem performance test
 mutex - Mutex performance test
 oltp - OLTP test

简单来说就是下面的一些方面。

1、磁盘IO性能 2、CPU运算性能 3、调度程序性能 4、内存分配及传输速度 5、POSIX线程性能 6、数据库性能(OLTP基准测试)

比如测试CPU,如果让我们测试还真没有什么好的思路,看看sysbench是怎么做的,可以使用命令sysbench --test=cpu help得到如下的结果:

cpu options:
  --cpu-max-prime=N      upper limit for primes generator [10000]

可以看到重要的关键字prime,即质数,比如查找小于一千万的最大质数,这个问题还是蛮烧脑的,就让CPU来烧吧,这样运行即可。会启用10个并发线程,最大请求数是100

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=cpu --debug --cpu-max-prime=10000000 run 

有了CPU压测的基本概念,后续的几种解释起来就相对容易一些了。

比如测试内存,可以指定测试范围,如32G,64G根据自己需要来。

比如我们测试32G内存,并发线程数是10个,最大请求数是100,分别从读和写两种测试来做。

内存读测试

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=memory --memory-block-size=8k --memory-total-size=32G --memory-oper=read run

内存写测试

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=memory --memory-block-size=8k --memory-total-size=32G --memory-oper=write run

而对于IO测试而言,是有些区别的,因为会有准备数据(比如写一个临时文件),所以会分成几个阶段,准备阶段,运行阶段,清理阶段。

下面就是一个相对简单的场景,20个文件,每个10GB,随机读写,文件大小总量在200G.

/usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw prepare /usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw run /usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw cleanup

硬件类的测试,基本一次测试就能够得到一个基线数据,就不需要反反复复测试了。而对于DBA还是开发同学而言,更加关注于业务层面,我们会从很多可能的角度和场景去分析权衡,这些sysbench也是支持的,就是oltp选项。

当然sysben对于mysql的支持是原生的,而对于其他的数据oracle,PostgreSQL等数据,需要单独配置。

因为应用测试会产生基础数据,所以也是分为多阶段的。

比如准备基础数据,进行压力测试,最后的统计结果和后期的清理。这里值得说的是,对于较低版本的sysbench而言,还不支持多表参数--oltp_tables_count,准备好基础数据,后面就会开启多线程模式进行模拟压力的测试。比如下面的命令,测试模式complex,并发线程数30,最大请求数5000000 ,表的数据量在一亿。先创建一个测试库sysbenchtest,测试完成之后删除即可。

mysql -uroot -e "create database if not exists sysbenchtest" /usr/local/bin/sysbench --mysql-user=root --test=oltp --mysql-host=localhost --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-db=sysbenchtest --oltp-table-name=innodb_test --num-threads=30 --max-requests=5000000 prepare /usr/local/bin/sysbench --mysql-user=root --test=oltp --mysql-host=localhost --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-db=sysbenchtest --oltp-table-name=innodb_test --num-threads=30 --max-requests=5000000 run mysql -uroot -e "drop table if exists sysbenchtest.innodb_test; drop database if exists sysbenchtest"

在一台服务器上我进行了测试,发现1亿左右的数据,数据文件在24G左右。

-rw-r----- 1 mysql mysql 61 Mar 10 11:20 db.opt -rw-r----- 1 mysql mysql 8632 Mar 10 11:20 innodb_test.frm -rw-r----- 1 mysql mysql 24419237888 Mar 10 13:29 innodb_test.ibd 得到的报告如下,可以看到整个过程持续了近3个小时,TPS在455左右,其实还是不高的。

对于压力测试,其实一个蛮不错的想法,就是我指定压测的策略,然后让它去在后台运行,MGR测试脚本已经写好,会在测试之后共享给大家,这样一来,我可以在瞬间创建出多个节点,然后测试很多复杂的压力场景。到时候我就直接查看数据,得到一个报告,想想都很有意思。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2017-03-10

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逸鹏说道

AI---Anaconda For Linux (附C#交互式编程的引入)

Jupyter美化: https://www.cnblogs.com/dotnetcrazy/p/8760189.html

15640
来自专栏Ceph对象存储方案

RGW Bucket Shard设计与优化-上

1 bucket index背景简介 bucket index是整个RGW里面一个非常关键的数据结构,用于存储bucket的索引数据,默认情况下单个bucke...

1.5K50
来自专栏进击的程序猿

高效的并发控制

本文是阅读论文Efficient Optimistic Concurrency Control Using Loosely Synchronized Clock...

8530
来自专栏PHP在线

缓存更新的套路

看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。试想,两个并发操作,一个是更新操作...

393130
来自专栏我是攻城师

多线程基础知识了解一下

作为一名优秀的攻城师,了解多线程的知识非常有必要,尤其在人工智能和机器学习的热潮下,如何提高程序或者算法的运行效率是非常有价值的一件事情。

27830
来自专栏信安之路

web测试方法工具篇

之前写过一个文章《web应用渗透测试流程》,这个文章的主要内容是关于一个web应用如何进行测试,测试什么地方,没有过多的提供使用的工具,只是一个针对web测试的...

19400
来自专栏北京马哥教育

【Linux调优】linux系统性能监控与优化(1)–简介

最近几年做了很多性能优化的事情,但是一直没有形成一套理论,也没有很好的形成一个好的排查问题的流程,每次做优化,大多是经验式的查找,最近看了一下这本书《linux...

31460
来自专栏java思维导图

rpc思维导图,让rpc不再难懂

解析 RPC(Remote Procedure Call),远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。 ? 在O...

39590
来自专栏Android开发经验

让你的App有声音

12120
来自专栏JAVA技术zhai

通过Java 线程堆栈进行性能瓶颈分析

改善性能意味着用更少的资源做更多的事情。为了利用并发来提高系统性能,我们需要更有效的利用现有的处理器资源,这意味着我们期望使 CPU 尽可能出于忙碌状态(当然,...

393110

扫码关注云+社区

领取腾讯云代金券