Apache虚拟主机部署多摄像头YOLOv5推理性能下降问题咨询

核心结论 #

虚拟主机工作线程本身不会直接引发性能干扰，但你的部署架构存在资源调度和复用的低效问题，这是导致帧率骤降的主要原因。

具体问题分析与解决方向 #

1. YOLOv5模型重复加载导致GPU调度开销

   • 每个Flask脚本独立加载YOLOv5模型，会在GPU中生成12个模型副本。尽管当前显存占用仅6GB，但多模型上下文切换会大幅增加GPU调度开销，降低推理效率。单路时GPU只需处理一个模型，调度成本极低，因此帧率能达到34fps。
   • 解决方法：
     • 改为单进程加载1次YOLOv5模型，通过多线程/协程处理12路摄像头流，复用同一个模型实例。
     • 若必须保持多应用架构，可实现模型池机制，让多个Flask实例共享少量模型副本（比如2-4个），避免重复加载。

2. Apache+多Flask应用的调度瓶颈

   • Windows下Apache的WinNIT MPM线程调度效率有限，12个独立Flask应用会产生大量CPU上下文切换开销。同时，默认Flask实例为单线程处理请求，多路流并发时会出现请求排队，进一步拉低帧率。
   • 解决方法：
     • 合并Flask应用：用单个Flask脚本处理所有12路摄像头，通过路由参数或独立函数区分不同摄像头的流处理逻辑。
     • 替换WSGI服务器：改用Waitress（Windows下轻量高效的WSGI服务器）替代Apache，减少中间层的调度开销；测试阶段也可直接使用Flask自带服务器（仅用于验证，不建议生产环境）。

3. 摄像头流读取与预处理的低效

   • 12个独立进程同时读取摄像头流，可能触发硬件驱动的锁竞争，导致流读取延迟。此外，单线程预处理无法充分利用8核CPU，造成CPU资源闲置（当前仅35%使用率），进而拖慢GPU推理的喂数速度。
   • 解决方法：
     • 集中式流处理：用单独进程统一读取所有12路摄像头流，完成预处理（缩放、归一化等）后，再将数据分发到推理模块，避免重复操作。
     • 多核预处理：使用multiprocessing或concurrent.futures实现多线程/多进程预处理，充分利用CPU核心。

4. 资源监控的关键指标遗漏

   • 当前仅关注显存、CPU和RAM占用，但GPU的**利用率（GPU Utilization）**才是推理性能的核心指标。如果GPU利用率偏低，说明推理线程在等待数据（流读取/预处理跟不上），而非GPU资源不足。
   • 解决方法：
     • 用nvidia-smi命令查看实时GPU利用率和显存使用情况，定位是否存在数据喂入瓶颈。
     • 用任务管理器查看每个Flask/Apache进程的CPU使用率，确认是否有进程单线程满载、其余核心闲置的情况。

内容的提问来源于stack exchange，提问作者Bhupendra Mourya