1. 性能问题概述：Linux 内核性能问题的常见类型与分析方法

Linux 内核性能问题通常表现为系统响应变慢、吞吐量下降或服务中断。要高效定位根因，首先需要理解问题的分类与系统化的分析方法。本章将介绍最常见的四类性能瓶颈（CPU、内存、I/O、网络），以及业界广泛采用的两种方法论：USE 方法（资源视角）和 RED 方法（服务视角）。

1.1 常见性能问题类型

内核性能问题可以按资源维度划分为四大类。下表总结了每类问题的典型表现、常见根因以及初步排查工具。

资源类型 典型表现 常见根因 初步排查工具
CPU 高负载、高上下文切换、软/硬中断占比高 死循环、锁竞争、调度策略不当、中断风暴 top, vmstat, perf, mpstat
内存 OOM、频繁换页、内存泄漏、大页使用不当 内存泄漏、碎片化、cgroup 限制、NUMA 失衡 free, vmstat, /proc/meminfo, valgrind
I/O 高 I/O 等待、磁盘利用率高、延迟抖动 文件系统锁、块层队列深度不足、磁盘硬件故障 iostat, iotop, blktrace, fio
网络 丢包、重传、连接超时、吞吐量低 缓冲区溢出、中断亲和性、协议栈锁、驱动 bug netstat, ss, tcpdump, ethtool
实践提示： 当系统出现性能问题时，不要急于深入某个工具。先通过 top 或 vmstat 1 快速判断瓶颈是 CPU、内存还是 I/O，再选择对应类别的工具进行细化分析。

1.1.1 CPU 性能问题

CPU 瓶颈通常表现为 user、system、softirq 或 steal 时间占比异常。高 context switch 往往暗示锁竞争或线程过多。使用 perf top 可以快速定位热点函数。

1.1.2 内存性能问题

内存问题不仅包括物理内存不足，还包括 TLB 抖动、NUMA 访问延迟 和 slab 缓存膨胀。通过 /proc/meminfo 观察 Active(anon) 与 Inactive(anon) 的比例，可以判断内存回收压力。

1.1.3 I/O 性能问题

I/O 瓶颈的核心指标是 await（平均 I/O 等待时间）和 svctm（服务时间）。当 iostat -x 1 显示 %util 接近 100% 且 await 远高于 svctm 时，说明 I/O 队列深度过大，磁盘成为瓶颈。

1.1.4 网络性能问题

网络性能问题常表现为 TCP 重传率 升高或 接收/发送丢包。使用 netstat -s 查看协议栈统计，结合 ethtool -S eth0 检查驱动级计数，可以快速定位是网卡硬件、驱动还是协议栈的问题。

Linux 内核四类性能问题关系图 Linux 内核性能问题 CPU 瓶颈 内存瓶颈 I/O 瓶颈 网络瓶颈 性能问题通常不是孤立的，例如内存不足可能引发 I/O 换页，进而导致 CPU 等待。

1.2 性能分析基本方法论

面对复杂的性能问题，需要一套系统化的方法论来指导排查方向，避免盲目试错。本节介绍两种最实用的方法：USE 和 RED。

1.2.1 USE 方法（资源视角）

USE 方法由 Brendan Gregg 提出，全称为 Utilization、Saturation、Errors。它适用于所有物理资源（CPU、磁盘、网络接口等）的快速检查。

  • Utilization（利用率）：资源忙于服务的时间百分比。例如 CPU 利用率 90% 表示 90% 的时间在工作。
  • Saturation（饱和度）：资源无法及时服务的额外请求量。例如 CPU 运行队列长度、磁盘 I/O 等待队列深度。
  • Errors（错误数）：资源发生的错误事件计数。例如网卡丢包、磁盘 I/O 错误。
USE 方法检查清单示例（CPU）：
Utilization: mpstat -P ALL 1 → 查看每核利用率
Saturation: vmstat 1 → 查看 r 列（运行队列）
Errors: dmesg | grep -i "cpu\|thermal\|mce" → 检查 CPU 相关错误

1.2.2 RED 方法（服务视角）

RED 方法由 Tom Wilkie 提出，全称为 Rate、Errors、Duration。它适用于面向服务的系统（如微服务、API 网关），从请求维度衡量性能。

  • Rate（速率）：每秒处理的请求数（吞吐量）。
  • Errors（错误率）：失败请求的比例。
  • Duration（持续时间）：请求处理延迟，通常关注 P50、P99 等百分位值。
方法选择建议： 排查基础设施层（物理机、虚拟机）问题时优先使用 USE；排查应用层或服务网格问题时优先使用 RED。两者可以互补：先用 USE 定位资源瓶颈，再用 RED 量化对服务的影响。

1.2.3 USE 与 RED 对比

维度 USE 方法 RED 方法
视角 资源（CPU、内存、I/O、网络） 服务（请求、调用、事务）
核心指标 利用率、饱和度、错误数 速率、错误率、延迟
适用场景 操作系统、硬件、内核子系统 Web 服务、数据库、中间件
典型工具 top, iostat, vmstat, sar Prometheus, Grafana, 链路追踪
输出形式 百分比、队列长度、错误计数 QPS、错误率、延迟分布
USE 与 RED 方法对比流程图 USE 方法（资源视角） U - Utilization（利用率） S - Saturation（饱和度） E - Errors（错误数） RED 方法（服务视角） R - Rate（速率） E - Errors（错误率） D - Duration（延迟） USE 回答“哪个资源满了”，RED 回答“对服务的影响有多大”。两者结合可覆盖 90% 的性能问题。

1.3 方法论落地：一个快速排查流程

将 USE 和 RED 方法结合，可以形成以下高效的排查流程：

  1. 从 RED 开始：检查服务的 Rate、Errors、Duration，确认问题是否真实存在。
  2. 切换到 USE：对疑似瓶颈的资源（CPU/内存/I/O/网络）检查 Utilization、Saturation、Errors。
  3. 交叉验证：例如 RED 显示延迟升高，USE 发现磁盘饱和度很高，则根因可能是 I/O 瓶颈。
  4. 深入追踪：使用 perf、strace、blktrace 等工具定位具体代码路径。
常见误区： 不要只看一个指标就下结论。例如 CPU 利用率 100% 不一定是 CPU 瓶颈，也可能是 I/O 等待导致进程占着 CPU 空转（实际是 I/O 问题）。务必结合上下文切换、运行队列等饱和度指标综合判断。

1.4 本章小结

  • Linux 内核性能问题主要分为 CPU、内存、I/O、网络 四类，每类有对应的典型表现和排查工具。
  • USE 方法（利用率、饱和度、错误数）适用于资源层面的快速扫描。
  • RED 方法（速率、错误率、延迟）适用于服务层面的量化评估。
  • 实际排查中，建议 RED 先行、USE 跟进、交叉验证，避免单指标误判。
← 上一章 📖 返回目录 下一章 →