性能优化简介
性能定位为完成某件任务所需要的时间度量，换句话说，性能即响应时间。
性能优化就是在一定的工作负载下尽可能的降低响应时间。
**
误区：
- 性能优化不应该是降低CPU利用率，因为CPU利用率的提升代表资源被消耗的更多，更多的资源消耗是用来工作的，用来提升查询效率的
- 性能优化不应该是吞吐量的提升，吞吐量是单位时间的查询数量，响应时间缩短了，吞吐量自然就上去了，吞吐量是性能优化的副产品
完成一件任务所需时间分成两部分：
- 执行时间
优化方案：测量定位不同子任务花费的时间，然后优化掉子任务或者降低子任务的频率或者提升子任务的效率。
- 等待时间
不易优化，等待时间可能由其他系统间接影响所致，任务之间也可能由于争夺磁盘或者CPU使用权而互相影响。
通过性能剖析进行优化
性能剖析有俩步骤：一是测量任务所花费的时间，二是对结果进行排序，将重要的任务排在前面。
如果不能确定问题是出现在执行还是等待上，那么需要分析任务执行时间长是因为消耗了太多的资源且大部分时间花费在执行上，还是说任务一直等待，没有消耗什么资源。再具体分析什么任务执行时间长或是任务在什么地方阻塞的时间最长。
对应用程序进行性能剖析
对系统进行性能分析建议自上而下进行，这样可以追踪自用户发起到服务器响应的整个流程。
性能瓶颈可能有很多影响因素：
- 外部资源，比如调用了外部的web服务
- 应用需要处理大量的数据，比如分析一个超大的xml文件
- 在循环中执行昂贵的操作，比如滥用正则表达式
- 使用了低效的算法，比如暴力搜索算法来查找
剖析MySQL查询
这部分。。。。实际还是用druid连接池监控吧
诊断间歇性问题
单个查询问题还是服务器问题
- 首先要确认是单条查询问题还是服务器问题
- 使用show global status, 统计线程连接数和正在执行查询的线程数
- 使用show processList, 观察是否有大量线程处于不正常的状态或者有其他不正常的特征
- 使用查询日志分析
- 理解发现的问题
捕获诊断数据
- 诊断触发器
常见问题：
误报，收集了很多诊断数据，但期间并没有发生问题
漏检，问题出现时没有捕获到数据
- 触发器的标准: 找到能和正常时的阈值进行比较的指标，通常是一个计数，比如正在运行的线程的数量，处于’freeze items’状态线程的数量等。对于数据库，比如Thread_running的趋势在出现问题时比较敏感，没有问题则比较平稳；线程异常状态尖峰指标；show innodb status的特定输出，服务器的平均负载尖峰等。
- 阈值的选择：要在问题开始时捕获数据，若在系统崩溃时捕获，就很难诊断到真正的原因。举例，正常情况下并发数<10, 建议阈值可以设置为20, 且为了避免误报, 设置为thread_running连续5秒超过20，就开始收集诊断数据
- 可以选用一些工具，比如pt-stalk
- 尽可能收集所有能收集的数据
系统状态，CPU利用率，磁盘使用率和可用空间，ps的输出采样，内存利用率以及可以从mysql获得的信息。执行时间包括工作时间和等待时间。可以使用工具pt-collect
- 解释结果数据
- 检查问题是否真的发生了
- 是否有非常明显的跳跃性变化，查看异常的查询或事务的行为，以及服务器的内部行为
总结: 
若有收获，就点个赞吧
0 人点赞
