二 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
--线程，文件系统类型