8

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

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

这个应用程序接受来自大约 1000 台其他机器的连接，读取数据，解码一个简单的协议，并将数据打乱到使用 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 反应器的实现中使用了过多的锁定。请参阅C++ 套接字服务器 - 无法使 CPU 饱和 但是，问题仍然存在：我如何证明这一点？我该如何解决？

4

3 回答 3

2

我相信如果你使用多个 io_service 对象（比如每个 cpu 核心），每个都由一个线程运行，你不会有这个问题。请参阅 boost ASIO 页面上的 http 服务器示例 2。

我已经针对服务器示例 2 和服务器示例 3 进行了各种基准测试，发现我提到的实现效果最好。

于 2011-10-13T20:04:54.030 回答
2

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

于 2011-08-25T06:13:44.743 回答
0

在我的单线程应用程序中，我从分析中发现大部分处理器指令都用于 io_service::poll() 的锁定和解锁。我使用 BOOST_ASIO_DISABLE_THREADS 宏禁用了锁定操作。这也可能对您有意义，具体取决于您的线程情况。

于 2015-10-31T03:11:56.330 回答