性能监控与瓶颈分析

概述

提供推理服务性能监控的完整方案，实时采集 FPS、延迟、显存、GPU 利用率等指标，自动分析瓶颈位置并给出优化建议。基于 T4 vs S4000 真实压测经验。

使用场景

• 生产环境监控：7x24 小时推理服务性能监控
• 压测数据采集：系统性能测试时自动化数据收集
• 瓶颈定位：推理慢时快速定位是哪个环节
• 容量规划：根据监控数据预测扩容需求
• SLA 保障：监控 FPS/延迟确保满足 SLA
• 故障预警：GPU 异常/显存泄漏早期发现

真实压测经验

瓶颈定位案例：S4000 后处理延迟

通过对推理流程分解计时发现：S4000 前向推理 1.2ms（与 T4 相当），但后处理（NMS）耗时 13.7ms，是 T4（0.9ms）的 15 倍。定位到 S4000 的 NMS 算子实现存在性能问题。

GPU 异常检测案例

8 卡并发测试中，通过监控各 GPU 的 FPS 发现 GPU 0 和 GPU 4 在 2 路并发时性能异常下降。进一步排查发现散热和驱动版本问题。

操作指南

1. PipelineMonitor 推理流程监控

使用 PipelineMonitor 类对推理各阶段计时：前处理、前向推理、后处理、推流编码。通过 time.perf_counter() 记录耗时，计算 FPS 和延迟分布。

2. GPU 状态监控

定期采集 GPU 状态：利用率、显存、温度、功耗。NVIDIA 用 nvidia-smi，摩尔线程用 mthreads-gmi。每 5 秒采集一次。

3. FPS 与延迟统计

维护滑动窗口（最近 100 帧）计算：平均 FPS、P50/P95/P99 延迟、丢帧率。低于阈值时触发告警。

4. 瓶颈分析报告

| 阶段 | T4 耗时 | S4000 耗时 | 占比(S4000) | |------|---------|-----------|------------| | 前处理 | 0.5ms | 0.5ms | 3% | | 前向推理 | 1.3ms | 1.2ms | 8% | | 后处理 | 0.9ms | 13.7ms | 80% | | 推流编码 | 2.0ms | 2.0ms | 9% | | 总计 | 4.7ms | 17.4ms | 100% |

S4000 后处理占总延迟 80%，为明确瓶颈

5. 多 GPU 负载分析

收集各 GPU 的 FPS 和利用率，计算负载均衡度。理想状态各 GPU 负载差异不超过 10%。

6. 监控告警规则

| 指标 | 告警阈值 | 说明 | |------|---------|------| | FPS | 小于 25 | 低于实时要求 | | P99 延迟 | 大于 100ms | 用户体验差 | | GPU 利用率 | 大于 95% | 可能过载 | | 显存使用 | 大于 90% | OOM 风险 | | GPU 温度 | 大于 85C | 散热问题 | | 丢帧率 | 大于 5% | 推理跟不上 |

常见问题与排查

| 问题 | 原因 | 解决方案 | |------|------|---------| | FPS 突然下降 | GPU 过热降频 | 检查散热 | | 显存持续增长 | 显存泄漏 | 排查代码引用 | | P99 延迟极高 | 偶发 GC/同步 | 排查 Python GIL | | GPU 利用率低 | CPU 瓶颈 | 使用多进程 | | 监控本身影响性能 | 采集频率过高 | 降低采集频率 | | 告警风暴 | 阈值设置不合理 | 调整阈值+告警抑制 |

扩展方向

• Prometheus + Grafana: 标准化监控方案
• 分布式追踪: OpenTelemetry 追踪推理全链路
• AI 异常检测: 使用 ML 模型检测异常模式
• 自动扩缩容: 根据监控指标自动增减实例
• 历史趋势分析: 长期性能趋势预测
• 多租户监控: 按租户隔离监控数据

技能链路

• yolo-video-inference: 监控推理 FPS 和延迟
• gpu-concurrent: 监控多 GPU 负载均衡
• gpu-benchmark: 压测过程数据采集
• rtmp-streaming: 监控推流延迟和码率
• model-quantization: 量化前后性能对比

检查清单

• ] 推理各阶段计时已部署
• ] GPU 状态定期采集
• ] FPS 和延迟告警已配置
• ] 瓶颈分析报告自动生成
• ] 多 GPU 负载均衡监控
• ] 历史数据持久化存储
• ] 告警通知渠道已配置