瓶颈先出在算力上
检测类设备的性能瓶颈通常先出现在 CPU 与内存，而不是转发口：开启的规则类别增多、叠加 TLS 解密、流量峰值突增，都会让检测进程排队，表现为新建连接变慢、告警延迟，严重时触发检测降级甚至丢包。排查的关键是分清「流量变多」与「策略变重」两类原因，并用计数和日志验证，而不是凭感觉扩容。
基本信息
| 可疑信号 | CPU/内存持续高位、会话表接近上限、检测丢包计数增长、告警延迟 |
|---|---|
| 常见原因 | 规则开得过多、TLS 解密叠加、流量突增、日志外发占用资源 |
| 先看数据 | 设备自身 CPU/内存/会话数/丢包计数与降级日志 |
| 处置顺序 | 先收敛范围止血，再做容量评估与扩容 |
典型使用场景
- 业务高峰期网页打开变慢，怀疑设备成为瓶颈
- 新增 TLS 解密或开启某类规则后性能明显下降
- 日常巡检发现 CPU 长期高于安全水位
- 日志出现检测降级或丢包记录，需要确认影响范围
- 新设备上线前按峰值流量与目标规则集做容量验证
排查顺序
排查顺序
# 1. 判断流量本身是否异常增长（对比接口流量历史曲线）
# 2. 回顾近期变更：新增规则类别、加密流量检测、日志外发
# 3. 查设备资源与降级计数（CPU、内存、会话表、丢包计数）
# 4. 临时收敛规则范围或解除密范围，观察资源是否回落
# 5. 定位到单一变量后，再决定是优化策略还是扩容信号与含义
| 信号 | 含义 | 处理方向 |
|---|---|---|
| CPU 长期高位 | 检测或转发排队 | 先收敛规则范围，再评估规格 |
| 内存高位 | 会话表与重组缓存占用 | 核对并发会话增长与老化参数 |
| 检测丢包计数 | 流量未被完整检测 | 已发生检测降级，优先止血 |
| 告警延迟 | 日志与告警队列积压 | 检查日志外发链路与平台写入能力 |
| 会话表接近上限 | 并发连接逼近容量 | 评估新建速率与老化时间设定 |
性能告警期间不要同时改多个变量：一次只调整一项并观察结果，否则无法判断是哪项改动起了作用。
把 CPU、内存、会话数、检测丢包做成长期趋势监控，比现场临时排查更能提前发现问题；阈值按业务峰值设定，不要用平均值。