这一章在做什么

什么时候翻这一章

• 刚拿到这本书，想知道哪一章管什么这一章几乎每一节都在给后面的章指路；上面的图和下面的表是本站按问题整理的对照。§1.1§1.7
• 接到一句「某某很慢」，不知道从哪下手先把问题问清楚，再把每种资源扫一遍，看哪里可疑。§1.5.1§1.10.1§1.11.1场景手册 →
• 想判断一项优化值不值得做用延迟算出这一项最多能带来多少加速，再决定排在第几。§1.5.4§1.6
• 在生产机上排查，拿不准该先看还是先压观测和实验各管什么，各有什么代价。§1.7§1.8场景手册 →
• 新版本上线前，想确认没有变慢第二个案例演示了非回归测试，以及压测时瓶颈跑到了压测客户端上。§1.11.2场景手册 →

这一章只开头，不展开。按问题找章，可以用这张表（本站整理，不是书里的）：

先用中文过一遍

延迟：能直接换算成「最多快多少」

一个成熟的系统里，已知没修的性能问题往往有一堆（§1.5.4）。难的不是找到一个问题，而是挑出影响最大的那个，这就要把每个问题量化。延迟（latency）是等待花掉的时间：一个请求、一次查询、一次文件读，都有自己的延迟。它好用在于能拆、能相减：知道一个请求的时间里有多少花在某件事上，就能算出把这件事完全去掉，最多能快几倍（§1.6）。

拿本站下面「动手」里的小程序说：每个请求约 20 毫秒，其中 6 毫秒在 CPU 上算，14 毫秒在等后端。把计算优化到快一倍，只省 3 毫秒，整体快 1.18 倍；等待减半，快 1.5 倍；等待全部消掉，上限是 20 ÷ 6 ≈ 3.3 倍。别的指标给不出这种结论：IOPS 降了一半，可能是好事，也可能只是每次 IO 变大了。还有两点要记住：延迟要带限定词，「网络延迟」可以指建连接的时间，也可以指整个请求的时间，书里会写成连接延迟、请求延迟；很多地方只给平均延迟或者根本不给，BPF 工具可以在任意位置量，并给出完整分布。

延迟好不好，本身没有标准答案：平均 1 毫秒的磁盘 IO，对一个服务可能很快，对另一个可能太慢（§1.5.1）。把「慢」变成能检查的事，要先定目标，比如平均响应时间不超过多少，或者百分之多少的请求要落在某个延迟以内。

观测和实验：两只手

观测（observability）是靠「看」来理解系统，不改变它的负载。看的手段有三种。计数器（counter）是内核和应用里一直在累加的整数：操作次数、字节数、错误数。工具隔一段时间读两次相减，算出速率、平均值、百分位，这叫统计（statistic）；挑出来长期记录、画曲线、设告警的统计叫指标（metric）。计数器便宜、一直开着，但常常只能告诉你「CPU 或磁盘有问题」，说不出为什么（§1.7.1）。剖析（profiling）是定时采样，比如每秒打断几十次、记下正在跑的代码，拼出一张粗略的画像；最常见的是 CPU 剖析，画成火焰图。作者认为在指标之外，CPU 火焰图帮人找到的改进比任何工具都多，而且锁的自旋、过多的 malloc 这类问题也会在火焰图里留下 CPU 的痕迹（§1.7.2）。跟踪（tracing）是把每一个事件都记下来，或者当场汇总，三种里最细（§1.7.3）。

实验（experimentation）是自己施加一个人造的负载，量系统的反应，也就是基准测试。宏基准（macro-benchmark）模拟真实的客户端请求；微基准（micro-benchmark）只测一个部件，比如磁盘或网络，通常更容易重复、也更容易弄懂。实验的长处是负载固定：线上的流量每秒都在变，固定负载把这部分波动去掉，剩下的波动（比如吞吐忽高忽低分成两档）就显出来了。它的代价是会和真实负载抢资源，所以书里的建议是：生产环境先用观测工具，空闲的测试机可以先压测摸清硬件的底（§1.7、§1.8）。只用观测也不对：工具太多，挨个看可能花几个小时，换成一个实验也许更快就有答案。

跟踪：静态插桩、动态插桩和 BPF

跟踪要先有「插桩点」，事件发生时才有东西可记。静态插桩（static instrumentation）是写在源码里的固定点：内核里叫跟踪点（tracepoint），磁盘 IO、调度、系统调用都有；用户态程序和库里的叫 USDT。像代码里预先埋好的日志语句，位置是写代码的人定的。动态插桩（dynamic instrumentation）是在程序跑起来以后，改内存里的指令插进一段例程，像调试器下断点，只是执行完例程就接着跑，不停下来。对 C/C++ 程序员来说，相当于不重新编译、在线上进程任意一个函数里临时加一行 printf。Linux 内核里的这项能力叫 kprobes，2004 年开始合入（§1.7.3）。

BPF 原本是给 tcpdump 加速过滤表达式的内核小虚拟机，2013 年起扩展成通用的内核执行环境，保证安全，访问数据又快。它让 BCC 和 bpftrace 这两套前端可以「编程」：在任意插桩点上写一小段逻辑，在内核里直接汇总成直方图、计数。书里很多工具（比如抓短命进程的 execsnoop）都是 BCC 工具。这些工具都要 root；BPF 本身在第 3 章讲（§3.4.4），插桩点的原理在第 4 章（§4.3.5–§4.3.8），用法在第 15 章。

头一分钟：先问清楚，再把资源扫一遍

没有方法的排查像钓鱼：随便试，指望碰上（§1.10）。第一步是把「慢」落到实处。工单上写「磁盘慢」，可能只是有人在监控上看见磁盘很忙；应用到底有没有变慢、用什么量的、变慢前动过什么，都要先弄清。书里第一个案例就是先问了几个问题，才发现最初的怀疑很可能只是猜测（§1.11.1；怎样把问题问清楚，见 §2.5.5）。

第二步是在几分钟里把每种资源各看一眼，先排除掉一大片。书里 §1.10.1 给了一张十条命令的检查表，每条都指到详细讲它的那一节，值得在自己的机器上照着跑一遍。本站按要回答的问题换一种排法，顺带补上书外的 PSI：

• 有没有哪种资源让任务在等？内核 4.20 以后（还要编译时开了 PSI）有压力停顿信息：/proc/pressure/ 下的 cpu、memory、io 这几个文件，各给出最近 10、60、300 秒里有任务因为这种资源而停顿的时间比例，一眼就能看出往哪边查（PSI，§7.5.2）。
• 是谁在用？pidstat 或 top 按进程列出 CPU，看有没有不该出现的进程（§6.6.7）。
• CPU 是整体不够，还是一个核满了？mpstat -P ALL 1 逐核看；平均值很低、某个核 100%，多半是单线程到顶了（§6.6.3）。
• 磁盘忙不忙、排不排队？iostat -xz 1 看利用率和平均等待（§9.6.1）。
• 内存紧不紧？free 看 available，别被 buff/cache 吓到；vmstat 的 si、so 不为零就是在换页（§7.5.1）。
• 网络有没有重传？nstat 或 sar 的网络选项看吞吐和 TCP 重传（§10.6.4、§10.6.6）。
• 内核有没有报错？dmesg 里找 OOM 和 IO 错误，错误比慢更该先处理。

两点提醒。监控面板上有同样的数，看面板也行，但监控常常一分钟一个点，会把几秒的突发抹平：书里的案例里，监控说磁盘 80%，按秒看却是经常顶到 100%、开始排队。扫完这一遍，你只知道哪种资源可疑，还不知道为什么；接下来按第 2 章的 USE 方法（§2.5.9）把每种资源查完整，再往下钻（§2.5.12），去对应资源那一章用剖析和跟踪找原因。

动手：在自己的机器上试

// req.c：假装处理 50 个请求。每个请求先在 CPU 上算一会儿，再等一会儿（假装在等数据库）
#include <stdio.h>
#include <time.h>
#ifndef WORK
#define WORK 8500000       // 计算量：本站的 WSL2 上大约 6 毫秒
#endif
#ifndef WAIT_MS
#define WAIT_MS 14         // 每个请求等多少毫秒
#endif

static volatile unsigned sink;

static void compute(long n) {                 // 在 CPU 上
    unsigned s = 0;
    for (long i = 0; i < n; i++) s = s * 31 + (unsigned)i;
    sink = s;
}

static void wait_backend(long ms) {           // 不在 CPU 上，只是等
    struct timespec ts = { 0, ms * 1000000L };
    nanosleep(&ts, NULL);
}

int main(void) {
    for (int id = 0; id < 50; id++) {
        compute(WORK);
        wait_backend(WAIT_MS);
    }
    printf("done %u\n", sink);
    return 0;
}

# 先观测：real 是墙上时间，user + sys 是在 CPU 上的时间
$ gcc -O2 req.c -o req
$ time ./req
# 再实验：计算减半、等待减半，各编一份
$ gcc -O2 -DWORK=4250000 req.c -o req_cpu
$ gcc -O2 -DWAIT_MS=7 req.c -o req_wait
$ time ./req_cpu
$ time ./req_wait

req:       real 0.988s   user 0.284s   sys 0.000s
req_cpu:   real 0.851s   user 0.146s   sys 0.000s
req_wait:  real 0.655s   user 0.297s   sys 0.004s

成书之后

分节地图

这一章是全书的导览，每一节都短，结尾是两个虚构的案例。先读的是讲延迟、观测和实验、头 60 秒清单的几节，它们是后面各章天天要用的基本功；性能为什么难、云计算、两个案例，想了解时再读。

1. Computer performance is an exciting, varied…约 100 词开篇四条学习目标，也就是这一章的目录。
2. Systems Performance约 200 词系统性能研究整条数据路径，书里的全栈一直到硬件；手边要有一张数据路径图。
3. Roles约 200 词角色谁在做性能工作、性能团队怎么分工；上手用不到。
4. Activities约 500 词活动从立项到上线的十项性能活动；金丝雀测试、蓝绿部署、容量规划在这里出现。
5. Perspectives约 100 词视角从负载往下看与从资源往上看，第 2 章展开。
6. Performance Is Challenging约 100 词性能为什么难四个原因的引子。
7. Subjectivity约 200 词主观性好不好取决于预期；怎样用目标把它变成能检查的事。
8. Complexity约 300 词复杂性没有明显的起点、连锁故障、瓶颈转移、线上负载在实验室复现不了。
9. Multiple Causes约 100 词多个原因几件各自正常的事凑在一起才出问题。
10. Multiple Performance Issues约 200 词多个性能问题问题总有一堆，要量化，挑最要紧的。
11. Latency约 400 词延迟为什么延迟能估出加速比上限而 IOPS 不能；延迟要带限定词。
12. Observability约 100 词可观测性观测和实验的分界；生产环境先用哪一种。
13. Counters, Statistics, and Metrics约 400 词计数器、统计和指标从计数器到告警的几层叫法；指标什么时候够用、什么时候只指方向。
14. Profiling约 300 词剖析采样画粗略画像；火焰图能从 CPU 的痕迹里看出哪些别的问题。
15. Tracing约 700 词跟踪静态插桩、动态插桩、BPF 的来历；细节在第 4、15 章。
16. Experimentation约 400 词实验宏基准和微基准；固定负载能显出什么；为什么两种工具都要用。
17. Cloud Computing约 200 词云计算按时计费让优化直接省钱；邻居干扰、看不见物理机。
18. Methodologies约 100 词方法论没有方法的排查是什么样子。
19. Linux Perf Analysis in 60 Seconds约 100 词Linux 性能分析的头 60 秒一张十条命令的检查表，每条指到详细讲它的节。照着跑一遍。
20. Case Studies约 100 词案例两个虚构的案例；作者说这只是一种做法。
21. Slow Disks约 900 词磁盘慢从问清问题、USE 扫资源到和同类机器对比，看方法怎么串起来。
22. Software Change约 800 词软件变更非回归测试：压测到顶、定速比资源消耗、找出真正的瓶颈。
23. More Reading约 100 词延伸阅读指向第 16 章和第 2 章，没有新内容。

词与短语

只收先读和用到再查两档的节。斜体那一行是原句里连续的几个词，在电子书里搜它就能找到那一句。

§1.1 Systems Performance

§1.3 Activities

§1.5.1 Subjectivity

§1.5.2 Complexity

§1.5.4 Multiple Performance Issues

§1.6 Latency

§1.7 Observability

§1.7.1 Counters, Statistics, and Metrics

§1.7.2 Profiling

§1.7.3 Tracing

§1.8 Experimentation

§1.9 Cloud Computing

§1.10 Methodologies

§1.11 Case Studies

§1.11.1 Slow Disks

§1.11.2 Software Change

诊断题：换成你来查

场景和输出都是本站编的。先自己判断，再点选项看解释。

parse_json    8 ms   (on-CPU)
mysql_query  30 ms   (waiting)
other         2 ms

        w/s
before  1200
after    150

%util   aqu-sz   r_await
 100     9.8      41.2
  12     0.1       0.6
 100    11.3      47.9
  10     0.1       0.5

target   achieved   server_cpu
10000      10000        16%
15000      15000        24%
20000      18100        29%
30000      18200        29%

值得停下来的句子

the real task isn’t finding an issue; it’s identifying which issue or issues matter the most.— §1.5.4。本站译：真正的活不是找到一个问题，而是认出哪一个或哪几个问题最要紧。

排查时最容易犯的错，是看到第一个「不正常」的数就认定是它。成熟的软件里本来就躺着一堆已知的性能问题，找到一个毫不稀奇。这句话把排查从「找问题」改成「排优先级」，而排优先级就要量化：这个问题让请求慢了多少毫秒、修好它最多快几倍。这也是为什么书里紧接着就讲延迟。

you have two hands, observability and experimentation. Only using one type of tool is like trying to solve a problem one-handed.— §1.8。本站译：你有两只手，观测和实验。只用一种工具，就像单手解决问题。

这是作者转述一位前辈工程师的比喻。只会看监控的人，可能在几十个工具之间转几个小时；只会压测的人，在生产机上会把现场搅乱。实际的节奏是交替的：观测给出假设，实验验证假设，再回到观测确认改动的效果。上面「动手」里的小程序就是这个节奏的缩小版。

带走的几条

一句话：先量化再动手：用延迟算出上限，生产上先观测，扫完资源再往深处钻。