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

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

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

核心目标：

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

学习内容与快速应用路径

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

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 配置。
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)。
系统负载平均值 (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天)

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

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 的数量变化。
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 请求慢)。
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 st2  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 影响。
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 使用快照。
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 问题与瓶颈 (核心技能)

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 高。
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) 是重点。
内核瓶颈 (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 异常高是主要线索。需要优化进程模型、减少系统调用或排查内核/驱动。
CPU 负载不均衡：
- 现象： mpstat -P ALL 1 显示个别核心利用率接近 100% (%us+%sy)，而其他核心利用率很低 (%id 高)。
- 原因： 单线程应用、进程/线程绑定 (CPU Affinity) 设置不合理、中断处理集中在少数核心。
- 影响： 整体性能受限于最忙的核心，其他核心资源浪费。
- 快速诊断： mpstat -P ALL 1 一目了然。
- 性能测试关联： 限制了系统的水平扩展能力。需要应用支持多线程并行或调整亲和性。

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

测试前准备：
- 确认监控工具可用：htop, vmstat, mpstat, pidstat, sar (安装 sysstat)。
- 基线测量： 系统空闲时运行 mpstat -P ALL 1 5, vmstat 1 5, sar -u 记录基线值。记录 lscpu 输出。
压测中实时监控 (开多个终端/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 和命令名。
测试后分析与报告：
- 收集数据： 保存 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 亲和性 (谨慎)、检查中断平衡。

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

工具三板斧： 掌握 vmstat 1 (看队列 r/wa), mpstat -P ALL 1 (看核心利用率/iowait), htop (找进程) 这三个命令足矣覆盖 90% 场景。pidstat 和 sar 作为补充。
指标聚焦： 死死盯住 r (运行队列长度), %us+%sy (CPU 计算忙), %wa (CPU 等 I/O)。它们是判断 CPU 瓶颈性质和严重程度的 黄金三角。
关联分析： CPU 指标必须与性能测试结果关联！ 当 r 持续 > CPU 数时，TPS 是否上不去了？当 %wa 高时，RT 是否飙升了？这种关联性是证明 CPU 是性能瓶颈的核心证据。
进程视角： 发现整体 CPU 高 (%us+%sy) 时，立刻用 htop 按 CPU 排序，找出消耗最大的进程。
区分真假瓶颈： %us+%sy 高 (r 高) 是真 CPU 不足。%wa 高是 I/O 慢拖累了 CPU。%id 高但负载高/RT 高可能是等锁或其他资源。
理解负载含义： load average > cores 不一定是 CPU 问题，可能是等 I/O (%wa)。结合 vmstat 的 r 和 b 分析。
动手实践：
- 运行 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 是否成为瓶颈以及瓶颈的类型，为性能优化指明方向。祝你成功！