怎么在Linux利用Ulimit调整硬限制防止进程耗尽资源-linux运维-PHP中文网

普通用户无法提升ulimit -h硬限制，仅root或cap_sys_resource进程可调高；需通过/etc/security/limits.conf（登录会话）、systemd limitnofile（服务）、docker --ulimit（容器）等分场景配置。

怎么在linux利用ulimit调整硬限制防止进程耗尽资源

普通用户无法提升硬限制（hard limit），ulimit -H 只能降低或维持当前值，不能越过系统级上限。真正能调高硬限制的，只有 root 或具备 CAP_SYS_RESOURCE 能力的进程。

常见错误现象：ulimit -Hn 65536 执行后没报错，但再查仍是旧值；或者直接提示 Operation not permitted。

检查当前硬限制：运行 ulimit -Hn
确认是否为 root：非 root 用户想提上限，必须让管理员提前在 /etc/security/limits.conf 或 /etc/security/limits.d/*.conf 里配好 * soft nofile 65536 和 * hard nofile 65536
注意 PAM 加载顺序：确保 pam_limits.so 已在 /etc/pam.d/common-session（Debian/Ubuntu）或 /etc/pam.d/login（RHEL/CentOS）中启用

* 匹配的是“登录用户”，不是所有进程；systemd 服务、cron 任务、SSH 非登录 shell 默认不读取 limits.conf —— 它们走的是不同加载路径。

使用场景：Web 服务器（如 Nginx）、数据库（如 MySQL）常因打开文件数不足报 Too many open files，这类问题必须按实际运行用户配，而不是笼统用 *。

ulimit -n 只影响当前 shell 及其后续 fork 出的子进程，不会 retroactively 修改已存在的进程，也不能穿透 execve 的资源重置逻辑。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

性能影响：设太高不一定好。Linux 内核为每个打开文件维护 struct file，过多 fd 会增加 slab 分配压力和 close() 系统调用开销；某些老版本 glibc 在遍历 fd 表时还有 O(n) 行为。

临时调试可用：ulimit -Sn 65536; ulimit -Hn 65536; ./myserver
不要在脚本开头写 ulimit -n 1048576 就以为万事大吉 —— 如果脚本里又 exec 了别的程序，它可能重置为默认值
验证是否生效：启动后进进程 namespace，查 /proc/<pid>/limits</pid> 中 Max open files 行，比看 ulimit -n 更可靠

systemd 忽略 /etc/security/limits.conf，它用自己的资源控制体系。哪怕你在 limits.conf 里配了 root 的 hard nofile，nginx.service 依然可能卡在 1024。

兼容性影响：RHEL 7+、Ubuntu 16.04+ 默认用 systemd，老教程教改 limits.conf 对服务基本没用。

编辑 service 文件：sudo systemctl edit nginx.service
写入：
```
[Service]
LimitNOFILE=65536
```
重载并重启：sudo systemctl daemon-reload && sudo systemctl restart nginx
注意：如果服务用了 RuntimeDirectoryMode=0755 类似配置，也要同步检查 LimitCORE、LimitAS 是否需要调整，避免被其他限制间接触发 OOM

硬限制这事，本质是层层拦截：内核有 fs.nr_open 全局上限，systemd 有 per-unit 限制，PAM 有登录会话限制，应用自己还可能调 setrlimit() 锁死。漏掉任何一层，都可能在某个深夜收到 “Too many open files” 告警。