linux - 高性能文件服务的设计选择

Question

我正在 linux 下开发一个应用程序，它需要支持大约 250 个连接并通过 TCP 套接字传输大小在 100MB 以上的大文件。目的是调整吞吐量而不是延迟。我想始终保持饱和的 2x1Gbit 以太网连接。这些将被 channel 绑定(bind)。

预计应用程序将持续忙碌，并且会尽快丢弃数据。连接将在大部分时间保持连接，因此与 HTTP 不同，它们不会经常断开。

我一直在寻找各种选项，例如 epoll、sendfile api 等以获得高性能和 aio(恕我直言，这看起来太不成熟且风险太大)。

我也一直在研究底层使用 epoll 的 boost asio api。我以前用过它，但没有用于像这样的高性能应用程序。

我有 4 个以上的可用处理器内核，因此我可以充分利用它。

但是，我读到 boost asio 在多线程方面不是很好，因为 react 堆设计中存在一些锁定。这对我来说可能是个问题吗？

如果我有很多可用的 CPU 核心，我是否应该创建尽可能多的线程或 fork 进程并将它们设置为在每个处理器核心上运行？

关于锁定等等。我想要一些设计建议。我怀疑我的主要瓶颈将是磁盘 I/O，但尽管如此……我想要一个好的设计，而不需要以后进行大量返工。

有什么建议吗？

Answer 1

I'm developing an application under linux that will need to support around 250 connections and be transmitting large files over TCP sockets in the 100MB+ size range. The aim is to tune for throughput rather than latency. I want to keep saturated 2x1Gbit ethernet connectons at all times. These will be channel bonded.

磁盘 IO 通常比网络慢。 250 个客户端对于现代 CPU 来说不算什么。

文件有多大并不重要。真正的问题是数据总量是否适合 RAM - RAM 是否可以扩展以便数据适合它。如果数据适合 RAM，则不必过度优化:使用 sendfile() 的单线程服务器就可以了。

应考虑使用 SSD 进行存储，尤其是在优先读取数据的情况下。

It's expected that the application will be busy continuously and will just be throwing out data as quick as possible. The connections will remain up most of the time so unlike HTTP they won't be torn down so often.

“越快越好”会导致灾难。我对至少一个这样的多线程灾难负责，因为它导致的磁盘搜索量而无法扩展。

通常，您可能希望每个存储有几个(例如 4 个)磁盘读取线程，它会为非常大的 block 调用 read() 或 sendfile()，以便操作系统有机会优化IO。几乎不需要线程，因为人们希望乐观地认为可以从操作系统的 IO 缓存中并行提供一些数据。

不要忘记设置大套接字发送缓冲区。在您的情况下，轮询套接字的写入能力也很有意义:如果客户端无法像您读取/发送的速度那样快地接收，那么读取就没有意义。您服务器上的网络 channel 可能很胖，但客户端 NIC/磁盘却不是。

I've been looking at the various options such as epoll, sendfile api etc for high performance and aio (which looks too immature and risky IMHO).

现在几乎所有的 FTP 服务器都使用 sendfile()。 Oracle 使用 AIO，Linux 是他们的主要平台。

I've also been looking at the boost asio api which uses epoll underneath. I've used it before but not for a high performance application like this.

仅适用于套接字的 IIRC。 IMO 任何有助于处理套接字的实用程序都可以。

I have more than 4 processor cores available so I can make use of that.

TCP 由 NIC boost ，磁盘 IO 主要由 Controller 本身完成。理想情况下，您的应用程序应该处于空闲状态，等待磁盘 IO。

However, I read that boost asio is not very good with multiple threads because of some locking in the reactor design. Is this likely to be an issue for me?

检查 libevent作为备选。您可能只需要 sendfile() 的线程数量有限。并且数量应该受到限制，否则您会因磁盘寻道而扼杀吞吐量。

If I have lots of CPU cores available should I just create as many threads or forked processes and set them to run on each processor core?

没有。磁盘受寻道的影响最大。 (我重复了足够多的次数了吗？)如果你有很多自主读取线程，你将失去控制发送到磁盘的 IO 的可能性。

考虑最坏的情况。所有 read()s 都必须转到磁盘 == 更多线程，更多磁盘寻道。

考虑最好的情况。所有 read()s 都从缓存中获取 == 根本没有 IO。那么您的工作速度与 RAM 相当，可能根本不需要线程(RAM 比网络快)。

What about locking etc. I'd like some design suggestions. I suspect my main bottleneck is going to be Disk I/O but nonetheless...

这是一个答案非常非常长的问题，不适合放在这里(我也没有时间写)。这在很大程度上还取决于您要提供的数据量、您使用的存储类型以及访问存储的方式。

如果我们将 SSD 作为存储，那么任何愚蠢的设计(比如为每个客户端启动一个线程)都可以正常工作。如果您在后端有真正的旋转媒体，那么您必须对来自客户端的 IO 请求进行切片和排队，尽量避免在一侧使客户端挨饿，而在另一侧以尽可能少的寻道方式安排 IO。

我个人会从简单的单线程设计开始，在主循环中使用 poll()(或 boost.asio 或 libevent)。如果数据被缓存，那么就没有必要启动一个新线程。如果必须从磁盘中获取数据，单线程将确保我避免查找。用读取的数据填充套接字缓冲区并将等待更改为 POLLOUT 模式，以了解客户端何时使用数据并准备好接收下一个 block 。这意味着我在主循环中至少有三种类型的套接字:监听套接字、我正在等待请求的客户端套接字、我正在等待再次变为可写的客户端套接字。

I want a good design up front withough much rework later.

啊……好梦……