零基础学习性能测试第二章-linux服务器监控：CPU监控

目录

• • 学习内容与快速应用路径
  • • [第一阶段：理解 CPU 核心概念 (0.5天)](#第一阶段：理解 CPU 核心概念 (0.5天))
    • 第二阶段：掌握核心监控命令与指标 (1-2天)
    • [第三阶段：识别 CPU 问题与瓶颈 (核心技能)](#第三阶段：识别 CPU 问题与瓶颈 (核心技能))
    • 第四阶段：整合到性能测试工作流程 (快速应用落地)
  • 快速应用到工作中的关键策略

零基础学习 Linux CPU 监控并快速应用到性能测试工作中，关键在于 理解核心指标、掌握实用命令、识别瓶颈模式、关联性能影响。下面是一个聚焦 CPU 监控的详细学习路径，助你快速上手：

核心目标：

1. 理解 CPU 时间组成： 知道 CPU 时间花在用户态、内核态、等待 I/O 等不同状态上的含义。
2. 掌握核心监控命令： 熟练使用 top/htop, vmstat, mpstat, pidstat, sar 查看 CPU 状态。
3. 识别关键 CPU 指标： 能解读 %us, %sy, %wa, %id, load average, 运行队列长度等指标的含义和健康阈值。
4. 定位 CPU 瓶颈与问题： 能判断 CPU 过载、I/O 等待瓶颈、进程竞争、配置不足等问题。
5. 整合到性能测试流程： 在压测过程中实时监控 CPU，并在报告中分析 CPU 使用情况及其对性能的影响。

---

学习内容与快速应用路径

第一阶段：理解 CPU 核心概念 (0.5天)

1. CPU 核心 (Cores) vs 线程 (Threads)：

   • 物理核心： 实实在在的处理器单元。lscpu 命令查看 Core(s) per socket。
   • 逻辑核心 (通常说的 vCPU)： 通过超线程 (Hyper-Threading) 技术，一个物理核心可以模拟出两个逻辑核心。lscpu 查看 CPU(s) 或 top 按 1 看到的数量。性能监控主要关注逻辑核心。
   • 快速应用认知： 运行 lscpu | grep -E '^CPU\(s\):|Core\(s\) per socket|Thread\(s\) per core' 了解你的服务器 CPU 配置。

2. CPU 时间组成 (理解 top/mpstat 输出)：

   • %us (User)： CPU 花费在运行 用户空间应用程序代码 上的时间百分比。高 %us 通常意味着应用自身计算密集。
   • %sy (System)： CPU 花费在运行 内核空间系统调用和中断处理 上的时间百分比。高 %sy 可能表示系统调用频繁、进程切换过多、内核锁竞争或驱动问题。
   • %ni (Nice)： CPU 花费在运行 低优先级 (nice) 用户进程 上的时间百分比。通常占比很小，可忽略。
   • %id (Idle)： CPU 空闲 时间百分比。理想状态下，压测时 %id 应很低。
   • %wa (I/O Wait)： 最关键指标之一！ CPU 在 等待磁盘 I/O 或网络 I/O 操作完成 而空闲的时间百分比。高 %wa 表示 CPU 想干活但被慢速 I/O 卡住了，是 I/O 瓶颈的直接信号！
   • %hi (Hardware Interrupt)： CPU 处理硬件中断的时间百分比。通常很低。
   • %si (Software Interrupt)： CPU 处理软件中断的时间百分比。通常很低。
   • %st (Steal)： (仅虚拟化环境) 被 Hypervisor 偷走用于运行其他虚拟机的时间百分比。高 %st 表示宿主机资源不足。
   • 核心关系： %us + %sy + %ni + %id + %wa + %hi + %si + %st = 100%
   • 快速应用认知： 压测时，CPU 繁忙 (%us + %sy) 高是好事（资源利用充分），但 %wa 高是坏事（I/O 阻塞）。 目标是让 CPU 尽可能忙于计算 (%us/%sy)，而不是等待 (%wa)。

3. 系统负载平均值 (Load Average)：

   • 是什么： uptime 或 top 第一行显示的三个数字 (e.g., load average: 1.25, 0.89, 0.75)。
   • 含义： 表示在过去的 1分钟、5分钟、15分钟 内，系统处于可运行状态 ® 或不可中断睡眠状态 (D - 通常等 I/O) 的 平均进程数。
   • 如何解读：
     • 负载 < 逻辑核心数： 系统相对空闲或有空闲核心。
     • 负载 ≈ 逻辑核心数： 系统资源利用充分，但可能没有明显排队。
     • 负载 > 逻辑核心数： 表示有进程在排队等待 CPU 资源。数值越大，排队越严重。
     • 看趋势： 结合 1min, 5min, 15min 值看负载是上升、下降还是稳定。压测时关注 1min 负载。
   • 重要： 负载高 ≠ CPU 利用率高！ 负载包含了等待 I/O (D 状态) 的进程。高负载可能由高 %us/%sy (CPU 忙) 或高 %wa (I/O 慢) 引起。
   • 快速应用认知： 压测时，如果 load average (1min) 持续远高于逻辑 CPU 数，就需要结合 %us, %sy, %wa 判断是 CPU 真不够用还是被 I/O 卡住了。

第二阶段：掌握核心监控命令与指标 (1-2天)

目标：熟练使用命令获取数据，理解每个关键指标的含义和健康阈值。

1. top / htop 命令 (进程级监控，首选 htop):

   • 命令： top (动态刷新) 或 htop (更友好，yum install htop / apt install htop)
   • CPU 相关视图 (顶部汇总行)：
     • %Cpu(s)： 显示的是 所有逻辑 CPU 的平均使用率 。按 1 可切换显示每个逻辑 CPU 核心的详情。
     • 关键指标： us, sy, ni, id, wa, hi, si, st (含义同上)。
     • Tasks： 总进程数，以及处于运行 (R)、睡眠 (S)、停止 (T)、僵尸 (Z)、不可中断睡眠 (D) 状态的进程数。关注 R (运行中) 和 D (等 I/O) 的数量。
     • Load average： 系统负载。
   • 进程列表：关键列：
     • %CPU： 该进程占用单个逻辑 CPU 核心的百分比。 如果一个进程占满一个核心，就是 100%。注意：多核系统中，一个进程的 %CPU 可以超过 100% (如占用 2 个核心就是 200%)。
     • TIME+： 该进程累计使用的 CPU 时间。
     • P (仅 htop)： 进程优先级。
     • STATE： 进程状态 (R=运行, S=可中断睡眠, D=不可中断睡眠/等 I/O, Z=僵尸, T=停止)。
   • 健康阈值 (经验值)：
     • 整体 CPU： %us + %sy： < 70-80% 通常较安全。持续 > 80-90% 表示 CPU 是瓶颈。%wa： 理想是 0%。 > 1-2% 需关注， > 5-10% 是严重 I/O 瓶颈。
     • 负载： 1min Load Avg < 逻辑核心数较理想。持续 > 逻辑核心数表示资源紧张。> 2倍逻辑核心数通常有问题。
   • 快速应用：
     • 压测时运行 htop。
     • 按 %CPU (F6 -> PERCENT_CPU) 降序排序，找出 CPU 消耗最高的进程。
     • 观察顶部汇总行的 us, sy, wa 变化。
     • 按 1 查看每个核心的利用率是否均衡？是否有核心被 100% 占用而其他空闲？
     • 关注 Tasks 行 R 和 D 的数量变化。

2. mpstat 命令 (多核 CPU 详细统计)：

   • 命令： mpstat [-P {ALL | 0,1,2...}] [间隔秒数] [次数] (通常 mpstat -P ALL 1：每秒报告一次所有逻辑核心的统计)

   • 作用： top 显示的是平均值，mpstat 能详细展示每个逻辑 CPU 核心的使用情况，是分析 CPU 负载均衡和不均衡问题的利器。

   • 输出解读 (关键列)：

     Linux ... (4 CPU)
     10:30:00 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
     10:30:01 AM  all   25.00    0.00   15.00    0.25    0.00    0.25    0.00    0.00    0.00   59.50
     10:30:01 AM    0   40.00    0.00   20.00    0.00    0.00    0.00    0.00    0.00    0.00   40.00
     10:30:01 AM    1   10.00    0.00   10.00    0.00    0.00    0.00    0.00    0.00    0.00   80.00
     10:30:01 AM    2   30.00    0.00   20.00    1.00    0.00    1.00    0.00    0.00    0.00   48.00
     10:30:01 AM    3   20.00    0.00   10.00    0.00    0.00    0.00    0.00    0.00    0.00   70.00

     • CPU: 核心编号 (all 表示平均)。
     • %usr: 等同于 %us。
     • %sys: 等同于 %sy。
     • %iowait: 等同于 %wa。
     • %idle: 等同于 %id。
     • %irq, %soft: 硬件/软件中断，通常很低。
     • %steal: 虚拟化环境被偷走的时间。

   • 快速应用：

     • 压测时持续运行 mpstat -P ALL 1。
     • 核心关注点：
       • 整体 (all) 的 %usr, %sys, %iowait。
       • 各个核心 (0, 1, 2...) 的利用率是否均衡？ 是否存在个别核心接近 100% 而其他空闲？(可能应用线程绑定或单线程瓶颈)。
       • 是否有核心的 %iowait 特别高？ (可能该核心处理的 I/O 请求慢)。

3. vmstat 命令 (系统级统计，包含 CPU 和队列)：

   • 命令： vmstat [间隔秒数] [次数] (如 vmstat 1：每秒刷新)

   • 输出解读 (重点关注 CPU 和进程队列列)：

     procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
      r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
      2  1      0 1234567 98765 654321    0    0  1000   500  500 1000 30 15 50  5  0

     • procs 部分：
       • r (Running)： 最重要队列指标！ 正在运行或等待 CPU 时间片的进程数。 如果 r 持续大于逻辑 CPU 数，说明 CPU 资源不足，进程在排队。压测时重点监控！
       • b (Blocked)： 处于不可中断睡眠状态 (D) 的进程数 (通常是等待 I/O)。
     • cpu 部分：
       • us, sy, id, wa, st： 含义同 top/mpstat，是所有 CPU 的平均值。

   • 快速应用：

     • 压测时持续运行 vmstat 1。
     • 眼睛紧盯 r 列！ 如果 r 持续大于逻辑 CPU 核心数，是 CPU 资源不足 的强烈信号。
     • 同时观察 us, sy, wa 比例。
     • 结合 b 列 (等 I/O 进程数) 和 wa 判断 I/O 影响。

4. pidstat 命令 (精细的进程级 CPU 统计)：

   • 命令： pidstat [选项] [间隔秒数] [次数] (常用 pidstat -u 1 或 pidstat -u -p <PID> 1)

   • 作用： 比 htop 提供更详细、更定时的单个进程 CPU 使用报告。特别适合监控特定进程。

   • 输出解读 (-u 选项)：

     10:35:00 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
     10:35:01 AM  1001     12345   75.00   10.00    0.00   85.00     2  java
     10:35:01 AM  1002     54321    5.00    1.00    0.00    6.00     0  nginx

     • %usr: 进程在用户态消耗的 CPU 百分比。
     • %system: 进程在内核态消耗的 CPU 百分比。
     • %guest: 运行虚拟机消耗的 CPU (通常0)。
     • %CPU: 进程消耗的总 CPU 百分比 (所有核心上的总和)。 等同于 htop 的 %CPU。
     • CPU: 进程最后运行在哪个逻辑 CPU 核心上。

   • 快速应用：

     • 用 htop 找到可疑的高 CPU 进程 PID。
     • 针对该 PID 运行 pidstat -u -p <PID> 1，持续监控其详细的 %usr, %system, %CPU 变化。 这有助于判断是应用逻辑 (%usr 高) 还是系统调用 (%system 高) 消耗 CPU。
     • 也可直接运行 pidstat -u 1 查看所有进程的 CPU 使用快照。

5. sar 命令 (历史数据收集与分析)：

   • 命令： 通常需要安装 (sysstat 包: yum install sysstat / apt install sysstat)。默认每10分钟收集一次系统活动数据。
   • 查看历史 CPU： sar -u [起始时间] [结束时间] (e.g., sar -u -s 10:00:00 -e 11:00:00)
   • 查看当天 CPU： sar -u (默认显示当天所有记录)
   • 输出解读： 类似 mpstat 的 all 行，显示 %user, %nice, %system, %iowait, %steal, %idle。
   • 快速应用： 当压测结束后，用 sar -u 或指定时间范围查看压测期间的 CPU 整体使用情况概览和趋势 ，特别是峰值 (%user, %system, %iowait)。非常方便生成报告图表。

第三阶段：识别 CPU 问题与瓶颈 (核心技能)

1. CPU 资源不足 (CPU Bound)：

   • 现象：
     • %us + %sy 持续 > 80-90% (平均值或核心最大值)。
     • %id 持续很低 (< 10-20%)。
     • vmstat 的 r 列持续 > 逻辑 CPU 数 (排队严重)。
     • load average (1min) 持续 > 逻辑 CPU 数且不断上升。
     • 应用响应时间 (RT) 随负载增加而显著上升，吞吐量 (TPS) 达到平台无法提升。
   • 原因： 应用计算逻辑复杂、线程/进程过多、配置不足、代码效率低。
   • 快速诊断： vmstat 1 (看 r), mpstat -P ALL 1 (看各核 %us+%sy), htop (按 %CPU 排序找大户)。
   • 性能测试关联： TPS 达到上限无法提升，RT 显著增加，且 r 队列长、%us+%sy 高。

2. I/O 等待瓶颈 (I/O Bound)：

   • 现象：
     • %wa 持续 > 5-10% (平均值或核心最大值)。
     • vmstat 的 b 列较高 (有进程在等 I/O)。
     • 可能伴随 vmstat 的 bi/bo (块设备 I/O) 较高。
     • %us + %sy 可能并不高 (CPU 想干活但被 I/O 卡住)。
     • load average 可能较高 (包含了等 I/O 的 D 状态进程)。
     • 应用响应时间 (RT) 不稳定或较高，TPS 上不去。
   • 原因： 磁盘慢、磁盘过载、网络慢、数据库慢查询、内存不足导致 Swap 频繁读写。
   • 快速诊断： mpstat -P ALL 1 (看 %iowait), vmstat 1 (看 %wa, b, bi, bo), iostat (分析磁盘 I/O 详情 - 后续学习)。
   • 性能测试关联： RT 高且波动大，TPS 上不去，%wa 高是直接信号。 优化 I/O (磁盘/网络/DB) 是重点。

3. 内核瓶颈 (System Time High)：

   • 现象：
     • %sy 持续异常高 (e.g., > 30-40%)。
     • %us 可能不高。
     • 可能伴随 vmstat 的 cs (Context Switch - 上下文切换) 非常高。
     • 系统整体感觉"不顺畅"。
   • 原因： 进程/线程数量过多导致频繁切换、系统调用过于频繁、锁竞争激烈、网络中断处理过多、驱动问题。
   • 快速诊断： mpstat -P ALL 1 (看 %sys), vmstat 1 (看 cs, in - 中断), pidstat -w (看进程级上下文切换), strace/perf (分析系统调用 - 进阶)。
   • 性能测试关联： TPS/RT 表现不佳，且 %sy 异常高是主要线索。需要优化进程模型、减少系统调用或排查内核/驱动。

4. CPU 负载不均衡：

   • 现象： mpstat -P ALL 1 显示个别核心利用率接近 100% (%us+%sy)，而其他核心利用率很低 (%id 高)。
   • 原因： 单线程应用、进程/线程绑定 (CPU Affinity) 设置不合理、中断处理集中在少数核心。
   • 影响： 整体性能受限于最忙的核心，其他核心资源浪费。
   • 快速诊断： mpstat -P ALL 1 一目了然。
   • 性能测试关联： 限制了系统的水平扩展能力。需要应用支持多线程并行或调整亲和性。

第四阶段：整合到性能测试工作流程 (快速应用落地)

1. 测试前准备：

   • 确认监控工具可用：htop, vmstat, mpstat, pidstat, sar (安装 sysstat)。
   • 基线测量： 系统空闲时运行 mpstat -P ALL 1 5, vmstat 1 5, sar -u 记录基线值。记录 lscpu 输出。

2. 压测中实时监控 (开多个终端/tmux)：

   • 窗口 1：vmstat 1 - 紧盯 r (运行队列), b (阻塞进程), us, sy, wa 列。 r > CPU cores 是红灯！
   • 窗口 2：mpstat -P ALL 1 - 观察整体和每个核心的 %usr, %sys, %iowait。 看是否均衡，是否有核心打满，%wa 是否高。
   • 窗口 3：htop - 按 %CPU (F6 -> PERCENT_CPU) 降序排序。 找出 CPU 消耗 Top 进程，观察其 %CPU, STATE, 所属用户。按 1 看核心视图。
   • (可选) 窗口 4：pidstat -u 1 - 针对 htop 发现的疑似问题进程，用 pidstat -u -p <PID> 1 精细监控。
   • 核心关注：
     • 当 r 持续 > 逻辑核心数时，记录时间戳，并关联此时 TPS 是否停滞/下降？RT 是否飙升？
     • 当 %wa 持续 > 5% 时，记录时间戳，并关联此时 RT 是否波动/上升？TPS 是否上不去？
     • 当某个核心 %usr+%sy 持续 > 95% 时，记录时间戳和核心号。
     • 当发现某个进程 %CPU 异常高时，记录其 PID 和命令名。

3. 测试后分析与报告：

   • 收集数据： 保存 vmstat, mpstat 输出，htop 截图 (高负载时)，sar -u 数据 (用 sar -u -f /var/log/sa/saXX 查看历史某天)。
   • 分析关键点：
     • CPU 利用率峰值： %us max, %sy max, %wa max (来自 mpstat/sar)。
     • 运行队列峰值： vmstat 中 r 的最大值。
     • 负载峰值： load average (1min) 最大值 (来自 sar -q 或 top 记录)。
     • 瓶颈类型判断： 是 CPU Bound (%us+%sy 高, r 长), I/O Bound (%wa 高, b 高), 还是 System Bound (%sy 异常高)？
     • 不均衡性： 是否有核心长期打满而其他空闲？
     • Top 进程： 哪些进程消耗了最多的 CPU (htop/pidstat)？
   • 报告撰写：
     • 清晰描述 CPU 监控结果： 列出关键指标峰值 (%us max, %sy max, %wa max, r max, load max)。
     • 展示关联性图表/描述： 将 r > cores 的时间点、%wa 飙升的时间点、%us+%sy 接近 100% 的时间点 与 性能测试工具记录的 RT 上升点、TPS 下降点/平台点 精确对应起来。
     • 指出问题与瓶颈：
       • 如："当 r 值持续在 8 (逻辑 CPU=4) 且 %us+%sy 平均达 95% 时，TPS 稳定在 200 无法提升，平均 RT 从 50ms 升至 500ms，判断为 CPU 资源不足瓶颈"。
       • 或："压测全程 %wa 维持在 15-25%，vmstat 显示 b 列在 5-10，磁盘 iostat 显示 %util 100%，判断为磁盘 I/O 瓶颈导致 CPU 大量时间等待"。
       • 或："应用进程 app_server 的单个线程 (PID 1234) 持续占用 CPU 核心 2 的 98%，导致该核心成为瓶颈"。
     • 给出建议：
       • CPU Bound: 优化代码算法、增加 CPU 资源 (更多/更强 CPU)、优化线程池配置、水平扩展。
       • I/O Bound: 优化磁盘 (SSD、RAID)、优化数据库 (索引、慢查询)、优化网络、增加内存减少 Swap。
       • System Time High: 减少不必要的系统调用、优化锁策略、调整进程/线程数、升级内核/驱动。
       • 负载不均衡: 优化应用使其支持多线程并行、调整进程 CPU 亲和性 (谨慎)、检查中断平衡。

快速应用到工作中的关键策略

1. 工具三板斧： 掌握 vmstat 1 (看队列 r/wa), mpstat -P ALL 1 (看核心利用率/iowait), htop (找进程) 这三个命令足矣覆盖 90% 场景。pidstat 和 sar 作为补充。
2. 指标聚焦： 死死盯住 r (运行队列长度), %us+%sy (CPU 计算忙), %wa (CPU 等 I/O) 。它们是判断 CPU 瓶颈性质和严重程度的 黄金三角。
3. 关联分析： CPU 指标必须与性能测试结果关联！ 当 r 持续 > CPU 数 时，TPS 是否上不去了？当 %wa 高时，RT 是否飙升了？这种关联性是证明 CPU 是性能瓶颈的核心证据。
4. 进程视角： 发现整体 CPU 高 (%us+%sy) 时，立刻用 htop 按 CPU 排序，找出消耗最大的进程。
5. 区分真假瓶颈： %us+%sy 高 (r 高) 是真 CPU 不足。%wa 高是 I/O 慢拖累了 CPU。%id 高但负载高/RT 高可能是等锁或其他资源。
6. 理解负载含义： load average > cores 不一定是 CPU 问题，可能是等 I/O (%wa)。结合 vmstat 的 r 和 b 分析。
7. 动手实践：
   • 运行 stress -c 4 (模拟 CPU 负载) 观察 vmstat, mpstat, htop 变化。
   • 运行 dd if=/dev/zero of=tempfile bs=1M count=1000 oflag=direct (模拟磁盘写，oflag=direct 绕过缓存增加 %wa) 观察 %wa 上升。
   • 观察不同负载下的 CPU 指标变化。

总结： 零基础快速掌握 Linux CPU 监控的核心就是 监控队列 (vmstat r), 区分忙闲 (mpstat us/sy/wa), 定位元凶 (htop %CPU) ，并将这些指标的变化 精准关联 到 TPS 和 RT 上。通过几次实际的性能测试，结合这个流程进行分析，你就能快速将 CPU 监控技能应用到工作中，有效判断 CPU 是否成为瓶颈以及瓶颈的类型，为性能优化指明方向。祝你成功！