mysql容量性能测试_二 mysql容量规划，性能测试

何为基线

- 当前运行状态记录、快照

- 用于和未来的状态进行对比

- 未来时刻产生关键事件后的新状态，作为下一个基线

基线数据收集，关注哪些要点

- 系统负载

- MySQL运行状态

- 相应的业务指标

1、系统&MySQL相关性能指标

- CPU：%user、%idle、%sys、%iowait

- IO：tps、await、svctm、%util

- 内存：free(free、shared、buffers、cached)、used，以及swap

- MySQL：tps、rt、lock、hit ratio、waits

如何选择OOM对象：--out of memory

2. 如何选择要kill掉的进程

分析badness代码，其选择过程如下：

1)计算该进程以及其子进程所占用的内存；

2)计算CPU时间和存活时间

3)做相应的权重调整

总结起来，就是占用内存越高，得分越高，cpu时间和存活时间越高，得分越低；进程优先级越高，得分越低

综合上述因素后，会得到一个point的值，得分最高的会被选中，然后被kill掉

rt = response time

lock = row lock、table lock

hit ratio = cache/buffer hit ratio

waits = Innodb_buffer_pool_wait_free / Innodb_log_waits / Table_locks_waited / Innodb_row_lock_current_waits / Innodb_row_lock_waits

2、系统容量指标

磁盘空间利用率

网络带宽利用率

CPU、内存利用率

redis里，一定要禁用 keys * 指令

3、业务指标

并发用户数、请求数

每秒新增业务数/订单数

ethstatus，iftop，ifconfig，ifstat

响应时间：就是用户发出请求到收到响应数据的时间；

并发量：就是系统同时能处理多少用户请求；

吞吐量：就是单位时间内系统处理的请求数量；

容量规划

--理解需求，建立模型，优化目标，优化方案

业务类型

- 静态用户请求，峰值每秒xxx次，平均每秒xxx次

- 动态用户请求，峰值每秒xxx次，平均每秒xxx次

- 读写比例：读多写少(MyISAM/TokuDB为主)、读少写多(InnoDB)、读写相当(InnoDB为主)、

统计为主(infobright、infinidb、TokuDB)、纯写入为主(TokuDB/MyISAM)

- 存盘模式：实时存盘(trx_commit = 1)，异步存盘(trx_commit = 0，或者本地有写入队列)，有cache、不关注(有NOSQL提供缓存服务)

sync_binlog = 1

- 用户语言：亚洲(gbk/gb2312/utf8/latin1)，全球用户(utf8)，西方用户(latin1)

- 数据恢复实时性要求：实时(部署在线热备库，最好还要有高可用方案)，1小时(binlog及时做备份即可，或者用自定义的增备方案)，当天(每天一次全备)

- 预计日新增数据量：xx行，xxMB，预估要分配多大内存、存储空间

- 数据库连接方式：长连接(timeout可以设置大一些)，短连接(timeout设置小一些，或者启用proxy方案)

- 历史数据归档：可归档(分库、分表，按年/季/月/周/日分表或者分区，方便归档)，不归档(未来做垂直拆分)

- 业务峰值性能指标：每秒tps：xx个(机器配置)，容忍最长响应时长：xx毫秒(避免大/长/复杂事务，尽量用小/短/简单事务，并尽快提交)，

预计最高并发数：xx个(内存大小，网络吞吐)

- 其他需求，是否部署redis/memcached缓存层服务

汇总后，评估要点&案例：

- 服务器配置：OLTP-S/OLTP-M1/OLTP-M2

- 数据库备份机制、频率：主从、普通全量备份(mysqldump/xtrabackup)、基于binlog的增备，自行实现备份方案(基于MySQL特性实现，或者基于业务特性实现)

- 数据库冗余方案：单节点、一主一从、一主多从、双主、双主多从、PXC、MySQL Cluster、MMM/MHA/keepalived/keepalived/proxy

- 数据库版本：MySQL官方、Percona、MariaDB、其他

b) 建立模型

根据：

- 每秒tps，峰值tps

- 基础数据量，日均增长数据量

- 最大连接数

- 内存分配

- IOPS

根据上述几个因素制定架构规划，持久层、事务层、cache层，以及分库分表策略，服务器配置(CPU、内存、IOPS、总存储容量)

c) 优化目标

- 针对当前基线中存在的瓶颈进行优化

- 常见瓶颈以IO为主(磁盘IO、网络IO)

- 制定相对应的方案，找到优化的尝试路径

- CPU：%user、%idle、%sys、%iowait

- IO：tps、await、svctm、%util

- 内存：free(free、shared、buffers、cached)、used，以及swap

- MySQL：tps、rt、lock、hit ratio、waits

a) 优化方案

- CPU，更换更好、更多核心的CPU

- IO，更换IOPS性能更高的设备，例如SSD，PCI-E SSD

- 内存，增加内存，合理分配

- MySQL，升级版本，使用Percona/MariaDB分支版本以支持更高TPS或者降低锁竞争粒度

性能测试

a) 基准压力测试目的

- 采购新设备，评估新设备性能

- 开发新项目，评估数据库容量

- 新系统上线前，预估/模拟数据库负载

- 更换数据库版本，评估性能变化

b) 测试模型设计

- 明确测试的核心目标、诉求

- 排除干扰，专注测试目的

- 确定测试环境

- 确定测试过程中的衡量和变量

- 保证测试结果的可重复性

trx_commit = 0/1/2

明确测试的核心目标、诉求(测试新版本性能/可靠性？ 测试新系统性能/可靠性？ 测试新机器性能/可靠性？ 测试新业务性能？)

排除干扰，专注测试目的(集中注意力，测试过程中不要被其他因素干扰测试的核心目标，此外，测试环境也要做到干净，无干扰)

确定测试环境(构建一个合理、合适、科学的测试环境，不会和现实环境差距太大，硬件、系统、配置相当)

确定测试过程中的衡量和变量(每一次对比测试循环中，只变更少数因素，不要一次性变更太多因素)

保证测试结果的可重复性(保证每个循环都至少有3次测试，每次持续至少30分钟，排除最好和最差的测试结果)

注意事项

- 只在本地加压

- 压测数据量小

- 压测时间过短

- 压测模式太少

- 压力负载过大或过小

- 每轮测试完毕要净化环境

压测数据量小(500 warehouse)

压测时间(1h+)

压测模式(读写比例变化、并发数变化，RO、RW)

压力负载(并发4-1024，最大请求数100w – 10亿 )

c) 压测工具介绍

sysbench

tpcc-mysql

ycsb

--warehouse 1000,warmup time 120s,run time 3600,并发线程4-256

--线程，文件系统类型