Linux修改文件最大连接数：系统级句柄限制优化指南

在Linux服务器性能优化过程中，文件描述符（句柄）限制是一个常见且关键的问题。许多工程师都曾遇到配置后服务仍报“Too many open files”错误的情况。本文将系统性地解析此问题及其解决方案。

ulimit -n 命令修改后未生效的原因

执行 ulimit -n 65535 后，新进程的限制可能仍是默认的1024。这通常是因为对 ulimit 命令的作用范围理解有误。

ulimit 的设置仅对当前shell会话及其创建的子进程有效。关闭终端或开启新会话，设置便会失效。此外，还需区分“软限制”与“硬限制”：软限制不能超过硬限制。硬限制的默认值通常由PAM（可插拔认证模块）在用户登录时设定，若未在系统级配置中修改，其值可能仅为4096或更低。

调整前建议按以下顺序排查：

• 查看硬限制上限：执行 ulimit -Hn 查看当前硬限制。若目标值为65535而此处显示4096，则设置软限制为65535的命令将失败。
• 临时提高硬限制：可使用root权限执行 sudo ulimit -Hn 65535 进行临时测试，但此设置仅对当前会话有效。
• 通过配置文件永久生效：要为普通用户永久提升限制，需修改 /etc/security/limits.conf 文件，并重新登录用户以使配置加载。
• 注意systemd服务：由systemd管理的服务（如Nginx、Redis）不通过PAM加载限制，因此 limits.conf 对其无效。此问题将在后续详细说明。

/etc/security/limits.conf 配置不生效的常见原因

在 limits.conf 中添加了 * soft nofile 65535 和 * hard nofile 65535 后，限制可能仍未改变。这通常是由于PAM模块未正确加载所致，该文件需由PAM读取并应用。

主要检查点如下：

• 确认PAM模块启用：检查 /etc/pam.d/common-session 或 /etc/pam.d/system-auth 文件（取决于发行版，如CentOS 7+常用后者），确保包含 session required pam_limits.so 且未被注释。
• 注意配置优先级：limits.conf 的匹配具有顺序性。若同时使用通配符 * 和特定用户（如 www-data）设置，PAM将采用首个匹配的规则。特定用户规则可能覆盖通配符规则。
• 彻底重新登录：修改 limits.conf 后，需完全退出当前用户登录状态（如断开SSH重连，或图形界面注销再登录），而非仅关闭终端窗口。
• 正确验证设置：登录后，直接运行 ulimit -n 查看。对于已运行进程，可通过 ps -o pid,uid,comm -u $(whoami) 查找进程ID，然后检查 /proc/[PID]/limits 文件中的信息。

单独处理systemd服务的NOFILE限制

在现代Linux服务器上，多数服务由systemd管理。需特别注意：limits.conf 对systemd服务无效。通过 systemctl start 启动的服务，其资源限制由systemd自身规则控制。

调整Nginx、Redis、MySQL等服务的限制时，需采用以下方法：

• 全局修改（影响所有systemd服务）：编辑 /etc/systemd/system.conf 文件，找到并取消注释 DefaultLimitNOFILE 行，将其值改为 65535。
• 单独修改（针对特定服务）：此方式更推荐。找到对应服务的unit文件（如 /etc/systemd/system/nginx.service），在 [Service] 段落添加 LimitNOFILE=65535。
• 修改后重载配置：更改systemd配置后，必须执行 sudo systemctl daemon-reload 以重新读取配置，随后重启服务：sudo systemctl restart nginx。
• 使用正确命令验证：验证时不应使用 ulimit。正确的命令是：systemctl show nginx | grep LimitNOFILE，或直接查看进程内核限制：cat /proc/$(pidof nginx)/limits | grep "Max open files"。

fs.file-max 与 net.core.somaxconn 的协同配置

解决进程级限制后，还需关注系统级内核参数：

• fs.file-max：定义系统可打开的文件句柄总数上限，是所有进程共享的资源池。
• net.core.somaxconn：定义单个监听socket的“全连接队列”最大长度，直接影响高并发下的连接建立成功率。

两者需协同工作。若 fs.file-max 设置过小，系统总资源将迅速耗尽。若 net.core.somaxconn 过小，在连接激增时，新连接可能在内核队列中等待超时后被丢弃，表现为“连接被拒绝”而非“打开文件过多”。

调整建议如下：

• fs.file-max：建议值设置为服务器预期最大并发连接数 × 1.2 至 1.5 倍。例如，计划支撑10万并发，可设为1200000。
• net.core.somaxconn：此值应大于等于单个服务（如Web服务器）预期的瞬时并发峰值。对于现代Web服务，常设置为65535。
• 使配置永久生效：通过 sysctl -wfs.file-max = 1200000）写入 /etc/sysctl.conf 文件，然后执行 sudo sysctl -p 以应用并持久化。
• 云主机特别注意：部分云服务商（如AWS EC2）的默认 fs.file-max 值可能较低（例如65536），在高并发场景下会成为瓶颈，务必检查并调整。

最后需明确排查思路：Linux资源限制是分层的。ulimit -n 显示当前shell的软限制，/proc/[PID]/limits 显示特定进程的实际限制，systemctl show 则显示systemd为服务设定的限制——三者可能不同。有效的调优需进行分层验证，而非依赖单一命令的输出。