这一章在做什么

什么时候翻这一章

• 容器里的服务时不时卡几十毫秒，CPU 看着却不满多半是 CPU 限额在节流：配额在一个周期的前一小段就被几个线程用光，剩下的时间全体停着。§11.3.3§11.3.4场景手册 →
• 云主机里 vmstat 的 st 一直不为零你的虚拟 CPU 想跑却没轮到，时间给了邻居或宿主自己。客户机里能看到量，看不到原因。§11.2.4场景手册 →
• 容器里 free 说还有十几 GB，进程却被 OOM 杀了free 报的是宿主的内存；容器的上限在 cgroup 的 memory.max 里。§11.3.3场景手册 →
• 容器里 uptime、iostat 显示很忙，自己的服务却闲着这些工具读的是整台宿主，算进了别的租户。§11.3.4
• 测试时很快，上线和别的服务挤在一起就慢了几倍测试时在空机器上「借」了闲置 CPU，上线后借不到了。份额只保证下限。§11.3.3
• 在宿主上排查某个容器或虚拟机怎么把容器里的 PID 对到宿主上，怎么进它的命名空间跑工具，虚拟机的退出原因怎么看。§11.2.4§11.3.4

这一章不讲新的资源，讲的是第 6–10 章的方法搬进虚拟化环境以后哪里要改。USE 方法要把每一种限额当成一种资源来查（§2.5.9）；CPU 那一章的 steal（§6.6.2）、限额（§6.9.8）在这里展开。

先用中文过一遍

三种虚拟化，差在有几个内核

硬件虚拟化给每个客户机一台「假电脑」，客户机跑自己的内核；容器只有一个内核，靠内核把进程分成几组、互相看不见；轻量虚拟机（MicroVM，书里以 Firecracker 为例）还是一客户机一内核，但虚拟机管理程序（hypervisor）做得很小，启动快、占内存少。

有几个内核，决定了两件事。一是开销：虚拟机里用户态代码直接在 CPU 上跑，开销主要出在特权操作、内存地址的二次翻译和 IO 上，有硬件支持后已经很小；容器在 CPU 和内存上没有额外开销，代价是大家挤同一个内核里的锁、缓存和队列（§11.2.2、§11.3.2）。二是谁看得清：虚拟机的用户有自己的内核，perf、BPF 都能用，但看不到宿主；容器的运营方在宿主上什么都看得见，容器里的用户却多半用不了内核跟踪工具（§11.6）。书里点出的尴尬是：从虚拟机搬到容器，更容易撞上内核里的争用，同时失去查它的手段。

steal：虚拟 CPU 想跑却没轮到

虚拟机里的 CPU 是虚拟 CPU（vCPU），由宿主调度到物理 CPU 上。宿主把这颗物理 CPU 给了别的客户机，或者拿去处理 IO、执行实例类型的限额，你的 vCPU 就得等。客户机内核把这段时间记成 steal（被偷走的时间），vmstat 的 st、mpstat 的 %steal 就是它（§11.2.4）。书里说这是少见的「知道自己被虚拟化了」的指标。

读它要注意两点。第一，它只告诉你被拿走了多少，不告诉你被谁拿走：客户机看不到邻居，原因得问云厂商或者换实例。第二，它在客户机里算，以 KVM 为例，记的是 vCPU 有活要干、却没被宿主调度的时间；vCPU 自己闲着时，宿主拿走它不算 steal。所以 steal 高说明「你想要的 CPU 没给足」，和利用率、排队一起看才完整。

容器：命名空间管看见什么，cgroup 管用多少

Linux 内核里没有「容器」这个东西。Docker 之类的软件用两样内核功能拼出容器：命名空间（namespace）决定一组进程能看见什么（自己的进程号、挂载点、网卡、主机名），控制组（cgroup）决定它们能用多少（CPU、内存、IO、进程数）。所以容器里的 1 号进程在宿主上是另一个 PID，宿主上用 grep NSpid /proc/PID/status 能看到两边的对应（§11.3.1、§11.3.4）。

这两样东西分开做，留下了这一章最大的坑：很多统计并没有按命名空间隔离。/proc 下的 stat、meminfo、loadavg 在常见配置下仍是整台宿主的数，于是容器里的 top 头部、uptime、free、vmstat、mpstat、iostat 报的都是宿主；ps、pidstat 只列容器自己的进程，因为 PID 命名空间隔离了进程表。本站实测：在一个限了半个 CPU、256 MB 内存的 cgroup 里，nproc 仍然说 16，free 仍然说有 11 GB 可用。用这些数给线程池、缓存定大小，就会定错。

真话在 cgroup 的目录里。cgroup v2 下，cat /proc/self/cgroup 给出自己所在的路径，前面加上 /sys/fs/cgroup 就是目录：cpu.max 是 CPU 限额，cpu.stat 是用量和节流，memory.max、memory.current 是内存的上限和当前用量。

CPU 限额：配额、周期和节流

cgroup 管 CPU 有三种手段（§11.3.3）。cpuset 把整颗 CPU 划给容器，稳定但闲着也不让别人用。份额（v1 叫 shares，v2 叫 weight）只在大家都抢的时候按比例分，没人抢时可以「借」闲置的 CPU，这叫突发（bursting）。带宽限额是硬上限：每个周期（默认 100 ms）给一份配额，用完就停到下个周期。cgroup v2 里写成 cpu.max 的两个数，200000 100000 就是每 100 ms 给 200 ms，相当于两颗 CPU。

配额是所有线程合用的。一个有 4 个线程的服务，限额一颗 CPU：4 个线程在 4 个核上同时跑，25 ms 就把 100 ms 的配额花完，然后全体停 75 ms。平均下来它确实只用了一颗 CPU，可每个请求都可能撞上一次 75 ms 的停顿。这时宿主上大半的核空着，mpstat 一切正常；只有 cpu.stat 里的 nr_throttled（被掐的周期数）和 throttled_usec（被掐的时间）在涨。下面「动手」一节量出的就是这个数。

内存限额：上限之内，page cache 也算

虚拟机的内存是配置时定死的，客户机内核自己在这个范围里换页、回收。容器则由 memory cgroup 管：容器读写文件产生的 page cache 记在容器名下，不用另外设置（§11.3.3）。cgroup v2 里 memory.max 是硬上限，用量回收不下来就在这个 cgroup 里触发 OOM；memory.high 是软一些的线，超过后进程被放慢、被迫回收。

读数时要分清两种内存：memory.stat 里的 anon 是堆和栈，回收它只能换出；file 是 page cache，大多可以直接丢。memory.current 贴着 memory.max 不一定危险，可能只是缓存把空间用满了；危险的信号是 memory.events 里 max、oom_kill 在涨，或者 anon 一路长。

方法：按什么顺序查

书里的原则只有一句：限额比物理上限先到，所以先查限额（§11.3.4）。宿主运营方和容器用户都该这么做；USE 方法把每一种限额当作一种资源，查它的利用率、饱和度和错误（§2.5.9）。落到一次排查上，本站整理成下面几步，前三步在容器或客户机里就能做，不要 root。

1. 我在哪种环境里？

   systemd-detect-virt 说出是哪种虚拟机或容器；lscpu 的 Hypervisor vendor 一行；cat /proc/self/cgroup 给出所在的 cgroup，只有一行 0::/… 就是 cgroup v2。环境不同，下面能信哪些数也不同。§11.2.4§11.3.4

2. 有哪些限额？

   在自己的 cgroup 目录里读 cpu.max、cpu.weight、cpuset.cpus.effective、memory.max、memory.high、pids.max。max 表示没限。把这些数记下来，后面所有利用率都按它算，而不是按 nproc 和 free。§11.3.3

3. CPU 是被限额掐住，还是被邻居挤了？

   隔几秒读两次 cpu.stat：nr_throttled 和 throttled_usec 在涨，就是带宽限额在节流。用了 cpuset，就看那几颗 CPU 是不是满了。都不是，而进程的 nonvoluntary_ctxt_switches（/proc/PID/status）在涨、宿主上没有空闲的 CPU，那是份额之争：别的租户也在抢。虚拟机里看 vmstat 1 的 st。§11.3.4§11.2.4

4. 内存离上限多远？

   memory.current 对 memory.max；memory.stat 里 anon 和 file 各多少；memory.events 的 max、oom_kill 有没有在涨；memory.pressure 给出因为内存而停顿的时间比例。§11.3.3§11.3.4

5. IO 和网络：先看延迟

   虚拟磁盘、虚拟网卡的「忙」不说明什么，因为你不知道背后是什么设备；看延迟。虚拟机里有自己的内核，可以用 BPF 工具逐个看 IO 的延迟，找出既不是因为 IO 大、也不是因为排在写回后面的离群值，那多半是物理上的争用。网络的限速常常只有宿主或云厂商的接口看得到。§11.2.4

6. 到宿主上接着查

   能上宿主时：systemd-cgtop 按 cgroup 排出谁在用 CPU 和内存；grep NSpid /proc/PID/status 对上容器里外的 PID；nsenter -t PID -m -p top 进它的命名空间跑工具。KVM 的客户机在宿主上是 qemu 进程，pidstat -t -p PID 1 看每个 vCPU 线程，perf kvm stat live 看退出原因（要 root）。§11.2.4§11.3.4

工具速查

表里的 cgroup 文件都在自己的 cgroup 目录下（/sys/fs/cgroup 加上 /proc/self/cgroup 第三段），读它们不要 root；书里的例子是 cgroup v1 的文件名，对照见「成书之后」。systemd-cgtop、systemd-detect-virt、systemd-run 随 systemd 自带；nsenter、lsns 在 util-linux 里；vmstat 在 procps，mpstat、pidstat 在 sysstat。宿主上的 nsenter、perf kvm、读别的用户的 /proc 要 root。工具名链到本站的工具卡：vmstat、mpstat、systemd-cgtop、nsenter、lsns、perf、xentop。

动手：在自己的机器上试

// stall.c：N 个线程各自空转，记下两次读时钟之间最长停了多久
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static double now_ms(void) {
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec * 1e3 + t.tv_nsec / 1e6;
}

static void *spin(void *arg) {
    double start = now_ms(), last = start, worst = 0;
    long stalls = 0;                       // 停了 5 ms 以上的次数
    while (last - start < 3000) {          // 跑 3 秒
        double t = now_ms();
        if (t - last > worst) worst = t - last;
        if (t - last > 5) stalls++;
        last = t;
    }
    printf("thread %ld: longest stall %.1f ms, stalls>5ms: %ld\n",
           (long)arg, worst, stalls);
    return NULL;
}

int main(int argc, char **argv) {
    int n = argc > 1 ? atoi(argv[1]) : 4;
    pthread_t th[32];
    if (n < 1 || n > 32) n = 4;
    for (long i = 0; i < n; i++) pthread_create(&th[i], NULL, spin, (void *)i);
    for (int i = 0; i < n; i++) pthread_join(th[i], NULL);
    return 0;
}

$ gcc -O2 -pthread stall.c -o stall
# 不限额，作对照
$ ./stall 4
# 放进一个限额 1 颗 CPU 的临时 cgroup 里跑，跑完读它的 cpu.stat
$ systemd-run --user --scope --quiet --expand-environment=no -p CPUQuota=100% sh -c './stall 4; cat /sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup)/cpu.stat'

不限额：  thread 0: longest stall 1.9 ms, stalls>5ms: 0
限额后：  thread 0: longest stall 80.0 ms, stalls>5ms: 31

usage_usec 3111431
nr_periods 31
nr_throttled 31
throttled_usec 9037843

$ systemd-run --user --scope --quiet --expand-environment=no -p CPUQuota=50% -p MemoryMax=256M sh -c 'nproc; free -m; C=/sys/fs/cgroup$(cut -d: -f3 /proc/self/cgroup); cat $C/cpu.max $C/memory.max'
# 对照：nproc 认 CPU 亲和性（cpuset 就是靠它）；本站的 coreutils 9.7 不认配额
$ taskset -c 0,1 nproc

nproc：      16
free：       total 14874   available 11713   (MB)
cpu.max：    50000 100000
memory.max： 268435456
taskset 后：  2

成书之后

分节地图

这一章先铺背景（§11.1），再把三种虚拟化各按「实现、开销、资源控制、可观测性」四节走一遍（§11.2–11.4），最后是别的形态和一张对比。先读的是容器那一半：资源控制和可观测性两节最长，也是「指标看不准」的答案所在。虚拟机的 steal、宿主上的工具在 §11.2.4，云主机用户用到时再查。

1. The rise of cloud computing solves…约 400 词开篇学习目标和四个部分，以及三种虚拟化在云上普及的先后。
2. Background约 300 词背景宿主、客户机、租户、多租户这几个词怎么用。
3. Instance Types约 200 词实例类型云厂商的实例家族和规格，名字会过时，看厂商文档即可。
4. Scalable Architecture约 300 词可扩展的架构纵向和横向扩展的架构常识，和单机排查关系不大。
5. Capacity Planning约 800 词容量规划自动伸缩会掩盖性能退化；突发是什么。
6. Storage约 200 词存储云上的网络存储为什么比本地盘难预测。
7. Multitenancy约 200 词多租户吵闹的邻居，和两种对策：资源控制与可观测性。
8. Orchestration (Kubernetes)约 400 词编排（Kubernetes）Pod、Node、Service 的关系；调度和网络是两大性能问题。
9. Hardware Virtualization约 700 词硬件虚拟化两种管理程序配置；二进制翻译、半虚拟化、硬件辅助的演进。
10. Implementation约 400 词实现VMware、Xen、Hyper-V、KVM、Nitro 的来历，排查用不上。
11. Overhead约 1800 词开销CPU、内存映射、内存、IO、多租户争用各自的开销从哪来。
12. Resource Controls约 900 词资源控制vCPU、缓存划分、气球驱动；客户机内的优先级宿主看不见。
13. Observability约 1900 词可观测性宿主上看 vCPU 线程和退出原因，客户机里看 steal 和设备延迟。
14. OS Virtualization约 500 词操作系统虚拟化容器比虚拟机好在哪、差在哪；前两条缺点要合起来读。
15. Implementation约 400 词实现命名空间和 cgroup 各管什么；内核里没有容器这个概念。
16. Overhead约 700 词开销CPU 和内存没有额外开销；IO 多几层；主要问题是多租户争用。
17. Resource Controls约 1300 词资源控制优先级和上限两类；CPU 的 cpuset、份额、带宽怎么配合。
18. Observability约 3400 词可观测性容器里的工具报谁的数，宿主上怎么按容器查，节流怎么判断。
19. Lightweight Virtualization约 300 词轻量虚拟化MicroVM 想兼得虚拟机的隔离和容器的轻快。
20. Implementation约 200 词实现几个项目的来历和启动时间，名单会变。
21. Overhead约 100 词开销和 KVM 相近，内存占用小得多。
22. Resource Controls约 100 词资源控制管理程序是宿主上的进程，用宿主的 cgroup 管。
23. Observability约 300 词可观测性宿主上整台虚拟机只是一个进程；客户机里的统计只算自己。
24. Other Types约 300 词其他形态函数即服务、SaaS、Unikernel：没有可登录的系统时怎么分析。
25. Comparisons约 300 词比较一张对比表；可观测性对运营方和用户各偏向哪种技术。
26. Exercises约 200 词习题习题；本页的动手和诊断题可以代替。

词与短语

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

§11.1.3 Capacity Planning

§11.1.5 Multitenancy

§11.1.6 Orchestration (Kubernetes)

§11.2 Hardware Virtualization

§11.2.2 Overhead

§11.2.3 Resource Controls

§11.2.4 Observability

§11.3.1 Implementation

§11.3.2 Overhead

§11.3.3 Resource Controls

§11.3.4 Observability

§11.6 Comparisons

诊断题：换成你来查

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

cpu.max:   200000 100000
cpu.stat:  nr_periods    1200  →  1300
           nr_throttled   410  →   497

 r   us  sy  id  wa  st
 6   48   9   3   0  40
 5   45  10   2   0  43

memory.max:      1073741824
memory.current:  1052000000
memory.stat:     anon 210000000
                 file 820000000
memory.events:   max 0   oom_kill 0

uptime:    load average: 31.2, 29.8, 27.5
cpu.stat:  usage_usec  +40000 in 10s
           nr_throttled  +0

cpu.max:       max 100000
nr_throttled:  0
node %idle:    0.5

值得停下来的句子

Since these limits, where present, are encountered long before the physical limits, they are more likely to be in effect and should be checked first.— §11.3.4。本站译：这些限额只要存在，就会远比物理上限先撞上，所以更可能正在起作用，应该先查。

前面十章教的都是物理资源：CPU 满没满、磁盘忙不忙。到了容器和云主机里，这些检查依然要做，但顺序要倒过来。一个限了 2 颗 CPU 的容器跑在 64 核的宿主上，物理 CPU 用到 3% 时它就到顶了；看 mpstat 永远看不到问题。先读 cpu.max、memory.max，再按它们去算利用率，本页「方法」的第二步就是这么来的。

This can lighten the support burden on container operators: people tend to blame what they cannot observe.— §11.3.4。本站译：这能减轻容器运营方的支持负担：人总爱把问题怪到自己看不见的东西上。

这句话说的是让容器看到宿主统计的好处，但反过来也是给排查者的提醒。看不见宿主，就容易把一切慢都推给「吵闹的邻居」；看得见宿主，又容易把宿主的数当成自己的。两种错都来自同一件事：没弄清手上这个数是谁的。每读一个指标，先问它的范围是整台机器、这个 cgroup，还是这个虚拟机。

带走的几条

一句话：先弄清手上的数是谁的，再先查限额、后查物理资源。