Swoole中max_connection与系统ulimit的区别

在 Swoole 的日常调优里，max_connection 和 ulimit -n 这两个参数常常让人摸不着头脑。很多人把它们划等号，结果发现服务要么启动不了，要么连接数怎么也上不去。今天就来彻底掰扯清楚：max_connection 到底是管哪一头的，它跟系统的 ulimit 究竟怎么配合，以及踩坑之后怎么对症下药。

max_connection 是 Swoole 自己的连接数上限

max_connection（或者叫 max_conn）是 Swoole Server 实例级别的配置项，控制的是当前这个 Swoole 进程最多能维持多少个活跃的 TCP 连接。它在底层干的活是：预分配内存块（比如 swConnection 结构体数组），并且参与 session ID 映射、连接统计等内部管理。

注意一个关键点：它不直接决定“能不能 accept 新连接”，而是影响“accept 之后能不能成功注册进事件循环”。如果设得太小，Swoole 启动时会报错 serv->max_connection is too small，然后自动帮你修正为系统 ulimit -n 的值。反过来，如果设得太大（比如超过 100 万），在 4.2.9+ 版本中，底层会直接截断到 10000，省得预分配内存过大导致 OOM。

ulimit -n 是操作系统对单进程打开文件描述符的硬限制

Linux 上每个 TCP 连接都占用一个文件描述符（fd），Swoole 的每个连接也不例外。所以 ulimit -n 就是 Swoole 能达到 max_connection 的物理天花板。

常见的错误现象很典型：

• 明明设了 'max_conn' => 65535，结果只收到大概 1024 个连接就卡住不动了。
• 日志里反复出现 accept(): Too many open files 或 Too many open files (errno=24)。
• 用 lsof -p $PID | wc -l 查到 fd 数已经逼近 ulimit -n 的输出值。

这时候不是 Swoole 配置错了，而是系统没放开限制。必须先用 ulimit -n 65536（临时生效），或者在 systemd service 文件里配 LimitNOFILE=65536（持久化）。

两者不匹配时 Swoole 会怎么处理

Swoole 在启动阶段会做一次校验，具体怎么处理要看版本和数值关系：

• 如果 max_conn > ulimit -n：输出警告 WARN swServer_start_check: serv->max_conn is exceed the maximum value[...]，然后强制重置为 ulimit -n 的值。
• 如果 max_conn < 10：直接触发 fatal error，拒绝启动。
• 如果 ulimit -n 设得极高（比如 100 万），而 Swoole 版本 ≥ 4.2.9，那么 max_conn 会被静默限制到 10000——这是为了防止预分配内存过大导致 OOM。

一句话总结：max_conn 是你“想管多少”，ulimit -n 是系统“准你管多少”。Swoole 会在中间强行拉齐，并且优先服从系统限制。

为什么不能只调大 ulimit 就完事

光把 ulimit -n 调高，不等于服务就能撑住高并发。原因在于：

• Swoole 每个连接固定占用大约 224 字节（1.9.16+ 版本），10 万连接就是 22MB 内存，这还只是连接元数据。加上协程栈、buffer、task worker 的开销，总内存增长是非线性的。
• 内核的 socket backlog 队列（net.core.somaxconn）如果太小，新连接在进入 accept 之前就被丢弃了，客户端会表现为 connect timeout。
• 没有启用 enable_reuse_port 时，多个 worker 共享一个 listen fd，高并发下容易出现 accept 饥饿。这时候即使 ulimit 和 max_conn 都够，连接也无法均匀分发。

所以，真正要压测出稳定连接数，得同步检查三处：Swoole 的 max_conn、系统的 ulimit -n、内核的 net.core.somaxconn，缺一不可。其中最容易被忽略的是 somaxconn，它默认值通常只有 128，远低于大部分业务预期的连接数。