数据库性能测试

 

12月10日，前阿里数据库团队资深DBA杨奇龙老师，在【DBA+社群】北京群进行了一次主题为“数据库性能测试”的线上分享。小编特别整理出其中精华内容，供你们学习交流。同时，也很是感谢杨奇龙老师对DBA+社群给予的大力支持。

 

嘉宾简介

 

杨奇龙

• 前阿里数据库团队资深DBA

• 主要负责淘宝业务线,经历屡次11.11，有海量业务访问DB架构设计经验。

• 目前就任于有赞科技DBA，负责数据库运维工做，熟悉MySQL 性能优化，故障诊断，性能压测,对NoSQL感兴趣，但愿与你们多多交流，彼此一块儿成长。

 

内容摘要

 

• 压测方法论

• 为何要压测

• 影响因素

• 统计的指标

• 经常使用的压测工具

• 合理的压测平台

• 参考

 

这个是这次分享的大纲，本次分享其实相对比较简单，偏向于“纸上谈兵” 不涉及具体的实践操做，没有介绍工具如何使用 ，更可能是介绍我对MySQL 压测的认识，总结。有什么不妥之处，望各位大牛不吝指导。

 

演讲实录

 

1压测方法论

 

• 压测目的

• 压测场景／模型

• 结果分析

• 压测报告

 

其实能够把每次压测看成是一个项目，包括压测目的是什么？新版本数据库上线？新功能？ 新的机型 ？

 

肯定压测目标以后咱们要选择何种压测场景进行压测，只读，只写，读写混合？ 观察压测过程当中的性能曲线是否知足咱们的指望，而且真对性能出现可重复性抖动的问题进行分析缘由并改进。

 

压测结束以后，发布压测报告。

 

2为何要压测

 

• 测试数据库新版本的性能

• 测试新机型的性能

• 验证某些DB/OS层面的参数

• 压测新型存储的性能 某个厂商的SSD/nVME

• 压测某些场景

• 好比cgroup 隔离 ，网卡绑定等等

 

其实这个也就是咱们压测的目的/目标 ，新的db/机器/存储等上线和新技术预研，业务大促活动相似于11.11 或者秒杀活动等等都是须要提早进行压测的，评估数据库系统的性能容量和业务瓶颈，要不访问量过大致使业务瘫痪 就比较麻烦了，失去客户对咱们产品的信任了。

 

固然这个需求是对业务量至关大的时候必须作的,若是业务量极小能够忽略该环节。

 

3影响压测的因素

 

讲完压测的目的，咱们要讨论压测过程当中可能会遇到的问题。可能影响总体系统性能的因素大体分为：DB 层面、OS 层面 、存储层面。

 

• DB 层面

 

 

对于MySQL层面，Buffer pool大小事务写磁盘，binlog落盘的策略，innodb 层的并发读设置 事务隔离级别 默认使用rc 都是会影响到最终的压测写入性能表现。

 

• OS 层面

 

 

关闭numa 在bios 里面设置 cpu 为最大性能模式，记得有一两次是因为设置为省电模式致使性能出现问题。初始化系统的时候选择ext4 或者xfs 系统文件。内核参数主要是 tcp 参数，影响业务app 和db之间创建网络链接。

 

• 存储层面

 

 

其实数据库模型能够分为 io bond 类型 和cpu bond 类型，估计你们目前的oltp业务系统，绝大多数的业务系统属于 io bond 类型，你们的业务系统大多数也是都是用了基于 ssd的存储结构 ，可能采用的raid 模式不同有些是raid10 ，有些是raid 5 的差别。

 

在作性能压测的时候须要注意 raid 卡的配置，尤为是读写策略 WB 模式和WT模式性能差别极大。生产业务上注意对raid卡的充放电，避免致使模式变为WT 模式导致性能降低。

 

4须要关注的指标

 

• DB层

• QPS ,TPS ,RT(响应时间)

 

对于db层，我想特别强调对rt的监控，脱离业务场景的压测都是耍流氓，不少压测报告都说qps，tps 极高，可是没有公布对应的rt。大于生产需求的rt 阀值的压测结果都是没有用的。

 

好比说用户发起的一个业务请求，包含20次select，10次dml操做，单条sql，rt 为10ms,应用服务器 和db服务器网络交互 一次同城1ms -2ms，跨城5-15ms，单独db的响应时间就30*10=300ms 了，加上app与db的交互和业务处理，前端的处理时间，对于高并发的系统,吞度量不能接受。

 

• 系统

• CPU: load,usr cpu,

• IO : await, svctm, %util

• 网络: recv , send

 

await：从请求磁盘操做到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间,单位是毫秒(1秒=1000毫秒)

 

%iowait：显示用于等待I/O操做占用 CPU 总时间的百分比

 

svctm：平均每次设备I/O操做的服务时间 (毫秒)%util: 一秒中有百分之多少的时间用于 I/O 操做，或者说一秒中有多少时间 I/O 队列是非空的

 

• 工具

•  orzdba vmstat iostat dstat

 

5注意事项

 

• 每轮压测彼此避免相互干扰

• 使用orzdba 观察 uckpt％ 等待日志刷新完毕以后再开始测试新一轮。

• 注意压测系统的瓶颈

 

我最开始的某些压测场景没有作每次压测的隔离，致使上次的压测结果影响了下一次的压测性能，导致系统rt不稳定。能够经过orzdba –innodbs 命令查看uckpt% 该参数代表还有多少日志没有被刷新到磁盘。

 

6经常使用压测工具(开源)

 

这里我例举几种常见的开源数据库压测工具，仅仅讲述网上公开的how to 资料有不少，你们能够利用谷歌去搜索。

 

• Sysbench

• cpu,threads,mutex,memory,fileio,oltp

 

sysbench是一款开源的多线程性能测试工具，能够执行CPU/内存/线程/IO/数据库等方面的性能测试。数据库目前支持MySQL/Oracle/PostgreSQL。是一款很是受dba 欢迎的压测工具。

 

• Tpcc-mysql

• MySQL OLTP benchmarking

 

TPC(Tracsaction Processing Performance Council) 事务处理性能协会是一个评价大型数据库系统软硬件性能的非盈利的组织，TPC-C是TPC协会制定的，用来测试典型的复杂OLTP系统的性能；Tpcc-mysql是percona基于tpcc衍生出来的产品，专用于mysql基准测试，其源码放在bazaar上，所以须要先安装bazaar客户端。值得说明的是 Tpcc-mysql 包括五个处理逻辑，是比较贴近电商平台业务的一个压测工具New-Order :新订单 Payment :支付 Order-Status :订单查询 Delivery:发货 Stock-Level :库存。

 

• mysqlslap

• MySQL 自带的压测工具 单条SQL

 

mysqlslap是从5.1.4版开始的一个MySQL官方提供的压力测试工具。经过模拟多个并发客户端访问MySQL来执行压力测试，同时提供了比较详细的数据性能报告。而且能很好的对比多个存储引擎在相同环境下的并发压力性能差异。经过mysqlslap –help能够得到可用的选项，我的以为 mysqlslap是全部压测软件中最简单的。

 

• tcpcopy

• 引用线上流量到测试环境，模拟真实压力

 

TCPCOPY 是一个 tcp 流量的实时复制工具，其1.0版本由网易工程师 @tcpcopy 开发和维护。通常用来将生产环境的线上流量实时复制到测试环境进行测试。例如新系统上线前，若是咱们但愿进行一些基本的压力测试，那么咱们能够直接利用 tcpcopy 来复制线上的流量过来对系统进行测试，这样的好处是测试数据接近真实水平，且实施起来相对简单。下面咱们将经过一个真实的使用案例，来简单介绍 tcpcopy 的基本使用方法。咱们假定读者对 tcp 以及路由相关基本知识有必定了解。

 

• Mydbtest

• 楼方鑫的一款压测工具，能够去onexsoft下载

 

Mydbtest 估计不少人没有使用过，以前是楼方鑫在支付宝的时候的一个压测工具，能够根据业务模型 配置业务的sql，利用线上的数据备份进行压测的一款工具，推荐你们尝试使用。

 

7压测工具

 

• Sysbench

• 支持多种目标的测试 缺乏业务场景支持

 

• mysqlslap

• 使用方法简单，容易上手 测试方法/场景单一 TPCC 优势 业务场景固定，可以模拟商品购买流程 缺点 不能表明本身公司业务场景。

 

• tcpcopy

• 真实的线上压力,配置复杂，涉及线上环境，风险偏大。

 

• mydbtest

• 定制sql,模拟业务访问，动态修改,须要先部署好压测目标库,基础工做准备略多。

 

如ppt上所言，每一个工具各有千秋，你们在压测的时候须要选择最适合本身业务/目的的压测工具。不过我本人推荐使用mydbtest 工具，其足够灵活性，适配行更强。

 

8面临的问题

 

• 不考虑场景，就是耍流氓

• 难以模拟线上真实业务压力

• 压测模式不够细化

• 只读,只写,RW,会话数,TPCC 可以模拟五个业务场景

• 不能自动化获取压测结果

 

• 须要人肉处理压测数据 获取QPS,TPS 等

 

9更合理的压测工具

 

在这里我提出的是一个设想，运维自动化足够高的公司能够向这个方向靠近。

 

• 按需定制压测计划

• 模拟线上生产环境

• 配置灵活

• 支持分布式压测

• 自动收集性能数据

 

1.1 根据业务需求制定压测计划

• 压测模型

• 模拟各类业务类型 建立订单，减库存 等等

 

1.2 模拟线上生产环境

• 数据库硬件环境

• 真实的线上数据

• 模拟线上应用行为模式

 

1.3 工具配置灵活

• 适配多个脚本

• 调整读写比

读写比

IUD的比例

• 控制并发度

• 调整活跃/非活跃线程比例

• 支持分布式

跨机房调用多台app server

 

1.4 自动收集性能数据 QPS,TPS,RT

 

 

10总结

 

 

这个是以前和叶金荣讨论关于性能压测的话题以后整理的思惟导图。具体的地址在http://vdisk.weibo.com/s/dCZasgFETrgn/1445265070，涵盖数据库压测的全部内容。固然也有不足之处，欢迎你们给予建议和补充，可以使数据库压测结果更精准 ，为数据库性能/可用性评估提供有力帮助。

 

关于参考，这里我强烈推荐 dimitrik 大牛的blog ，里面聚集了各类压测场景和技术分析。

http://dimitrik.free.fr/

http://blog.itpub.net/22664653/viewspace-713075/

http://blog.itpub.net/22664653/viewspace-757735/

http://blog.itpub.net/22664653/viewspace-757506/

http://imysql.com/2012/12/21/pc-server-benchmarking.html