首页 > 代码库 > 数据库性能测试

数据库性能测试

2024-09-25 16:01:39   215人阅读

 

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

 

数据库性能测试


联系
我们