85

有谁知道现代标准 Linux 服务器上可能有多少个 tcp-socket 连接?

(通常每个连接上的流量较少,但所有连接都必须一直处于运行状态。)

4

8 回答 8

89

我在 Linux 桌面(16G RAM,I7 2600 CPU)上实现了 1600k 并发空闲套接字连接,同时实现了 57k req/s。它是用 C 语言编写的带有 epoll 的单线程 http 服务器。源代码在github 上,这里有一个博客

编辑:

我在同一台计算机上使用 JAVA/Clojure 进行了 600k 并发 HTTP 连接(客户端和服务器)。详细信息帖子,HN 讨论: http://news.ycombinator.com/item?id= 5127251

连接的成本(使用 epoll):

  • 应用程序每个连接需要一些 RAM
  • TCP 缓冲区 2 * 4k ~ 10k,或更多
  • epoll 需要一些内存来存储文件描述符,来自 epoll(7)

每个注册的文件描述符在 32 位内核上大约需要 90 个字节,在 64 位内核上大约需要 160 个字节。

于 2012-03-13T00:45:32.160 回答
24

这不仅取决于所讨论的操作系统,还取决于配置,可能是实时配置。

对于 Linux:

cat /proc/sys/fs/file-max

将显示当前允许同时打开的最大文件描述符总数。查看http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html

于 2009-03-16T19:04:59.947 回答
9

10,000?70,000?这就是全部 :)

FreeBSD 可能是您想要的服务器,这里有一篇关于调整它以处理 100,000 个连接的小博客文章,它有一些有趣的功能,例如零拷贝套接字,以及作为完成端口机制的 kqueue。

上个世纪的Solaris 可以处理 100,000 个连接!他们说linux会更好

我遇到的最好的描述是这个关于编写可扩展网络服务器的演示文稿/论文。他不怕这样说:)

软件也是如此:应用层的白痴迫使操作系统层进行了巨大的创新。由于 Lotus Notes 保持每个客户端打开一个 TCP 连接,IBM 为 Linux 的“一个进程,100.000 个打开的连接”案例做出了重大优化

O(1) 调度程序最初是为了在一些不相关的 Java 基准测试中取得好成绩而创建的。最重要的是,这种膨胀对我们所有人都有好处。

于 2009-05-30T15:49:52.017 回答
9

在 /proc 文件系统中可以配置打开套接字的数量限制

cat /proc/sys/fs/file-max

操作系统中由整数限制定义的传入连接的最大值。

Linux 本身允许数十亿个打开的套接字。

要使用套接字,您需要一个应用程序监听,例如一个 Web 服务器,并且每个套接字将使用一定数量的 RAM。

RAM 和 CPU 将引入真正的限制。(现代 2017 年,想想数百万而不是数十亿)

100万是可能的,不容易。预计将使用 X GB 的 RAM 来管理 100 万个套接字。

传出TCP 连接受每个 IP 约 65000 个端口号的限制。您可以拥有多个 IP 地址,但不能拥有无限的 IP 地址。这是 TCP 而非 Linux 中的限制。

于 2017-04-09T11:03:11.650 回答
5

在 Linux 上,您应该考虑使用 epoll 进行异步 I/O。可能还值得微调套接字缓冲区,以免每个连接浪费太多内核空间。

我猜你应该能够在一台合理的机器上达到 10 万个连接。

于 2009-03-17T18:09:10.790 回答
3

取决于应用程序。如果每个客户端只有几个包,那么 100K 对于 linux 来说非常容易。我团队的一位工程师多年前做过一个测试,结果显示:当连接建立后没有来自客户端的包时,linux epoll 可以在 cpu 使用率低于 50% 的情况下观察 400k fd 的可读性。

于 2011-11-27T14:52:34.007 回答
1

哪个操作系统?

对于 Windows 机器,如果您正在编写一个可扩展的服务器,因此使用 I/O 完成端口和异步 I/O,那么主要限制是您用于每个活动连接的非分页池的数量. 这直接转化为基于您的机器已安装的内存量的限制(非分页池是基于安装的总内存的有限、固定大小的量)。

对于没有看到太多流量的连接,您可以通过发布不使用非分页池且不影响锁定页面限制的“零字节读取”来减少它们的效率(另一个可能会阻止您的潜在有限资源)有很多套接字连接打开)。

除此之外,你还需要进行分析,但我已经设法在一个适度指定的(760MB 内存)服务器上获得了超过 70,000 个并发连接;有关更多详细信息,请参见此处 http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html

显然,如果您使用的是效率较低的架构,例如“每个连接的线程”或“选择”,那么您应该期望获得不那么令人印象深刻的数字;但是,恕我直言,没有理由为 Windows 套接字服务器选择这样的架构。

编辑:见这里http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx;在 Vista 和 Server 2008 中计算非分页池数量的方式发生了变化,现在可用的数量更多。

于 2009-03-16T22:15:42.810 回答
-12

实际上,对于一个应用程序,单台机器上超过 4000-5000 个打开的套接字变得不切实际。仅仅检查所有套接字上的活动并对其进行管理就开始成为一个性能问题——尤其是在实时环境中。

于 2009-03-16T19:43:19.900 回答