关键不是等“100%利用率”，而是看排队、延迟激增、错误上升等饱和信号；cpu利用率95%未必瓶颈，但run queue超核数3–4倍即表明调度饱和；内存90%不可怕，swap增长或page fault陡升才说明不足；磁盘i/o利用率70%时若iowait>20%且await>10ms，即已堆积；p95/p99突变早于资源打满，是更灵敏的饱和前兆；三类指标中任意两个同时恶化即可判定达饱和点。
容量基准测试中评估系统资源达到瓶颈的饱和点，关键不是等“100%利用率”出现，而是看资源在高负载下是否开始排队、延迟激增、错误上升——这些才是饱和的真实信号。
盯紧饱和度，而不是只看利用率
CPU 利用率到 95% 不一定代表瓶颈，但如果 run queue 长度持续超过 CPU 核数的 3–4 倍，说明线程在排队等待调度，响应时间就会明显拉长；内存使用率到 90% 也不可怕，但若 swap 使用量开始增长或 page fault 次数陡升，就表明物理内存已不够用；磁盘 I/O 利用率看似只有 70%，可如果 iowait > 20% 且 await 时间持续高于 10ms，说明 I/O 请求已在队列中堆积。
结合百分位响应时间找拐点
在逐步加压过程中，记录不同并发下的 P95/P99 响应时间。当并发从 500 增到 600 时，P95 从 120ms 跳到 480ms，而平均值只涨了不到 100ms——这个突变点就是系统开始饱和的标志。它往往早于 CPU 或内存打满，是更灵敏的瓶颈前兆。
交叉验证三类指标变化趋势
- 资源利用率（Utilization）：平稳上升，无异常突跳
- 饱和度（Saturation）：在某压力点后呈非线性增长（如 runq-sz 突增、r/s+w/s 持续高位、TCP retransmit 上升）
- 错误数（Errors）：连接拒绝（ECONNREFUSED）、超时（ETIMEDOUT）、OOM killer 日志、数据库连接池耗尽告警开始出现
三者中任意两个同时恶化，基本可判定该资源已达容量饱和点。
用 QPS/并发与响应时间反推理论吞吐天花板
根据公式 QPS ≈ 并发数 / 平均响应时间，在响应时间尚未明显劣化阶段，QPS 应随并发线性增长。一旦 QPS 增速放缓甚至持平，而并发和响应时间都在上升，说明系统吞吐已触顶。此时回溯监控，就能定位是哪一层（应用线程池、DB 连接池、CPU、网卡中断等）最先卡住。
