sysbench在美团点评中的应用

如何快速入门数据库?以我个人经验来看,数据库功能和性能测试是一条不错的捷径。当然从公司层面,数据库测试还有更多实用的功能。这方面,美团点评使用的是知名工具sysbench,主要是用来解决以下几个问题:

  • 统一测试方法,以便测试结果的可重复和可对比。
  • 结合美团点评的业务特点和硬件特性,得到最优的参数配置。
  • 扩展sysbench的测试能力,比如增加对JSON测试的支持。

数据库测试虽然入门简单,但是却能在测试中获得对数据库、操作系统等的感性认识,为日后深入的研究数据库和性能调优打下很好的基础。如果你不满足于仅仅使用测试工具,还想开发自己的测试工具,那么在本文的最后,还会从源码层面解读sysbench的高性能秘密。

测试可重复性

如果只是把测试工具运行起来,获得一个输出结果,那么测试就变成一个没有任何技术含量,也没有实际意义的事情。一个经得起推敲的测试,首先要保证测试结果的可重复性。测试结果的可重复性可能与系统的硬件、操作系统的版本、I/O调度算法、CPU调度算法、数据库版本、数据库的配置、测试工具、测试时间等息息相关。美团点评集团DBA有两位数以上,如果没有一个统一的测试平台,那么每个DBA的测试结果将难以比较,整个团队也无法有效协作。为了解决这个问题,我们做了几点的强制统一:测试工具及其参数的统一、MySQL配置的统一。

为何选用sysbench

当前可采用的测试工具有sysbench、TPCC-MySQL以及公司或者个人开发的压测工具。从功能上来讲,无论采用哪种方式都可以满足要求。美团点评采用sysbench有如下几点考虑:

  1. sysbench作为业界流行的测试工具,绝大多数DBA都熟悉它。
  2. MySQL几大主流厂商Oracle、Percona等在发布性能数据时,都采用sysbench作为测试工具。使用相同的测试工具,更便于复现测试结果。
  3. sysbench目前已支持MySQL 8.0的测试,因此从长远来看,该工具将会持续活跃。美团点评可以充分利用开源社区资源,降低测试工具的维护成本。
  4. sysbench内嵌了Lua脚本。在不需要修改核心的C语言代码的情况下,通过增添或者修改Lua脚本,即可扩展新的测试场景,大大提高了DBA人员对sysbench的掌控能力。

测试参数统一

sysbench提供了丰富的测试选项,包括测试表数量、单表数据量、测试预热时间等。我们根据美团点评的业务特征和使用sysbench的经验,为了避免新同学走不必要的弯路和降低测试的时间,将部分测试参数统一。另外在测试中,对MySQL核心参数做了强制统一。比如sync_binlog=1,innodb_flush_log_at_trx_commit=2,innodb_io_capacity=2000等。这里不一一赘述。

这里简要介绍sysbecnh测试过程中涉及到的几个重要参数:

sysbench助力参数优化

相对于业务更新速度,数据库的变化较为缓慢,然而影响MySQL数据库性能的因素却不断呈现出来。硬件方面,比如SATA、SSD、PCIe的出现,让数据库的IO能力相对于传统的机械硬盘有几百甚至上千倍的提升;CPU多核技术的发展,让单台服务器拥有上百个核;单GB内存的价格越来越低,服务器配置的内存也越来越大。软件方面,MySQL 5.7的出现,增强了多核处理能力,提高了从库的复制速度等。

如何将新硬件和新版本的性能发挥到极致,是每个DBA都会遇到的问题。美团点评DBA团队在前期理论调研后,会设计符合公司业务特征的场景进行严格的性能测试,确定最终的参数配置方案。下面以确定MySQL 5.7中多线程复制的slave_parallel_workers参数为例,来了解如何使用sysbench来优化参数配置。

为了测试从库的复制速度,我们使用sysbench的oltp_write_only.lua(包括增、删、改)在主库制造负载(TPS:33,336),观察从库的TPS,如下图所示。

从上图看出,工作线程在8时,从库的TPS达到最大。到这里为止,对于数据库新人来说,我们可以很自信的宣称自己学会了通过测试进行数据库调优。但是我们不能只满足于此,应该做更深入的探究。比如,多线程复制的原理是怎样的?如何进一步提升从库的TPS?建议有兴趣的读者可以继续调研binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count参数。

sysbench可扩展性

测试场景可扩展

sysbench不仅具有丰富的功能,还具有优良的设计与实现。为了把测试场景完全交给客户定制,所有的测试用例,均使用Lua编写;如果需要支持新的数据库,只要实现sysbench提供的10来个接口即可;而其他通用功能,均由sysbench提供。架构图如下。

使用过sysbench或者其他同类型测试工具的都知道,数据库测试分为三个阶段,包括prepare阶段、warmup阶段、运行阶段。这三个过程的实现完全使用Lua来控制,因此很容易定制。sysbench提供的默认测试用例有只读测试、只写测试、读写混合等。这些测试用例也是用Lua实现的,通过修改这些测试用例,测试人员可以很快的掌握编写自己测试用例的技巧。

比如,日前在评估MySQL 5.7 JSON替代MongoDB的可行性。与业务人员交流过程中发现,业务中并没有使用MongoDB的一些复杂特性,比如内嵌JS代码、map/reduce等特性,但是其TPS较高,较为关注MySQL 5.7+JSON与MongoDB的性能比较。因此需要一款可以测试MySQL JSON性能的测试工具。在前一节的分析中,我们只需更改sysbench中几个Lua文件即可拥有这样的测试工具。

性能可伸缩

sysbench的高性能有两个方面,一方面是其采用多线程结构,同时模拟多个客户端去并发操作,这方面无需赘言;另一方面是其高效的性能收集,比如多个线程同时执行多个任务,那么性能信息的更新可能会存在热点等状况,本节来解密其高性能的数据收集技术。

性能数据收集

数据库的性能往往不能用简单的TPS或者QPS来反映,还需要知道压测过程中系统的运行是否平稳(响应时间和QPS等)。

如果仅给出系统的最大TPS,比如10000左右,可能掩盖了系统中的重要信息。比如上图中,系统的TPS随着时间,周期性的严重抖动,值得数据库和开发人员关注。通过打开sysbench的周期性报表,即可获得这样的统计信息。

引入热点的性能信息收集

在上图中,可以看到TPS和QPS的数值。在多线程编程环境中,想要获得一段时间内执行的事务数量或者SQL数量,可以通过引入一个原子变量,当执行完一个事务和SQL后,就自增一次。

如此一来,全局的事务计数器与SQL计数器就会成为多个线程竞争的热点,影响sysbench的扩展性甚至严重干扰测试结果,尤其是在目前的多核处理架构,如下图所示。

据某著名数据库专家的话,凡是有热点的地方,解决之道只需一个字:拆。比如大家耳熟能详的分库分表,将大表拆成小表,大库拆成小库;像在大内存的系统中,MySQL会自动创建多个buffer pool instance,就是为了避免多个线程同时去竞争一个互斥量。sysbench在解决这个问题时,也不能例外。它为每个工作线程都分配一个局部的计数器,增加计数时,只需更新线程内部的计数器;当需要获得全局计数时,把局部计数器的值汇总即可。这种办法获得的计数值精确度比上一种办法要低,但是其可以线性扩展,而且在性能数据收集这个角度其精确度已经足够了。具体代码在sb_counter.c中,有兴趣的可以下载代码阅读。

SQL响应时间分布

在评估数据库的响应时间时,我们经常会提到90线、95线和99线(分别代表90%,95%和99%的响应时间在某个值之下)。因为最大值和最小值往往受偶然因素的影响很大,而平均值往往会淹没更多的细节。一个SQL响应时间的分布可以让DBA更好的了解数据库的性能,因此优秀的测试工具必须支持这个功能。

在实际的编程中,我们往往会遇到一个矛盾的问题。数据库的响应时间往往差距很大,比如快的可能在0.01ms以下,而遇到数据库抖动或者复杂查询时,可能到秒级别,甚至几十秒都有可能。如果使用算术刻度,比如单位为0.01ms,那么就需要长度为千万级别的整型数组去表示,耗费大量内存。而且在响应时间为秒级别时,如此精确的计数也没有必要。我们需要的是随着响应时间越小,精度越高,响应时间越长,精度可以适当放低,而“对数刻度”正好具有这种特性。

对数刻度

sysbench正是使用该方法做时间统计。当sysbench得到一个响应时间时,通过k=floor((log(response_time) +6.908) * 55.35 + 0.5) ,获得刻度值k。当响应时间为response_time=0.001时,k为0;response_time=0.01时,k=128;当response_time=10时,k=509;当response_time=100时,k=1023。随着响应时间的增加,k的变化越缓慢。其中横轴为刻度k,纵轴为响应时间,单位为ms。

当测试完成时,需要将k转化为响应时间。算法为respone_time = exp((k/55.535)-6.908)。这样就可以使用较少的空间,完成较大时间跨度的记录,而且精度是动态变化的,响应时间越小,精度越高。

响应时间收集之热点

在官方给出的MySQL性能测试数据库中,我们可以看到在高端机型上QPS已经达到百万,即使在一般的企业级服务器,也能达到几十万的级别。在前面的介绍中知道,响应时间是记录在一个数组上的,如果响应时间比较稳定,假设有50%的响应时间是落在一个刻度上,那么该刻度对应的变量就会被每秒更新几十万次,形成一个更新热点。参考下图。

在前面性能信息收集上也遇到类似的热点问题,当然我们也可以给每个线程各配备一个response[1024]的数组来避免热点。sysbench采用了类似的方法,但是做了些改变。它也是采用多个response[1024]的数组,但是其数量被固定为128个。

响应时间收集之避免热点

结论

美团点评运用sysbench进行性能测试以调整MySQL配置参数,也扩展了sysbench的功能来做JSON测试。通过对其源码研究,我们了解了其良好的功能扩展性以及其性能扩展性。未来美团点评会在sysbench上做进一步的定制,比如将测试做成服务化,让开发和运维人员能够方便使用sysbench做数据库的容量测试,也可以让数据库爱好者更快上手数据库测试。

原文发布于微信公众号 - 美团点评技术团队(meituantech)

原文发表时间:2017-07-14

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

平台设计中的脚本管理

前期揉入了一些功能,因为主要是面向基础功能,所以进度略慢,如果要想一下子有种井喷的效果,那就是脚本化和流程化大显身手的时候了。 如果尽可能减少开发和业务同学之间...

3844
来自专栏知晓程序

小程序用起来耗流量吗? | 小程序问答 #5

1152
来自专栏java达人

Base:Acid的替代方案

作者:DAN PRITCHETT 译者:java达人 来源:https://queue.acm.org/detail.cfm?id=1394128(点击阅读原...

3945
来自专栏CSDN技术头条

围绕着内存数据库的4个流言

【编者按】作者Yiftach Shoolman是Redis Labs的联合创始人兼CTO,拥有着丰富的实践经验。Yiftach 之前曾是Crescendo Ne...

1957
来自专栏weixuqin 的专栏

django 实现电子支付功能

  思路:调用第三方支付 API 接口实现支付功能。本来想用支付宝来实现第三方网站的支付功能的,但是在实际操作中发现支付宝没有 Python 接口,网上虽然有他...

1282
来自专栏非著名程序员

关于Android四大组件最权威最深刻最准确的解读(绝不标题党)

这篇文章翻译自Aannie Hackborn发表在google+上的一篇post,她是google资深大牛,2005年就进入Android Framework团...

19210
来自专栏企鹅号快讯

z/OS Connect 助力你的业务更上一层楼

上周有关API 经济的推送得到了热烈的反响,今天我们趁热打铁,解说下之前留下的一个引子。下面是我们今天要cover的重点: z/OS Connect Enter...

2080
来自专栏Linyb极客之路

面对峰值响应冲击,解决高并发的三大策略

在写这篇博客的前2天,听说某系统在25人的用户量下就宕机了,实在让人震惊,所以捋了下互联网交易系统我们可以采取哪些技术来解决互联网平台下大数据量高并发的问题。

1853
来自专栏恰同学骚年

《大型网站技术架构》读书笔记之七:随需应变之网站的可扩展架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

923
来自专栏SAP最佳业务实践

想学FM系列(14)-SAP FM模块:预算结构(5)-预算结构操作-预算地址维护

3.2.2 预算结构操作 3.2.2.1 预算地址维护 ? ? 1)FMBSBO - 单个处理 功能:手工维护预算地址 ? ① 预算类别:选择使用的预算类别,...

4238

扫码关注云+社区