服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

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(正常,因为进程只会读取多播),所以真正的问题在于操作系统组件 我们发现: 更改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命令完成的所有可能的优化。