《linux性能优化》第一章 性能追踪建议

1.1 记录在大量的笔记，在发生性能问题时，尽可能的记录所有的情况，对当时执行的命令和结果进行记录，避免重复执行

一般的系统性能问题都反映在cpu、内存、磁盘上面，所以需要对相关联的信息进行确认，在排队问题时具有指导价值，同时还应该关注系统日志

对于执行的所有命令最好进行记录

个人能力不足，无法确认问题，对网上查到的相关资料也需要进行记录和保存

通过记录的所有结果进行回顾整个过程，来排除旧的信息

定期回顾笔记来获取新的想法

1.2 自动执行重复任务

通过shell或程序来进行性能工具调用，减少复制粘贴的过程

应用程序测试，也最好进行脚本化操作，多次执行时减少错误

1.3 尽量选择低开销工具

1.4 选择多个工具来确定问题所在，对于工具的选择要有怡人性，第一个来说明方便使用，对系统影响最小，最好系统自带的，有些工具虽然是好用，但是需要编译使用，那就影响了性能处理的时间，SLA时间也会相应延长；第二个方面是对系统的侵入性较小，工具最好统计的信息接近实时，性能问题往往出现的只是有某些情况下才出现的，所以即时的信息比较容易直接定位到性能所在位置

2.1 找到性能指标、基线和目标

性能指标：也就是性能测试的结果，比如说你的网站要求性能指标需要达到请求数

基线：简单地说就是当前系统运行的状态，是否与性能指标的值相接近，如果达不到性能指标，就需要进行性能优化了

目标：当确认了指标和基线后，就需要确认一个目录，这个目标是我们如何达到指定的需求，以提升更好的性能

如何确认一个性能目标呢？

一个寻找相同配置的人，咨询性能指标，但是这个东西不太可靠，每个人的运行环境不同，无法适用于每一个场景，就像平时在百度上的结果，直接让人想吐🤮

查找工业标准测试程序的结果，这些也只是一个参考结果，但是可信度较高，可以进行参考。

我们平时处理问题时，一般只会去处理当前面临的问题，而不会深入去考虑后续是否会再生，只是形成了一个大致的看法，应该需要更深入的研究，尽可能全面的分析问题，提交给对人员进行确认和处理

2.2 各种搜索及反馈方法

 百度、google 百度，我现在认为已经不是一个搜索引擎了，出来的结果不尽如人意，我最爱的是快照功能；Google的话，需要条件，你懂的，也是锻炼英语的好机会

应用程序、开发人员邮件列表上求助，这个东西现在几乎很少用了，现在github已经解决了所有了

公司内部的产品则需要与开发人员进行沟通，进行问题确认

3.1 启动性能调查

分离问题

利用系统差异发现原因

一次只改变一件事

优化后重新测试

3.2 所有的事情记录记录再记录