波仔
🐧 第四章 进程调度器
📄 一句话概括

三个工具各管一段：time 给三行时间、perf stat 给指令与切换、/proc/stat 给整机账本。纪律三条：先预热、只改一个变量、重复取中位。

📝 本节和前面几节的关系

4.12 给了结论，这一节讲【这个结论在真机上怎么验证】——模拟能看规律，真机才能给绝对值。

一、time 的三行怎么读

real：墙上时钟，从命令开始到结束。这是用户感受到的时间。 user：用户态花的 CPU 时间。真正在算你的代码的时间。 sys：内核态花的 CPU 时间。系统调用、页错误、调度都记在这里。 三者关系最关键的一条：real 远大于 user＋sys，说明在等——等 IO、等锁、等网络，或者被别的进程挤了。 反过来 real 小于 user＋sys，说明用了多核——多个核同时干活，加起来的总时间可以超过墙上时间。

二、perf 与 /proc/stat 各补哪一块

perf stat 给你硬件层面的数：指令数、周期数、缓存未命中、分支预测失败、上下文切换次数。time 看不到这些。 /proc/stat 给整机的账：每个 CPU 在 user／system／idle／iowait 上各花了多少。它是累计值，两次相减才有意义。 三个工具的分工：time 看单个命令，perf 看硬件行为，/proc/stat 看整机。排查时先 /proc/stat 定位是哪类瓶颈，再用 perf 深挖。

三、三条纪律

一、先跑一遍预热。第一次有冷缓存、有动态链接、有页错误，量到的是启动成本不是稳定态。 二、只改一个变量。想比【两种算法】，就别同时换机器、换编译器、换数据集。否则数字出来了也说不清是谁的功劳。 三、重复多次取中位。单次结果可能是运气。取中位数比取平均更稳（平均会被极值拉走）。

四、本书为什么反复强调这三条

因为【看起来像数据的东西】最容易被误用。 作者在每个实验里都写明【同一台机器、同样的条件、同样的程序】——这不是啰嗦，是在给数字立信用。 一条实用判据：如果一份性能报告没说【测了几次、怎么控制的变量】，那些数字就只能当参考，不能当依据。

五、动手 Demo：实验方法——在真系统上怎么量

这一节不跑数据，只把三个工具、三条纪律列清楚。它们是你以后自己验证任何结论的工具箱。

# ① 单条命令：三行时间
time ls -R /usr > /dev/null

# ② 硬件行为：指令、缓存、切换
perf stat -e cycles,instructions,cache-misses,context-switches ./程序

# ③ 整机账本：每个 CPU 在什么状态上花了多少（累计值）
cat /proc/stat | head -3

# ④ 每秒刷新一次，看趋势
vmstat 1

实跑输出：

--------------------------------------------------------------------
实验方法——在真系统上怎么量
--------------------------------------------------------------------
① 三个工具，各管一段

  工具           量什么                             注意
  -------------------------------------------------------------------
  time           整条命令的真实/用户/系统时间       只到进程级
  perf stat      指令数、缓存未命中、上下文切换     要能读性能计数器
  /proc/stat     整机 CPU 时间怎么花的              每次读都是累计值

  **`time` 输出三行（real／user／sys）：**
  **real 是墙上时钟**，**user＋sys 是真正花在 CPU 上的**。
  两者差得远，说明**大部分时间在等**（等 IO、等锁、等别人）。

② 做实验的三条纪律

  纪律               为什么             违反的后果
  ---------------------------------------------------------
  先跑一遍预热       第一次有冷缓存     量到的是启动成本
  只改一个变量       归因要唯一         说不清是谁的功劳
  重复多次取中位     有噪声与抖动       一次结果可能是运气

  **这三条在本书每一个实验里都能看到**：作者反复强调【同一台机器、同样的条件、
  同样的程序】，**就是为了让数字能自圆其说。**

time 那三行里，real 与 user＋sys 的比较是最有用的诊断：差得多说明在等，反过来说明吃了多核。 /proc/stat 是累计值，直接看没有意义，两次相减才有意义。这条坑过很多人。 vmstat 是最省事的组合：r（可跑进程数）、cs（切换）、us/sy/id/wa（时间去向）。一行就能判断瓶颈在哪。 记住那三条纪律：预热、单变量、取中位。违反任何一条，数字就算出来了也不可信。

30 秒实验

  1. time sleep 1——real 约 1 秒，user＋sys 接近 0。这就是【在等】的样子。
  2. time python -c "sum(range(10000000))"——看 user 占了多少，sys 有多少。
  3. vmstat 1 5 观察 r 列：一直大于核数就说明 CPU 不够。

常见误区

  1. 【real 就是程序耗时】。它包含等待。程序本身的耗时是 user＋sys。
  2. 【跑一次就能比较出快慢】。噪声可能比差别还大。至少跑三次取中位。
  3. 【user 时间高说明程序写得差】。它只说明【在算】，算得是否有用要看它在算什么。
自测三问（点开对答案） 1. time 的三行各是什么？怎么用它们判断瓶颈？ —— real 墙上时钟、user 用户态 CPU、sys 内核态 CPU。**real ≫ user＋sys 说明在等；real < user＋sys 说明吃了多核。** 2. 为什么 /proc/stat 必须两次相减？ —— 它是**累计值**（自开机以来的总时间），单次读没有意义。 3. 做性能实验的三条纪律？ —— 先预热、只改一个变量、重复多次取中位。

相关笔记