Linux怎么修改文件最大连接数 Linux系统级句柄限制优化详解

在Linux服务器调优时，文件描述符（句柄）限制是个老生常谈却又常调常新的问题。很多工程师都遇到过这样的困惑：明明按照教程改了配置，为什么服务还是报“Too many open files”？今天，我们就来把这个问题彻底拆解清楚。

ulimit -n 为什么改了没生效

你是不是也试过，在终端里自信地敲下 ulimit -n 65535，结果新启动的进程一查，限制还是可怜的1024？别急，这几乎是每个运维都会踩的第一个坑。

关键在于理解 ulimit 命令的作用范围。它只对当前shell会话及其后续创建的子进程有效。你关掉终端，或者换个新窗口，这个设置就没了。更关键的是，这里还有个“软限制”和“硬限制”的上下级关系：软限制不能超过硬限制。而硬限制的默认值，通常由PAM（可插拔认证模块）在用户登录时设定，如果没在系统级配置文件里动过，它往往卡在4096甚至更低。

所以，下次调优前，不妨按这个顺序排查：

• 先看天花板有多高：运行 ulimit -Hn 查看硬限制。如果你的目标是65535，而这里显示4096，那么你设置软限制到65535的命令注定会失败。
• 临时拔高天花板：如果需要临时测试，可以用root权限执行 sudo ulimit -Hn 65535。但记住，这仅限当前会话。
• 永久生效靠配置：对于普通用户，想永久提升硬限制，必须去修改 /etc/security/limits.conf 这个文件，并且重新登录用户才会加载新配置。
• 警惕“特权”进程：还有一个大坑：通过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) 找到进程，再核对 /proc/[PID]/limits 里的信息。

systemd 服务的 NOFILE 限制要单独处理

现代Linux服务器上，绝大多数服务都由systemd管理。这里有个至关重要的知识盲区：limits.conf 对 systemd 服务完全无效。你用 systemctl start nginx 启动的服务，其资源限制由systemd自己的一套规则控制。

所以，当你调优Nginx、Redis、MySQL这些服务时，需要另辟蹊径：

• 全局修改（影响所有systemd服务）：编辑 /etc/systemd/system.conf 文件，找到 DefaultLimitNOFILE 这一行，取消注释并将其值改为 65535。
• 单独修改（只影响特定服务）：更推荐这种方式。找到对应服务的unit文件（例如 /etc/systemd/system/nginx.service 或 /lib/systemd/system/nginx.service），在 [Service] 段落里添加一行：LimitNOFILE=65535。
• 修改后必须重载：改完systemd的配置，一定要执行 sudo systemctl daemon-reload 让systemd重新读取配置，然后再重启服务：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（比如Nginx监听的80端口）的“全连接队列”的最大长度，直接影响高并发下的连接建立成功率。

它们不直接等同，但必须协同工作。如果 fs.file-max 设得太小，即便每个进程都能开6万多个句柄，系统总资源也会很快耗尽。而如果 net.core.somaxconn 太小，在连接瞬间暴涨时，新连接会在内核队列里等待超时后被丢弃，表现出来的错误可能是“连接被拒绝”，而不是“打开文件过多”。

调整建议如下：

• fs.file-max：建议设置为你的服务器预期承载的最大并发连接数 × 1.2 到 1.5 倍。例如，计划支撑10万并发，可以设为1200000。
• net.core.somaxconn：这个值应该大于等于你单个服务（如Web服务器）预期会达到的瞬时并发连接峰值。对于现代Web服务，设置为65535是常见的起点。
• 永久生效：通过 sysctl -w 命令修改是临时的。务必把配置（如 fs.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为服务设定的限制——这三者的值完全可能不一样。真正的调优高手，一定会分层验证，而不是只看一个命令的输出就下结论。