当系统存在异常告警时，如果排除了业务异常，第一时间需要关注到系统的各个指标水位，能够快速定有一个定位方向，是应急和找根因的前提。Load、CPU、Memory这些最常用的系统监控指标需要非常了解。在执行压测时，这些也是考察系统瓶颈的指标；
Load
Load：单位时间内系统处于「可运行状态」和「不可中断状态」的进程平均数；通常有3个单位指标：1/5/15分钟；
如果 Load值持续高于系统的CPU核心数，说明系统负载过重，CPU 资源不足，无法及时处理所有任务，任务会在队列中等待，导致系统响应变慢。如4核CPU的服务器，
LOAD=4
表示满负荷，LOAD>4
表示过载。
如突发的流量通常会导致短期（1分）Load过载；如果5分钟甚至15分钟持续过载，应当关注，采取措施，比如机器扩容；
| 级别 | 正常水位 | 异常水位 | 分析 |
|---|---|---|---|
| 1分 | ≤ CPU核心数 | ≥CPU核心数 | 短期突发流量，可以关注 |
| 5分 | ≤ CPU核心数 | ≥CPU核心数 | 可能引发持续高负载，需要关注，根据业务准备应急 |
| 15分 | ≤ CPU核心数 | ≥CPU核心数 | 已经持续高负载，需要介入处理 |
- 高流量引发的Load飙高属于正常，可考虑设置限流、机器扩容等；
- 非流量引发，需要关注Load飙高期间的热点代码问题；
- 偶现的Load飙高问题不大，有规律的Load飙高需要关注；
CPU利用率
CPU利用率通常大致有2个级别：
- 用户态：应用程序代码消耗的CPU，一般对应业务逻辑；
- 系统态：操作系统内核消耗的CPU；一般是系统调用、中断等；
|级别|正常水位|宽松水位|异常水位|分析| |---|---|---|---| | 用户态 | ≤ 50% | 50% ~ 70% | ≥ 80% | 存在计算密集逻辑，此时CPU可能是瓶颈 | | 系统态 | ≤ 10% | 10% ~ 20% | ≥ 20% | 在web应用中比较少见，通常意味着网络连接、IO请求频繁、文件读写频繁 |
Memory
内存需要关注物理内存和Swap使用量；
- 物理内存：应用程序实际占用的内存；通过JVM进程的内存占用比较稳定，大涨大跌都是不正常的。
- Swap使用量：物理内存不足时启用的虚拟内存；Swap使用量持续增长是内存不足的早期信号；
| 级别 | 正常水位 | 异常水位 | 分析 |
|---|---|---|---|
| 物理内存 | ≤ 70% | ≥ 90% | 关注是否流量异常、内存泄露，可能会引发FullGC |
| Swap使用量 | ≤ 1次秒 | ≥ 10次秒 | 物理内存不足，可能影响性能，需扩容，或重启pod |
压测找到系统瓶颈
1. 明确压测目标
- 容量规划：确定系统能支撑的最大并发用户数（如双十一峰值流量）。
- 瓶颈定位：发现代码逻辑、数据库查询、缓存或网络链路的性能问题。
- 验证优化效果：对比优化前后的吞吐量（TPS/QPS）、延迟（Latency）等指标。
2. 设计压测场景
- 基准测试：单接口/单服务的性能基线（如 API 的平均响应时间）。
- 负载测试：逐步增加压力，观察系统的各个指标的状态；
- 压力测试：超过系统设计容量的极限测试（如 200% 峰值流量），观察降级或崩溃点。
- 稳定性测试：长时间（如 24 小时）持续压力，检测内存泄漏或资源耗尽问题。
3. 环境与数据隔离
- 独立压测环境：避免影响生产环境，尽量模拟生产配置（如相同的 CPU、内存、网络带宽）。
- 数据隔离与预热：
- 数据库预填充真实规模的数据（避免空表测试失真）。
- 缓存预热（如 Redis 提前加载热点数据）。
