与网络/IO 绑定应用程序的进程相比，在 Linux 上工作时线程限制是什么？

问题描述：

我听说在多核服务器上的 Linux 下，如果只有 1 个进程但有多个线程，就不可能达到最佳性能，因为 Linux 对 IO 有一些限制，因此 8 核服务器上 8 个线程的 1 个进程可能比 8 个进程慢。

有什么意见吗？还有其他限制可能会减慢应用程序的速度吗？该应用程序是一个网络 C++ 应用程序，为数百个客户端提供服务，并有一些磁盘 IO。

更新：除了我自己实现的锁定之外，我担心还有一些与 IO 相关的问题...在多个线程中同时进行网络/磁盘 IO 是否存在问题？

解决方案 1：

线程的缺点

主题：

• 序列化内存操作。这是内核，而 MMU 必须为诸如mmap()执行页面分配之类的操作提供服务。

• 共享相同的文件描述符表。在更改和查找此表时需要锁定，此表存储文件偏移量和其他标志等内容。使用此表进行的每个系统调用（例如open()、accept()）fcntl()都必须锁定它以转换fd为内部文件句柄，并在进行更改时锁定它。

• 分享一些调度属性。不断评估进程以确定它们对系统施加的负载，并据此进行调度。大量线程意味着更高的 CPU 负载，这是调度程序通常不喜欢的，并且会增加该进程对事件的响应时间（例如读取套接字上的传入数据）。

• 可能会共享一些可写内存。任何由多个线程写入的内存（如果需要花哨的锁定，速度会特别慢）都会产生各种缓存争用和传输问题。例如，堆操作（如malloc()和）free()对全局数据结构进行操作（在某种程度上可以解决这个问题）。还有其他全局结构。

• 共享凭证，这对于服务类型流程来说可能是一个问题。

• 共享信号处理，这些将在处理时中断整个过程。

进程还是线程？

• 如果您想使调试更容易，请使用线程。

• 如果您使用的是 Windows，请使用线程。（在 Windows 中，进程是极其重量级的）。

• 如果稳定性是主要问题，请尝试使用流程。（SIGSEGV/PIPE只需一个流程...）。

• 如果没有线程可用，则使用进程。（现在不太常见，但确实发生过）。

• 如果您的线程共享无法由多个进程使用的资源，请使用线程。（或者提供 IPC 机制以允许与资源的“所有者”线程进行通信）。

• 如果您使用的资源仅在每个进程一个的基础上可用（并且每个上下文一个），显然请使用进程。

• 如果您的处理上下文完全不共享任何内容（例如，产生连接但又忘记连接的套接字服务器accept()），并且 CPU 是瓶颈，请使用进程和单线程运行时（不存在诸如堆和其他地方的各种强烈锁定）。

• 线程和进程之间最大的区别之一是：线程使用软件结构来保护数据结构，而进程使用硬件（速度明显更快）。

链接

• pthreads（7）

• 关于进程和线程 (MSDN)

• 线程与进程

解决方案 2：

这确实应该没有什么区别，但可能与设计有关。

多进程应用程序可能需要执行较少的锁定，但可能会使用更多内存。进程间共享数据可能更加困难。

另一方面，多进程可以更加健壮。您可以调用 exit() 并安全地退出子进程，而不会影响其他进程。

这取决于客户端的依赖程度。我通常推荐最简单的解决方案。