MySQL的性能基线收集及压力测试

建立基线的作用：
计算机科学中，基线是项目储存库中每个工件版本在特定时期的一个“快照”。

比如我们现在有并发事物，那么在某时刻发起一个事物会产生当前数据的快照，那么这个快照就相当理解为一个基线，那么所谓的性能数据的基线就是正常数据收集后的一段时间或者业务数据的负载，将它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。

 

什么是基线

1.当前运行状态记录、快照，其作用是将其与未来的状态做对比，那么未来的时刻产生的关键时刻的新状态则作为下一次的状态做对比

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

 

基线收集，需关注的重点

1.系统负载
2.MySQL运行状态

 

记录以上两个重点以便用于优化，比如做一次优化之前先记录一周的状态，比如最高、最低、平均等

优化的工作结束之后，我们再去逐渐观察，这样我们就能知道大概情况是如何

但是有些时候有些误区，比如在优化之前tps可能1000 ，优化后可能还是1000，但是但从tps来看的话可能没有什么，但是我们还需要关注它的iops等信息有所下降，这也是一种优化，所以要多纬度的去对比

 

建议收集基线数据的状态信息（需要关注的瓶颈）

系统层需关注的信息：

·CPU：%user、%idle、%sys、%iowait      #最通用的几个指标
·IO：tps、await、svctm、%util

·内存：free（free、shared、buffers、cached）、used，以及swap

    内存的利用率越多越好，所以我们主要关注空闲、使用、还有swap ，si so

    当前是否使用swap 是否频繁使用swap 也需要关注     

 

数据库层需关注的信息：

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

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

在找瓶颈的时候优先这几个地方进行分析，针对分析结果再定义优化方案

 

工作成果量化

所谓的量化，其实无非是对比（相同条件下、相同场景下）

    相同条件下：比如说同一套硬件，以前之能跑tps到1000，但是优化后tps能达到5000，这是很大的变化

相同场景下：之前的资源利用率是10% 但优化后降到了5%

 

相同业务负载下，基线数据产生变化

比如同样的用户量 同样的设备，经过优化的之后，tps是降低还是提升，util、cpu等

 

相同基线数据情况下，业务数据发生变化

 

建立目标，考证方案可行及总结

我们需要建立一套标准来验证我们的方法是否可行
·建立目标
·针对当前基线中存在的瓶颈进行优化
·常见瓶颈以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

 

假设做的优化，针对IO 那么重点记录的是io相关的情况，然后在优化完再判断util等io相关的数值是否产生了变化

也就是说优化工作是需要针对当前基线数据中的瓶颈进行的，

通常的瓶颈，目前来说还是磁盘IO和网络IO