optimization - 如何避免 Boost ASIO react 堆受限于单核？

Question

TL;DR:我的 react 堆吞吐量是否可能受到限制？我该怎么说？ io_service 的实现有多昂贵和可扩展性(跨线程)？

我有一个非常大规模的并行应用程序，运行在具有大量 RAM 和快速 SSD RAID 的超线程双四核至强机器上。这是使用 boost::asio 开发的。

这个应用程序接受来自大约 1,000 台其他机器的连接，读取数据，解码一个简单的协议(protocol)，并将数据打乱到使用 mmap() 映射的文件中。该应用程序还使用 madvise(WILLNEED) 预取“ future ”mmap 页面，因此它不太可能阻塞页面错误，但可以肯定的是，我已经尝试生成多达 300 个线程。

这是在 Linux 内核 2.6.32-27-generic(Ubuntu Server x64 LTS 10.04)上运行的。 Gcc 版本是 4.4.3，boost::asio 版本是 1.40(两者都是 Ubuntu LTS)。

运行 vmstat、iostat 和 top，我看到磁盘吞吐量(在 TPS 和数据量中)是个位数的 %。同样，磁盘队列长度总是比线程数小很多，所以我不认为我受 I/O 限制。此外，RSS 攀升，但随后稳定在几场演出(如预期的那样)并且 vmstat 显示没有分页，所以我想我没有内存限制。 CPU 恒定在 0-1% 用户，6-7% 系统，其余为空闲。线索!一个完整的“核心”(记住超线程)占 CPU 的 6.25%。

我知道系统落后了，因为客户端机器在超过 64kB 未完成时阻止 TCP 发送，并报告事实；他们都不断报告这一事实，系统的吞吐量远低于预期、预期和理论上的可能。

我的猜测是我正在争夺某种锁。我使用应用程序级锁来保护可能发生变异的查找表，因此我将其拆分为 256 个顶级锁/表以打破这种依赖关系。然而，这似乎一点帮助都没有。

所有线程都通过一个全局 io_service 实例。在应用程序上运行 strace 表明它大部分时间都在处理 futex 调用，我想这与 io_service reactor 的基于事件的实现有关。

我的 react 堆吞吐量是否可能受到限制？我该怎么说？ io_service 的实现有多昂贵和可扩展性(跨线程)？

编辑:我最初没有找到这个其他线程，因为它使用了一组与我的不重叠的标签:-/我的问题很可能是在 boost::asio react 器的实现中使用了过多的锁定。见 C++ Socket Server - Unable to saturate CPU
但是，问题仍然存在:我如何证明这一点？我该如何解决？

Answer 1

答案确实是，即使是最新的 boost::asio 也只能从单个线程调用 epoll 文件描述符，而不是一次从多个线程进入内核。我可以理解为什么，因为当您使用多个线程时，对象的线程安全性和生命周期非常不稳定，每个线程都可以获得相同文件描述符的通知。当我自己编写代码时(使用 pthreads)，它可以工作，并且可以扩展到单个内核之外。那时不使用 boost::asio —— 一个设计良好且可移植的库应该有这个限制，这是一种耻辱。