面对“系统变慢了”，最危险的做法是立刻猜磁盘、网络或某次发布。本章先给出一张全栈地图：请求从应用、运行库和系统调用进入内核，再经过 CPU、内存、文件系统、存储与网络；其中任何一层都可能是原因，也可能只是受害者。性能工作的目标不是让某个数字看起来更漂亮，而是以可接受的成本改善用户可感知的延时、吞吐量和稳定性。

性能问题常有多个促成因素，也可能同时存在多个无关问题。因此调查必须先把主观抱怨改写成可验证的问题，例如“过去一小时，结账接口 p99 延时由 180 ms 升至 900 ms，错误率未变”。之后再用证据缩小范围，并量化某个发现对端到端时间究竟贡献多少。

1. 始终看全栈。 团队边界不等于数据路径边界；“数据库慢”可能源于内存竞争造成的缓存命中率下降。
2. 延时最适合量化影响。 把请求总时间拆开，可以估计移除某段等待后最多能获得多少收益。
3. 先观测，后实验。 计数器、剖析和跟踪通常不主动改变负载；基准测试会施加工作，生产环境中风险更高。
4. 平均值不代表每一次请求。 尾延时、异常值和多模态分布可能完全被平均数遮住。
5. 调查是闭环而非工具清单。 问题陈述、基线、假设、预测、测量、解释和复验缺一不可。

用户请求 → 应用/数据库 → 系统库与系统调用 → 内核 → 设备与硬件
             ↑ 工作负载分析              资源分析 ↑

问题陈述 → 建立基线 → 提出假设 → 观测/实验 → 量化影响 → 复验与记录

• 响应时间/请求延时：一次操作从发起到完成的时间。使用前必须说明测量边界，例如“TCP 连接延时”与“页面完整加载时间”不是同一个指标。
• 吞吐量：单位时间完成的操作数或传输的数据量。不要把当前测得的吞吐量误称为链路的理论带宽。
• 使用率：资源在观测区间内的繁忙程度，或容量资源已用比例。
• 饱和度：工作超过服务能力后排队或等待的程度。
• 错误：失败、超时、重试、降级等事件；可恢复错误也会消耗资源并拉高延时。

固定计数器适合回答“发生了多少、平均如何”；剖析通过采样回答“CPU 时间大致花在哪里”；跟踪记录感兴趣的单个事件，能回答“这一次发生了什么”，但事件频率越高，开销越需要评估。

1. 把问题写成“对象 + 指标 + 时间范围 + 对照组”，同时询问最近的软件、配置、硬件和负载变化。
2. 保存故障窗口与正常窗口的同口径数据，确认监测聚合周期，避免拿 5 分钟均值解释 1 秒尖峰。
3. 在最初一分钟做只读概览：负载趋势、内核错误、运行队列、各 CPU、进程、磁盘、内存和网络。
4. 用工作负载视角确认请求率、请求类型和来源是否变化；用资源视角检查 CPU、内存、存储和网络是否使用、排队或报错。
5. 选择最能证伪当前假设的下一项测量。若认为磁盘拖慢请求，要证明请求确实同步等待磁盘，而不只是同时看到磁盘繁忙。
6. 修复或回滚后重复同一测量，并记录命令、版本、时间范围和结论，避免只凭“感觉恢复”。

下面是书中 Linux 60 秒检查表的校正版，均为读取或观察；持续命令用 Ctrl+C 结束：

uptime
dmesg -T | tail
vmstat -SM 1
mpstat -P ALL 1
pidstat 1
iostat -sxz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

dmesg 在受限系统中可能被拒绝；mpstat、pidstat、iostat 和 sar 通常来自 sysstat 包。不同发行版和 sysstat 版本的列名、单位及选项可能不同，应以本机 man 页为准。若只需一次非交互快照，可用 top -b -n 1。在生产环境不要顺手运行压力工具；先记录现状，再决定是否在隔离测试环境做实验。

• uptime 的 1、5、15 分钟负载均值只用于看趋势；Linux 负载还可包含不可中断睡眠任务，不能直接等同于 CPU 使用率。
• vmstat 关注 r、us、sy、id、wa、si/so。通常第一行混有自启动以来的累计均值，判断当前行为应看后续间隔行。
• mpstat -P ALL 1 能发现“整体不忙、单核跑满”的线程扩展问题；同时区分用户态、内核态、中断和虚拟化偷取时间。
• pidstat 1 找出 CPU 消费者，并比较用户时间与系统时间。进程使用率高只是线索，下一步通常是剖析代码路径。
• iostat -sxz 1 同看 IOPS、吞吐量、等待时间、队列和忙碌度；100% 忙碌不必然等于设备已达最大容量。
• sar -n DEV 1 看接口包速率和吞吐量，sar -n TCP,ETCP 1 看连接与重传。重传增加比单纯吞吐量高更接近故障线索。

1. 先入为主地责怪某一团队。 相关性和时间重合不能证明因果。
2. 只看平均延时。 少量慢请求可能决定用户体验，应补充分位数、直方图和最大值。
3. 把高使用率直接判为故障。 CPU 高使用率可能只是有效工作；要结合队列、调度延时和业务延时。
4. 把 IOPS 降低当成优化。 操作数减少但单次 I/O 变大，实际字节量和延时可能更差。
5. 在生产机直接跑基准测试。 合成负载会争夺资源并改变被测系统，测试结果还可能受负载生成器自身限制。
6. 找到一个问题就停止。 先量化它对目标请求的贡献，再判断它是不是当前最重要的问题。

1. 为“网站很卡”写出一条可测量的问题陈述，并标明时间范围。
2. 解释计数器、剖析和跟踪分别适合回答哪一类问题。
3. 如果平均负载上升但 CPU 仍空闲，你会再查看哪两类证据？
4. 为什么磁盘与慢请求同时出现高峰，仍不能证明磁盘是根因？
5. 不看正文，按 CPU、内存、磁盘、网络的顺序说出 60 秒检查中的代表命令。

性能分析的第一原则是把模糊抱怨变成有边界的指标问题，再从工作负载与资源两个方向观察整条数据路径。延时分解有助于量化收益，观测工具适合作为生产环境的第一选择，实验则应控制变量并评估扰动。60 秒检查不是诊断终点，而是用最小成本为后续假设选择方向。