c – 接收大量(r)UDP流量时CPU负载高(Windows)

发布时间：2020-12-16 09:49:52 所属栏目：百科来源：网络整理

导读：我正在研究使用大量传入数据进行进一步处理的应用程序的问题(多播传输流,具体而言). 情况如下：添加了多个组播流.每个都有自己的接收器线程,从套接字接收数据,然后将其复制到一个环形缓冲区.它不再做了. 在大约500到600 mbit,一个特定的CPU核心达到100％.实

我正在研究使用大量传入数据进行进一步处理的应用程序的问题(多播传输流,具体而言).

情况如下：添加了多个组播流.每个都有自己的接收器线程,从套接字接收数据,然后将其复制到一个环形缓冲区.它不再做了.

在大约500到600 mbit,一个特定的CPU核心达到100％.实际上,在初始化流并且随着以太网流量的增加时,我可以看到它几乎线性地向该负载上升.

套接字代码使用WSA重叠API.即使我减少线程只做那个(即不复制到ringbuffer,这反过来将主机应用程序的任何负载减少到接近零),我很容易将该特定核心沉入红色.同样有趣的是,即使我通过亲和设置将其限制为4个完全不同的核心,此负载也存在于该特定核心上.让我得出结论,时间花在操作系统或驱动程序级别上.

我曾尝试在复制之前立即收集n个数据报(即超过1500字节的MTU),但这只会让事情变得更糟.我还检查了我的套接字是否配置正确(非阻塞,返回值都可以).

我想知道是否有人可以告诉我一些有关此问题,或许有这个问题,或者对如何在Windows上有效处理这些流量有一些有用的见解.

(我正在使用的NIC：Intel PRO PT1000)

UPDATE

我设置了一个只有一个目标的小测试应用程序：从任意数量的多播中获取传入的UDP.我正在使用像Len建议的IO完成端口策略这样做.现在我可以轻松地从28个多播中获得1Gbit的CPU负载(毕竟现在我没有对数据包做任何事情),但是当使用更多(更小带宽)的多播(通常在这台机器上超过70)时,吞吐量变得越来越糟,工人线程似乎不平衡,大多浪费时间(等待).

NIC中断负载现在不是限制因素(之前是).

我对这种材料,多线程网络的东西很陌生.工作线程只是在IO完成端口(GetQueuedCompletionStatusEx())w / INFINITE上等待,然后当流读取完成时,我立即发出另一个并循环(如果我可以同步在同一个流上获得更多),我会在没有发布新IO事件的情况下接受这些事件,FILE_SKIP_COMPLETION_PORT_ON_SUCCESS).

我拥有尽可能多的工作线程,因为我有CPU内核(任何(远)超过使事情变得更糟).

不认为这保证了一个新的问题 – 但是,再次,任何帮助非常感谢！

这是我的测试应用程序的来源. (C) – 应该是可读的:-) http://pastebin.com/xWEPPbi6

解决方法

>使用SysInternals Process Explorer工具查看您的系统并查看该CPU的使用位置,它可能会分配给“Interrupts”,在这种情况下,它是处理NIC中断的CPU.如果是这种情况,请查看您的NIC驱动程序,看看您是否可以启用或调整中断合并,以便NIC为相同数量的数据报生成更少的中断.
>如果数据报校验和计算尚未卸载到NIC,请查看是否可以卸载数据报校验和计算,然后将使用计算机上的CPU时间.请注意,如果NIC无法跟上并且驱动程序不会丢弃任何数据报,则可能存在非页面缓冲池使用的潜在问题(请参阅我的 this blog posting).
>切换到使用GetQueuedCompletionStatusEx(),你说你正在使用“WSA重叠API”,希望你的意思是I / O完成端口方法.如果是这样,那么GetQueuedCompletionStatusEx()将允许您使用较少的系统调用来读取更多数据报.
>切换到使用RIO API(参见 here for an introduction to the Windows Registered I/O Network Extensions).这继续了3的主题,并提供了将数据报放入代码的更多性能.

更新以反映问题更新：

>首先发出多个读取以获得待处理读取的良好积压.因此,例如,有100个待处理的读取,然后开始发布新的(如果您使用“跳过完成端口”处理稍微复杂一点,但想法是建立一个积压.>从GQCSEx中检索多个完成,或者使用它没有意义.>当你获得“内联”完成时,避免递归,更喜欢循环.否则你就是在咀嚼堆栈.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!