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 条评论
登录 后参与评论

相关文章

来自专栏一名叫大蕉的程序员

Spark你一定学得会(四)No.68

小伙伴在写Spark任务的过程中感觉非常巨痛苦,总是有奇奇怪怪的问题,写好的程序在开发环境跑得好好的,一上到生产直接被干懵逼了。今天呢,我就跟大伙好好聊聊 Sp...

1815
来自专栏大数据

Solr:不止于文字

Solr于2004年首次创建时,打算成为OpenSource文本搜索引擎,为企业网站和内部文档搜索等用途提供类似Google的搜索功能。 基于Lucene搜索库...

2270
来自专栏Java架构师历程

Mysql海量数据存储和解决方案之—分布式DB方案

1)  分布式DB水平切分中用到的主要关键技术:分库,分表,M-S,集群,负载均衡

1082
来自专栏跨界架构师

又出现异常数据?来剖析一下分布式系统中的「事务」

本文是本系列的第三篇。与前两篇《不知道是不是最通俗易懂的《数据一致性》剖析了》、《烦人的数据不一致到底怎么解决?——通过“共识”达成数据一致性》...

892
来自专栏架构师之路

单KEY业务,数据库水平切分架构实践 | 架构师之路

提醒,本文较长,可提前收藏/转发。 本文将以“用户中心”为例,介绍“单KEY”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践: ...

4006
来自专栏视频直播

世界杯直播技术揭秘及视频云直播回源系统的应用

近些年,视频直播应用蓬勃发展,带宽也是日渐新高,腾讯云旗下的视频云直播为斗鱼、快手、虎牙、龙珠、CNTV广大的企业客户提供了很大的支持,在行业内起到了引领的作用...

852
来自专栏张善友的专栏

CAP理论十二年回顾:"规则"变了

CAP理论断言任何基于网络的数据共享系统,最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。但是通过显式处理分区情形,系统设计师可以做到优化数据一致...

2229
来自专栏公有云的互联网缓存与存储

对象存储的一些理解

对象存储怎么用,对于很多人来说,对象存储是什么都没听过。为什么觉得陌生,因为用得少。

1495
来自专栏跨界架构师

过去这几十年,分布式系统的「数据一致性」精华都在这了!

        本文是本系列的第三篇。与前两篇《分布式系统关注点——数据一致性(上篇)》、《分布式系统关注点——通过“共识”达成数据一致性》形成完整的「数据一致...

1111
来自专栏Java架构师学习

多研究些架构,少谈些框架——一名阿里架构师的笔记

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为...

3388

扫码关注云+社区