如何避免Boost ASIO反应器受限于单核？

Question

TL; DR:我有可能反应堆吞吐量有限吗？我怎么说？io_service的实现是多么昂贵和可扩展(跨线程)？

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

此应用程序接受来自大约1,000台其他计算机的连接,读取数据,解码简单协议,并将数据混洗到使用mmap()映射的文件中.该应用程序还使用madvise(WILLNEED)预取"未来"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的基于事件的实现有关.

我可能反应堆吞吐量有限吗？我怎么说？io_service的实现是多么昂贵和可扩展(跨线程)？

编辑:我最初没有找到这个其他线程,因为它使用了一组不与我重叠的标签: - /很可能我的问题是在执行boost :: asio reactor时使用的过度锁定.请参阅C++套接字服务器 - 无法使CPU饱和 然而,问题仍然存在:我如何证明这一点？我该如何解决？

Answer 1

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