Linux 性能-多线程或多进程应用程序

为了在linux上开发高度网络密集型的服务器应用程序，首选哪种体系结构？其想法是，该应用程序通常会在具有多个核心（虚拟或物理）的机器上运行。考虑到性能是关键标准，采用多线程应用程序还是采用多进程设计的应用程序更好？我知道共享资源和同步从多个进程访问这些资源会带来很大的编程开销，但正如前面提到的，总体性能是关键要求，因此我们可以忽略这些事情。编程语言应该是C/C++

我听说，即使是多线程应用程序（单进程）也可以利用多个内核，在不同的内核上独立运行每个线程（只要不存在同步问题）。这个调度是由内核完成的。如果是这样，多线程应用程序和多进程应用程序之间的性能是否没有太大差异？Nginx使用多进程架构，速度非常快，但多线程应用程序能否获得相同的性能

---

谢谢。

linux上的进程和线程彼此非常相似-主要区别在于整个虚拟内存是共享的，而信号处理等某些事情也不同

这使得线程之间的上下文切换更便宜（不需要昂贵的MMU重新加载等），但不一定会造成速度上的很大差异（特别是在线程创建之外）

对于设计高度网络密集型的应用程序，基本上唯一的解决方案是使用事件式体系结构（否则，系统将因大量进程/线程而陷入困境，并在管理上花费比实际运行工作代码更多的时间），您对套接字上的I/O做出反应的位置，以及根据哪些套接字表现出活动来执行适当的操作

关于这种情况下所面临的问题的一篇著名著作是“C10k问题”，可从中获得-它描述了不同的I/O方法，因此尽管有点过时，但这是一篇非常好的介绍

---

不过，在深入研究类似reactor的设计之前要小心——它们可能会变得笨拙和复杂，所以请查看您是否不能使用提供更好抽象的库/语言（Erlang是我个人最喜欢的，使用Go等协同程序的语言也会很有用）.

如果在linux下，线程彼此独立地执行任务，那么没有理由不使用多个进程。多个进程会增加内存使用，因为每个进程都有自己的私有内存空间，但另一方面，在独立线程之间共享内存空间是更糟糕的决定。线程与进程之间的上下文切换通常对于进程而不是线程来说做得更好，尽管它有点依赖于体系结构和代码。进程不使用锁和互斥锁进行序列化是安全的。在Linux中，进程更易于管理和交互。这是一份你可能会感兴趣的好文件（）。

@p-l：谢谢你的回答。是的，计划是使用基于偶数的架构，并根据网络事件采取行动。并且在运行时不会创建额外的线程和进程。鉴于此，您认为多线程和多进程应用程序之间没有性能差异吗？例如：如果有一个具有4个内核的系统，那么这两种体系结构之间的性能不会有任何明显的差异？最大的可能差异在于调度，可以通过任务的cpu相关性进行修改，将每个任务（线程/进程）固定到特定的cpu。更多的差异可能来自服务器进程完成的实际工作以及它如何与网络部分交互。在访问内存的方式上可能存在差异，但在NUMA系统上共享内存的线程/进程差异方面的差异较小——尽管当前的内核可能支持在不同的NUMA区域复制代码段（他们过去确实支持内核本身）.谢谢您对文档的参考，非常有帮助。我相信线程更快的感觉来自于早期的Windows环境，它可以从头创建完整的进程，而不像Linux fork，它只是复制堆栈，最初子进程和父进程共享相同的内存段。我认为，除非进行exec调用，否则代码将继续在所有子进程和父进程之间共享。