1. 课程导入与性能分析全景

在开始学习具体的工具和调优手段之前，我们需要先建立一张"性能地图"。RHEL 系统性能分析的核心目标，并不是把某个指标压到最低，而是在给定硬件资源和业务负载下，让系统稳定地满足服务等级要求（SLA）。换句话说，性能分析回答的是三个问题：系统现在表现如何？瓶颈在哪里？为了支撑未来的负载，还需要多少资源？前两个问题属于性能分析，第三个问题属于容量规划，二者共同构成本课程的主线。

三个关键指标：吞吐量、延迟、利用率

无论分析的是 CPU、内存、磁盘还是网络，我们几乎总是围绕三个指标展开观察。

吞吐量（Throughput）描述单位时间内系统完成的工作量，例如每秒处理的 HTTP 请求数（req/s）、每秒读写的字节数（MB/s）、每秒完成的事务数（TPS）。它衡量的是"做了多少事"。

延迟（Latency）描述单个请求从发出到完成所经历的时间，例如一次磁盘 I/O 的服务时间、一次数据库查询的响应时间。它衡量的是"一件事做得多快"。延迟通常用平均值、中位数（p50）、p95、p99 等分位数来描述，因为平均值会掩盖长尾请求，而用户体验往往由 p99 决定。

利用率（Utilization）描述资源在观察窗口内处于忙碌状态的比例，例如 CPU 利用率 65%、磁盘利用率 90%。它衡量的是"资源被用掉了多少"。

这三个指标之间存在典型的相互制约关系：当利用率接近饱和时，排队现象加剧，延迟会非线性上升，而吞吐量增长趋缓甚至下降。理解这一点，是后续判断瓶颈的基础。

性能分析的整体方法论

面对"系统变慢了"这类模糊问题，最忌讳的是凭直觉直接改参数。一个可复用的分析流程是：先定义目标，再建立基线，然后自顶向下逐层定位，最后验证并固化结论。

1. 定义目标与范围：明确是响应时间超标、吞吐量不足，还是资源即将耗尽；明确影响的是哪类业务、哪个时间段。
2. 建立基线：在系统正常时采集 CPU、内存、磁盘、网络的关键数据，作为后续对比的参照。没有基线，"异常"就无从谈起。
3. 自顶向下定位：从应用层现象出发，逐层向下排查，先看整体负载（如 uptime 的 load average），再看各子系统，最后深入到具体进程和线程。
4. 验证假设：每次只改变一个变量，用数据确认改动是否真正解决了问题，避免"改了但不知道有没有用"。
5. 固化与复盘：把有效的配置、监控项和判断依据记录下来，形成可复用的经验。

在 RHEL 中，这套流程会落到具体工具上：uptime、vmstat、mpstat、pidstat、iostat、sar、top、perf 等。它们各自覆盖不同的层次，后续章节会逐一展开。

容量规划的基本概念

容量规划是性能分析的"向前看"版本。它要回答：按照当前的增长趋势，现有资源还能支撑多久？需要提前扩容多少？

容量规划通常包含几个要素：当前容量（现有资源能承载的最大负载）、当前负载（实际业务量）、增长预测（按历史趋势或业务计划推算）、安全余量（预留应对突发和峰值）。一个常用的经验法则是：关键资源的目标利用率控制在 70% 左右，为峰值和突发留出空间。

下面这张图把本节的核心概念组织成一张"性能与容量全景图"：左侧是三个关键指标，中间是自顶向下的分析方法，右侧是容量规划的输入与输出。它帮助你在后续学习中随时定位自己处在哪个环节。

一个简单的示例：从现象到判断

假设一台 RHEL 服务器上运行 Web 服务，用户反馈"页面变慢"。我们先用 uptime 看整体负载：

$ uptime
 14:32:05 up 12 days,  3:21,  2 users,  load average: 8.42, 6.15, 3.80

1 分钟负载 8.42 明显高于 15 分钟负载 3.80，说明负载正在快速上升。接着用 vmstat 1 观察：

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  2      0 512340  82100 920400    0    0   420  1180 3200 5400 22  8 62  8  0
 7  3      0 508200  82100 918600    0    0   510  1320 3500 5900 24  9 58  9  0

这里 r 列（运行队列）持续在 6～7，wa（I/O 等待）约 8%～9%，id（空闲）约 58%～62%。运行队列长度大于 CPU 核数（假设 4 核），说明有进程在排队等 CPU；同时存在一定 I/O 等待。此时可以初步判断：CPU 是主要瓶颈之一，磁盘 I/O 也在贡献延迟。下一步应使用 pidstat -u 1 和 iostat -x 1 进一步定位到具体进程和设备。

这个例子说明：指标不是孤立看的，而是通过"负载—排队—等待—空闲"之间的关系来推断瓶颈。运行队列长、空闲率不低、I/O 等待存在，三者组合起来才指向"CPU 与磁盘共同受限"的判断。

容量规划的一个简化计算

继续上面的例子。假设当前业务峰值是 800 req/s，CPU 平均利用率 55%，目标是把利用率控制在 70% 以内。按线性估算，单机可支撑的峰值约为：

可支撑峰值 ≈ 当前峰值 × (目标利用率 / 当前利用率)
           ≈ 800 × (70% / 55%)
           ≈ 1018 req/s

如果业务预计半年后增长到 1400 req/s，则单机不足，需要至少 2 台同等配置的服务器（1400 / 1018 ≈ 1.38，向上取整并考虑冗余）。这只是一个线性近似，实际还要考虑延迟非线性上升、连接数、内存和磁盘带宽等因素，但它给出了容量规划的基本思路：用当前负载和利用率推算容量上限，再与预测负载比较，得出扩容需求。

本节小结