打开 100 万个连接最高可达 469K

Question

我需要配置服务器来处理超过一百万个打开的 websocket 连接（最好是两百万）。

我使用了这篇博文中的配置：

sysctl -w fs.file-max=12000500
sysctl -w fs.nr_open=20000500
ulimit -n 20000500
sysctl -w net.ipv4.tcp_mem='10000000 10000000 10000000'
sysctl -w net.ipv4.tcp_rmem='1024 4096 16384'
sysctl -w net.ipv4.tcp_wmem='1024 4096 16384'
sysctl -w net.core.rmem_max=16384
sysctl -w net.core.wmem_max=16384

但是，我的应用程序在达到 469219 个连接后停止应用新连接。我错过了什么？我真的认为操作系统配置中缺少某些东西。我们的主要应用程序是用 Java 编写的（使用 Tomcat 服务器），但我使用 NodeJS 服务器也得到了非常相似的结果。

我们使用 16GB RAM 的 Ubuntu。

编辑：在高峰期系统使用大约 12Gb 的 14.7Gb。

更新：

所以最后我有了 32GB 的工作站。通过增加 RAM 空间解决了问题。目前使用 18GB Java 堆，我能够处理 567K WS 连接。对于更高的数字，我需要更多的客户:-)

Answer 1

不一定是答案，但太大而无法发表评论。

tcp_mem (since Linux 2.4)
      This  is  a vector of 3 integers: [low, pressure, high].  These bounds, measured in units of the system page size, are used by
      TCP to track its memory usage.  The defaults are calculated at boot time from the amount of available memory.  (TCP  can  only
      use  low memory for this, which is limited to around 900 megabytes on 32-bit systems.  64-bit systems do not suffer this limi-
      tation.)

      low       TCP doesnât regulate its memory allocation when the number of pages it has allocated globally is below this  number.

      pressure  When the amount of memory allocated by TCP exceeds this number of pages, TCP moderates its memory consumption.  This
                memory pressure state is exited once the number of pages allocated falls below the low mark.

      high      The maximum number of pages, globally, that TCP will allocate.  This value overrides any other limits imposed by the
                kernel.

请注意以下事项：

这些边界，以系统页面大小为单位

将该值设置10000000 10000000 10000000为向内核声明为 TCP 使用 39062 MiB 内存。几乎是你所拥有的三倍。

第二个问题是 TCP 的 3 个值rmem，wmem您可以设置定义最小值、默认值和最大值。鉴于您的 tcp_mem 配置声明您永远不会进入“内存节省”模式，我想您实际上为每个套接字分配了 4-16k 之间的某个地方。

所以，如果我是内核并且我看到了如此疯狂的设置，我的行为也可能无法预料。

尝试将该值降低到您可以实际使用的值，然后再试一次。

最后，我要指出，如果你真的相信：

1. 内核将支持 200 万个连接。
2. Node 或 java 可以轻松支持 200 万个连接。

即使在最好的情况下（使用 epoll 集），一个 epoll 集中的 200 万个条目也是昂贵的。这永远不会发生在 worker 或 prefork 模型上。

您需要更均匀地分布此负载。您可能至少需要另外 10 个节点才能获得值得用户称之为服务的任何东西。