先直接给你梳理核心结论：当前的串联架构确实存在明显性能瓶颈，很大概率是摄像头卡顿的主要原因；拆分两个独立系统的思路完全正确，应该能有效缓解甚至解决卡顿问题。下面给你详细分析和建议：

一、当前架构的不合理之处 #

你的系统现在是「第一台交换机作为核心节点，同时连接两台NVR，并且串联第二、第三台交换机」，这种结构会带来两个致命的带宽压力：

• 所有摄像头的视频流都要经过第一台交换机转发到对应NVR：第三台交换机上的23个摄像头，视频流要走「第三台→第一台→NVR1」的路径；第二台的23个摄像头要走「第二台→第一台→NVR2」的路径。等于第一台交换机要承载全部60路摄像头的视频流量，再加上两台NVR的存储回写流量，负载直接拉满。
• 全HD 25fps的摄像头，按H.264编码算单路码率大概4-8Mbps，60路峰值就能到480Mbps左右；就算是H.265编码，串联架构下交换机之间的上联链路（比如第三台到第一台的链路）是单千兆，一旦多路高码率视频同时传输，很容易出现带宽拥堵，导致丢包、卡顿。

另外，同网段内有60+2+3=65台设备，过多的设备也可能引发广播风暴，占用额外带宽，进一步加剧卡顿。

二、拆分独立系统的可行性与优势 #

把系统拆成两个独立的监控子网，是非常合理的优化方案：

• 具体方案建议：让NVR1 + 第三台交换机组成一个独立网段（例如192.168.2.0/24），负责管理IP段50-73的摄像头；NVR2 + 第一、第二台交换机组成另一个独立网段（例如192.168.3.0/24），负责管理IP段74-110的摄像头。
• 核心优势：每个子网的视频流量都在自己的交换机集群内部流转，不需要跨到另一个核心交换机，彻底消除了原架构的核心带宽瓶颈；同时拆分网段后，广播域变小，也能减少广播包对系统的影响。

三、额外的排查优化点 #

除了架构调整，你还可以检查这些点，进一步确认和解决问题：

• 检查交换机端口协商：确保所有交换机之间的上联端口、NVR与交换机的端口都协商到千兆速率，如果是百兆带宽肯定不足以支撑多路视频传输。
• 检查NVR的存储性能：60路全HD视频写入对硬盘要求很高，确认NVR的硬盘是否为监控级硬盘，有没有开启RAID（如果设备支持的话），或者硬盘是否出现读写瓶颈。
• 调整摄像头码率：如果不是必须用最高码率，可以适当降低单路摄像头的码率（比如H.264降到4Mbps），减少整体带宽消耗；同时关闭不必要的功能（比如音频、高灵敏度智能侦测）。
• 查看交换机负载：登录交换机的管理界面，查看各端口的带宽使用率、丢包率，如果发现某个端口使用率接近100%，那就是明确的瓶颈点。

备注：内容来源于stack exchange，提问作者user2853569