Linux系统资源限制配置方案：从零上手防OOM与连接数爆满

什么时候需要调整Linux资源限制？

服务器运行一段时间后，可能会报“Too many open files”或者“cannot fork – resource temporarily unavailable”这类错误。
这通常是资源限制太低导致的。
每个进程能打开的文件数、能创建的子进程数、能占用的内存等都有默认上限。
本篇 Linux系统资源限制配置方案 会帮你理清从哪里改、怎么改、改完怎么验证，避免服务因资源瓶颈意外中断。

准备工作：确认当前限制与需要修改的文件

操作前先登录服务器（SSH），所有命令都通过终端执行。
你需要知道两项信息：

1. 当前用户的资源限制：运行 ulimit -a 查看全部。重点关注 open files（文件句柄数）和 max user processes（最大进程数）。
2. Linux系统级限制文件：/etc/security/limits.conf，这是PAM模块加载的核心配置。如果你用的是Systemd服务（比如Nginx、MySQL等由systemctl管理），还需要修改对应的service文件。

另外确认系统版本（cat /etc/os-release），CentOS 7+、Ubuntu 18+ 操作大同小异。

核心操作：三步完成资源限制配置

第一步：通过ulimit临时调整（仅当前会话生效）

快速测试时可以用。
例如把文件句柄数改为65535：

ulimit -n 65535

查看是否生效：ulimit -n。
注意重启终端或退出SSH就会重置，仅用来验证新数值是否让程序正常运行。

第二步：修改limits.conf实现永久生效

编辑 /etc/security/limits.conf：

sudo vi /etc/security/limits.conf

在文件末尾添加（以root和www用户为例，你可以替换成你的运行用户）：

*               soft    nofile         65535
*               hard    nofile         65535
*               soft    nproc          65535
*               hard    nproc          65535
root            soft    nofile         65535
root            hard    nofile         65535

• * 代表所有用户，root 单独再写一遍确保覆盖。
• soft 是软限制，hard 是硬限制，一般设相同值。
• nofile 是文件句柄数，nproc 是用户进程数。

保存后退出。
然后编辑 /etc/pam.d/common-session（Debian/Ubuntu）或 /etc/pam.d/login（CentOS），确保包含：

session required pam_limits.so

一般默认就有，如果没有就加上。

第三步：针对Systemd服务单独配置

对于用 systemctl 管理的服务（如 nginx、mysql），limits.conf 可能不生效。
需要修改service文件：

sudo systemctl edit nginx

在弹出的编辑器中添加：

[Service]
LimitNOFILE=65535
LimitNPROC=65535

保存后重启服务：

sudo systemctl daemon-reload
sudo systemctl restart nginx

查看是否生效：

cat /proc/$(pgrep -x nginx | head -1)/limits | grep "Max open files"

避坑指南：改了不生效的常见原因

• 重启了终端但没重新登录？ limits.conf 只在新登录会话生效，当前SSH窗口需要退出重新连。
• nproc修改无效？ 有些系统对 nproc 有上限，比如CentOS 7默认限制 /etc/security/limits.d/20-nproc.conf，查看并修改该文件，把*用户的nproc调大。
• Docker容器内修改？ 容器运行时资源限制需要在docker run时加 --ulimit 参数，或者在宿主机上改完重启容器。
• 不要忘记改系统内核参数？ 文件句柄全局最大值受 fs.file-max 控制，运行 cat /proc/sys/fs/file-max 查看，如果小于你要设置的nofile，需要编辑 /etc/sysctl.conf 添加 fs.file-max=1000000 然后 sysctl -p。

效果验证：怎么确认修改成功

1. 重新登录SSH，运行 ulimit -n 和 ulimit -u（-u 显示进程数），看数值是否变成65535。
2. 对于正在运行的服务，用 cat /proc//limits 查看实际限制。
3. 压力测试：用 ab 或 wrk 模拟高并发，观察是否还有“Too many open files”报错。
4. 检查系统日志：dmesg | tail 或 journalctl -xe，看是否有OOM killer或资源不足信息。

常见问题解答

Q：修改/security/limits.conf后需要重启服务器吗？
不需要。用户重新登录或服务重启即生效。

Q：给Nginx设置了65535，但还是报错怎么办？
检查Nginx worker_connections配置，配合 worker_rlimit_nofile 指令也在nginx.conf里设置大值。同时确认系统全局 fs.file-max 足够。

Q：修改后影响性能吗？
设置合理的高限不会降低性能，反而有助于处理突发流量。但无限制开太多文件可能耗尽内存，建议结合实际业务调整。

写在最后

Linux系统资源限制配置方案 是服务器稳定性的基础。
先从 ulimit -a 看清当前值，再按本文步骤依次配置limits.conf和Systemd限制，最后验证生效。
遇到问题先检查日志和 /proc 下的实际限制。
这套方法适用于大部分生产环境，记得根据用户和业务特点微调数值。