windws server 2008 udp组播性能问题

我在2008 R2 Enterprise SP1上遇到一个奇怪的性能问题。

这是设置：

• 许多进程侦听绑定在单个NIC上的不同组播UDPstream（5个多播按进程侦听）
• 在整个过程中，所有组播使用相同的端口范围，但不同的组播IP（重要的细节，因为给定端口的每个组播接收器将是REUSED服务器套接字的服务器）
• 每个进程多播监听带宽为10Mbits
• 在NIC上设置RSS，在NIC＆OS上设置最大卸载设置，激活MSI

行为：

• 在17个监听进程（大约85个joinUDP多播）中，内核CPU的影响是可以忽略的。
• 在17和22个监听器之间（大约110个joinUDP多播），内核CPU使用率开始缓慢增长，但是可以接受的
• 在25以上，每个join的组播开始对内核CPU时间产生巨大影响，这会影响所有RSS绑定的CPU
• 每个侦听进程使用的CPU时间接近0（正常，因为进程只会读取多播），所以真正的问题在于操作系统组件

我们发现：

• iotop显示99.99％的kswapd0和0％的磁盘读取和磁盘写入
• 为什么使用Hyper-V时SSD的性能下降？
• ZFS快照回滚的速度取决于文件数量吗？
• ext3文件系统性能调优：要监控的指标
• 如何在configurationRAIDarrays时select最佳的条带大小

• 更改NIC硬件对行为没有影响（在基于Broadcom NIC和HP NC365T，基于Intel千兆位的HP NC382i上进行testing）
• 全局接收带宽不是限制因素（单个500Mbitsstream不会触发CPU负载）
• 阅读组播套接字似乎不是限制因素（我们进行了testing，只是在组播stream上进行testing，只处理了组播stream，并再现了CPU负载问题）
• 在两个NIC上拆分多点传送stream量似乎可以更好地限制CPU负载和传播。 但是，这不是我们的用例。

问题：

• 我们至less需要能够监听大约500个组播stream，最多可以达到750个
• 相同的硬件，运行XP操作系统在CPU内核时间没有这种行为

被推荐的组件：

• NDIS.sys似乎是解释CPU使用率增加的一个很好的候选人。

你们有没有遇到这样的问题，可以给一些方向去调查。 我已经阅读了所有关于win server 2008networkingperf增强function的信息，但都似乎与TCPstream量有关。 我还testing了可以通过registry或netsh命令完成的所有可能的优化。