mysql数据库性能测试实例_数据库性能测试方案示例

本文详细介绍了如何进行数据库性能测试,包括明确测试目的、设计压力模型、准备测试环境、选择测试工具、监控性能指标等步骤。通过对比单实例与多实例在不同硬件设备上的性能,验证网络带宽瓶颈和硬件性能衰减情况,提供了一套完整的多实例多盘数据库性能测试方案。
摘要由CSDN通过智能技术生成

前言 :

究竟怎样进行数据库性能测试,数据库性能测试需要做些什么?大多数产品线的RD和QA也比较迷茫,经常过来咨询。

一般说来,做数据库性能测试需要如下几个步骤:

1:明确测试目的

2:设计测试模型 (即压力模型)

3:准备测试集群环境

4:准备压力测试工具或者编写压力测试脚本

5:明确性能指标并加监控

6:根据2设计的测试模型准备测试数据

7:测试执行

8:测试分析

本文依据以上步骤,模拟测试需求- 多实例多盘数据库的性能对比测试,制定测试方案公布给大家,方便大家了解数据库性能测试。

多实例多盘数据库性能测试方案

一、 测试目的

1. 对比数据库单实例、多实例的在不同硬件设备上的性能情况。

2. 对比单机单实例和多实例的性能情况

3. 验证网络带宽是否成为flash产品发挥性能优势的瓶颈。

4. 验证flash产品是否随时间存在性能衰减的可能。

二、 测试方法概述

测试基准工具:smart-slap(mysqlslap),Jmeter模拟若干客户端、若干用户执行指定的SQL语句,访问数据库。同时,通过监控工具监控系统负载、mysql数据库的服务,全面了解数据库系统以及硬件的负载情况。

href=”https://i-blog.csdnimg.cn/blog_migrate/e17d8b0ed7ce73dfe4feda3abe5c2f32.png”>

b1.JPG

测试模型

测试监控及结果统计

监控工具统计如下信息,分析性能瓶颈。

系统负载:

CPU:CUP_IDLE 、CPU_WA、SERVER_LOADAVG

内存:MEM_URATE、MEM_USED

网卡:NIC_TOTAL_IN、NIC_TOTAL_OUT、

数据库负载:

QPS:COM_READS、COM_WEITES

主从延迟:SECOND_BEHIND_MASTER

慢查询:SLOW_QUERIES_PT

连接数:THREADS_CONNECTED、THREADS_RUNNING

STL-tools 监控集群负载

附:性能指标:

系统负载:

CPU:CUP_IDLE 、CPU_WA、SERVER_LOADAVG

内存:MEM_URATE、MEM_USED

网卡:NIC_TOTAL_IN、NIC_TOTAL_OUT、

数据库负载:

QPS:COM_READS、COM_WEITES

主从延迟:SECOND_BEHIND_MASTER

慢查询:SLOW_QUERIES_PT

连接数:THREADS_CONNECTED、THREADS_RUNNING

三、 测试准备

测试环境准备

假设将四类IO存储设备,进行单、多实例的性能测试对比。则可以部署测试集群如下:

b2.JPG

测试集群具体搭建:

2台机器 ——–4主4从

根据测试更换硬件:

RAID+SAS:

RAID+SSD:

Flash :

Fusion :

监控:在每台机器上部署数据库监控脚本monitor,最好有统一平台上调度、管理、分析monitor采集到的数据。

测试工具准备:

Smart-slap :

特点:全量发压力,可得到最大QPS,对比不同集群的最大QPS。分析不同集群的最大QPS.

Jmeter:

特点:控制实时压力,分析各集群在指定压力下的性能情况。

测试思路:

先采用slap进行对不同集群组合进行同样的sql压力。(压力时间)取得不同集群的最大QPS,进行对比。

取最大QPS的一定比率(如1/8倍,1/4倍,1/2倍,1倍)作为每秒发送的请求压力进行测试。比较各个集群的负载、数据库性能情况。

网络瓶颈测试:

同网段3台压力机器 往一个集群压足够多的IO压力。分析各个硬件的IO。磁盘、CPU比网卡提前到达压力阀值说明网卡不是瓶颈。若网卡IO先达到极限则说明网卡存在瓶颈。

硬件性能衰减测试

同样压力测试24小时,比较最初1小时,和最后1小时的 TPS.以及各项性能指标。

测试数据准备:

数据库: flashT

36张表:

Test1- test36 :

表结构:

CREATE TABLE `test1` (

`doc_id` int(10) unsigned NOT NULL default ’0′,

`main_status` tinyint(3) unsigned NOT NULL default ’0′,

`sub_status` tinyint(3) unsigned NOT NULL default ’0′,

`create_time` int(10) unsigned NOT NULL default ’0′,

cid1` smallint(5) unsigned NOT NULL default ’0′,

……………

PRIMARY KEY (`doc_id`)

);

数据量:

每个表达到5000W 行(大概30G)

36个表

说明:具体的测试库表结构、类型

每张表的测试数据量等都需要根据具体测试目的和测试场景进行设计。

四、 测试步骤

测试一: 不同集群配置,不同实例的性能对比测试

一: 数据构造,同时验证各硬件集群基本读、写性能。

1) 4个实例全部开启insert 5000W ;初步对比写性能.

用36个slap并发实例分别往36张表insert,往每个表插入5000W 行数据。

2) 4个实例全部开启,每张表20个select并发select。初步对比读性能。

用36个slap并发实例子每个实例20个并发select请求分别从36张表中取数据。

二:对比不同集群执行最常用SQL命令的性能情况

制定数据库系统最常用的SQL语句,数据库执行这些SQL语句的性能。用slap并发用户数从10,50,100,200。

三:对比不同集群处理最耗时SQL命令的性能情况

制定数据库系统最耗时的SQL语句,数据库执行这些SQL语句的性能。用slap并发用户数从10,50,100,200。

四:模拟事务处理,对比各集群性能情况。

模拟事物,,用slap并发用户数10,50,100,200,500,800,1000分析不同集群分别在多少并发用户数下,TPS值最大。

五:分析各集群在线事物处理能力。

模拟事务处理,根据步骤四得到的最大TPS,设置TPS的一定比率作为每秒事务数,用jemeter测试,并发,10,50,100,200,500,800,1000.分析各个并发各种集群下的响应时间分布和其他各项性能指标。分析TPS情况最好的并发数。

测试二:网卡瓶颈测试

步骤一:分析测试一中的各项测试结果的CPU、磁盘、网卡等负载情况。

如果其他几项比网卡提前到达瓶颈。则说明网卡不会成为瓶颈。相反进入步骤二。此外,如果测试一中的各项测试磁盘,网卡,CPU等均未达到瓶颈。则将测试一中的步骤四,增大并发压力,直到出现负载瓶颈。

步骤二:调整测试。

测试三:硬件是否衰减情况。

步骤:用jmeter 持续测试24小时。

用测试一中的步骤五得到的最好TPS的并发数作为此次测试的并发数,用Jmeter并发测试24小时,分析第一个小时和最后一个小时的TPS,和响应时间分布。

(注意每一次测试命令中,涉及查询条件的值随机分布)

五、 总结:

关于数据库性能测试,只要掌握了压力测试工具。最关键的还是设计出符合业务的测试模型,以及测试完成后的测试分析。通过实践抽象出测试模型,进行自动化,则测试过程可以事半功倍。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值