我在 2008 R2 Enterprise SP1 上遇到了一个奇怪的性能问题。
设置如下：
- 许多进程监听绑定在单个 NIC 上的不同多播 UDP 流（每个进程监听 5 个多播）
- 跨进程，所有多播使用相同的端口范围但不同的多播 IP（重要的细节，因为给定端口的每个多播接收器将是 REUSED 服务器套接字的服务器）
- 每个进程组播监听带宽为10Mbits
- 在 NIC 上设置 RSS，在 NIC 和 OS 上设置最大卸载设置，激活 MSI
行为：
- 在 17 个监听进程（约 85 个加入的 UDP 多播）下，内核 CPU 影响可以忽略不计。
- 在 17 到 22 个侦听器（大约 110 个加入的 UDP 多播）之间，内核 CPU 使用率开始缓慢增长，但可以接受
- 超过 25 时，每个加入的多播都会开始对内核 CPU 时间产生巨大影响，这会影响所有 RSS 绑定的 CPU
- 每个监听进程使用的 CPU 时间接近于 0（这是正常的，因为进程除了读取多播之外什么都不做），所以真正的问题在于 OS 组件
我们的发现：
- 更改 NIC 硬件不会对行为产生影响（已在 HP NC382i、基于 Broadcom 的 NIC 和 HP NC365T、四千兆、基于 Intel 的上测试）
- 全局接收带宽不是限制因素（单个 500Mbits 流不会触发 CPU 负载）
- 在多播套接字上读取似乎不是限制因素（我们只使用多播流上的哑 JOIN 进程执行了测试并重现了 CPU 负载问题）
- 在两个 NIC 上拆分多播流量似乎可以限制 CPU 负载并更好地进行传播。然而，这不是我们的用例。
问题：
- 我们至少需要能够监听大约 500 个多播流，最多可能需要 750 个
- 相同的硬件，运行 XP 操作系统在 CPU 内核时间上没有这种行为
可疑组件：
- NDIS.sys 似乎是解释 CPU 使用率增加的一个很好的原因。
你们中有人遇到过这样的问题吗？能否给出一些调查方向？我读了所有关于 win server 2008 网络性能增强的资料，但似乎都与 TCP 流量有关。我还测试了所有可以通过注册表或 netsh 命令进行的优化。
答案1
那是大量的多播流，通常 NIC 的硬件过滤限制较低，超过该限制时，它们要么丢弃所有内容（廉价 NIC 上的实现不佳），要么将所有内容转发给操作系统进行过滤。当操作系统执行过滤时，您的处理器使用率将飙升。
除了研究您列出的一些不同的硬件之外，您还可以扩展到基于 10GigE，唯一的选择是使用代理服务器。
通过实验找到一些可以可靠管理的多播流，然后通过 TCP 将流转发到中央服务器或一组服务器。然后，该中央服务器可以使用 TCP 分段加速或完整的 ToE 来使传入的网络负载对处理器来说微不足道。
由于 Windows 驱动程序非常差，我根本无法使用 Broadcom 硬件获得不错的多播速率。看看 Linux 在相同硬件上的表现会很有趣，这应该可以很好地指示硬件和 IP 堆栈的质量。
您列出的 Windows XP 运行良好，Windows Server 和 Windows XP 之间的主要区别在于量子时间。Windows Server 提供更长的量子时间，可能值得研究强制缩短量子时间（如果您甚至可以设置它）。