linux大神Brendan Gregg 性能之巅 第二版（systems performance）阅读心得（第二章）

2.1 术语

        主要介绍了一些操作系统运维常用的名词，IOPS、吞吐量、延时等，后面都会进行分析。

2.2 模型

        受测系统、排队系统，一些概念，简单看看即可。

2.3 概念

        对2.1中的术语进行解释。

2.3.1 延时

        延时是实际操作执行之前花费的等待时间，不包括操作执行的时间，比如访问网站会发起一次tcp连接，DNS解析、tcp握手都属于传输数据之前的延时，而开始数据传输后属于操作时间。从点击网址到打开网页这段时间叫做响应时间，响应时间包含了延时和操作时间。

        当然，我们在平常工作中可能并不会分得这么细，把等待的总时间都叫做延时，所以在和别人交流时如果能大概判断到瓶颈所在，最好加上限定词，比如TCP连接延时，IO请求延时。

2.3.2 时间量级

        这一节给了一个有趣的表，列出了从1个CPU周期开始到重启物理系统的各种时间的绝对和相对时间比例。加入1个CPU周期对应1秒，那访问内存相当于6分钟，访问固态硬盘9~90个小时，机械硬盘1年，而重启一次物理服务器相当于32000年。

2.3.3 权衡

        性能、及时性、成本只能选择两个。

2.3.4 调优的影响

        性能调优越靠近工作执行的地方效果最显著。从应用程序-数据库-系统调用-文件系统-存储，自上而下，越上层调优效果越显著。比如数据库加个索引可能提升10倍性能，而对存储层级的调优对应用程序性能的提升只能达到百分比级。

        “操作系统的性能分析能辨别出来的不仅是操作系统层级的问题，还有应用程序层级的问题，某些情况下，甚至比从应用程序视角观测还简单。”  比如网站查询比较慢，可能查应用日志只能看到一些timeout的记录，但从操作系统的性能指标，比如cpu、io、内存等方面来观测更直观，但根本的问题可能只是程序写得不合理，而不是cpu性能不足。

2.3.5 合适的层级

        公司管理相关，看看就行

2.3.6 何时停止分析

        提示大家性能分析是没有边界的，只要你想，总能再优化一点。但也要考虑投入与回报的平衡。比如有些系统面向的用户比较局限，即使慢一点也没关系，而有些业务对实时性要求很高，在实际工作中就需要根据业务情况有所取舍。

2.3.7 性能推荐的时间点

        感觉是在讲性能调优的方法有时效性和针对性？不能把网上找到的调优参数直接用到自己的系统上，要自己辨别。

2.3.8 负载和架构

        如果对架构的分析显示只是工作任务在排队，处理任务没有任何问题，那么问题可能出在施加的负载太多上。此时可以引入更多的应用节点来均衡负载。

        比如写了一个单线程程序，只在一个CPU上忙碌，而其他CPU都是空闲的，这就是架构问题，而如果一个多线程程序在每个CPU上都忙碌，就是负载问题。

2.3.9 扩展性

        随着负载的增长，吞吐量等性能指标都会出现拐点，可能发生在某个组件达到饱和点时，比如内存、磁盘io等。

2.3.10 指标

        常见的性能指标：吞吐量、IOPS、使用率、延时。

        观察者效应：收集这些性能指标也是会消耗系统资源的，可能会加剧系统的卡顿。比如当CPU使用率高时，windows打开资源监视器可能会卡死。

        指标可能并不准确，有时在某个版本有效，随着技术进步反而在今天会造成误导。比如linux中的util指标。

2.3.11 使用率

        使用率可以是基于时间的，也可以是基于容量的。

        基于时间的：观测周期内的资源繁忙时间，比如CPU，磁盘io等。

        U=B/T  U：使用率   B：T时间内资源在工作的时间   T：观测周期

       但对于一些并行组件，使用率高并不能证明出现了瓶颈， 以磁盘io举例，类比大楼电梯，电梯可能一直在运行，但里面的乘客可能并不多，到了指定的楼层后，乘客并不用排队上电梯。

        存储阵列通常运行在100%使用率状态，因为其中某些磁盘在100%忙碌时，阵列中依然有足够的空闲磁盘来接受更多工作。

        基于容量的：字面意思。

        比如磁盘、内存的使用率，满了就会影响系统运行。

2.3.12 饱和度

        组件能提供的资源处理能力上限，达到饱和度就会排队。

2.3.13 剖析

        可视化分析。

2.3.14 缓存

        缓存就是将较慢的存储层的结果放在较快的存储层中，根据最近最常使用算法决定哪些数据要放在缓存里。比如，内存就是CPU和磁盘之间的缓存。

        因为较快存储容量一般比较慢存储小很多，所以缓存的一个重要指标是命中率，并且性能随命中率呈指数增长。98%和99%之间的性能差异要比10%和11%之间的性能差异大很多。

        除了命中率还需要关注失效率，如果缓存失效速度很快，即使命中率高性能也会很低。

        缓存的热冷温

        冷：缓存中有效数据是空的，命中率为0

        温：填充了有效数据，但还没达到预想的高度

        热：填充的都是有效数据，并且有很高的命中率，超过99%

2.3.15 已知的未知

        已知的已知、已知的未知、未知的未知。简单来说就是：“你知道的越多，你不知道的也就越多”，这句话很有道理，当你知道的很少时，你甚至意识不到还有很多未知。学得东西越多，接触的面越广，就会发现要学的知识还有很多。

2.4 视角

        面对性能问题，系统运维和应用程序运维往往会从不同的视角去进行性能分析，系统工程师会先检查平台、服务器、cpu内存io等底层资源情况，再进一步向上排查。而应用工程师则会先去查应用日志、数据库日志来确定应用程序问题。

2.5 方法

2.5.1 街灯讹方法

        “警察看到醉汉在路灯下找东西，就问他在找什么，醉汉回答钥匙丢了。警察帮着找了找也没找到，就问他确定是在灯下丢的吗？醉汉说：不，但这儿的光是最亮的。”

        故事挺有意思的，有些linux新手遇到问题就执行top，只是因为他们只会top。

2.5.2 随即变动讹方法

        根据经验猜测问题存在的方向，然后做调整。比如网站访问慢，不管cpu、内存使用率高不高，先扩容观察观察再说。

2.5.3 责怪他人讹方法

        甩锅大法。

        “感觉是网络的问题，你们给查一下。”

        “可能是磁盘io性能不足，检查下存储性能吧。”

        不去研究性能问题，用这种方法的人把问题推到别人身上，当证明根本不是别人的问题时，这对其他团队的资源也是一种浪费。

        为了避免成为牺牲品，向指责的人要截图、日志，能直观地证明是我们的问题，而不是他们的无端臆想。

2.5.4 Ad Hoc核对清单法

        一个技术团队应该维护一个包含性能指标检查项目的清单，包含查询命令和建议范围和针对的优化建议。并且时常保持更新。

2.5.5 问题陈述法

        这个问题在实际工作中最常用，排查之前一定要跟客户或者应用维护人员确认清楚以下几个问题，可以帮助我们更快地定位性能问题的关键：

1、什么让你认为存在性能问题的？网页打开慢，用户登录慢，查询数据慢。。。

2、出现性能问题的时间，之前运行正常吗，是第一次使用吗？

3、最近有什么改动？升级、新业务？

4、其他人有影响吗，换台电脑、手机或者网络环境测试呢？

根据这些基本的提问，可以大概判断问题的方向。

2.5.6 科学法

        问题-假设-预测-测试-分析

        这是一个不断循环的过程，因为一般不会一次假设就定位到问题所在。

2.5.7 诊断循环

        假设-检验-数据-假设

        基于每次检验的结果来修正假设

2.5.8 工具法

        可以用工具进行批量巡检，比手动一台一台上去用命令看快得多。

        常用的工具Prometheus、zabbix、ansible

2.5.9 USE方法

        USE:ultilization、saturation、error

        对于所有的资源，查看使用率、饱和度和错误来识别系统瓶颈。

        先看报错，再查达到饱和度的资源，再检查使用率（从易到难）

        常用的监控软件汇总的使用率最低的时间间隔是5分钟的平均值，但一秒内CPU就可能会有很强烈的起伏，所以监控值并不能体现出某一时间点的性能情况。这时候操作系统、应用程序中的错误日志就很重要。