遇到"Too many open files"报错，最稳妥的做法是分层调整：先临时用 ulimit 验证，再永久修改 limits.conf 和 systemd 配置，最后检查内核级 fs.file-max 上限，三者缺一不可。

命令速用版

临时提升当前会话限制（退出失效）：

ulimit -Sn 65535
ulimit -Hn 65535

查看系统全局上限：

cat /proc/sys/fs/file-max

查看某进程已打开文件数：

ls /proc/<pid>/fd | wc -l

为什么会这样

Linux 对文件描述符的限制分为软限制（soft limit）和硬限制（hard limit）。软限制是进程实际遵守的值，硬限制是软限制的上限。普通用户只能降低硬限制或在硬限制范围内调高软限制，只有 root 能提升硬限制。此外，限制生效分多层：当前 Shell 会话、用户登录会话（PAM）、systemd 服务配置、内核全局上限。只改其中一层，其他层卡住依然会报错。

分步处理

1. 临时调整（调试用）
在当前终端执行ulimit -n 65535。若报错"Operation not permitted"，需先用 root 执行ulimit -Hn 65535提升硬限制。注意这只对当前 Shell 及其子进程有效，重启服务无效。

2. 永久调整用户级限制
编辑/etc/security/limits.conf，添加：
* soft nofile 65535
* hard nofile 65535
确保/etc/pam.d/common-session包含session required pam_limits.so。修改后需重新登录用户或重启服务。

3. 适配 systemd 服务（关键）
systemd 管理的服务不读 limits.conf。执行systemctl edit nginx.service（替换为实际服务名），写入：
[Service]
LimitNOFILE=65535
执行systemctl daemon-reload并重启服务。

4. 调整内核全局上限
若并发极高，需调大fs.file-max。编辑/etc/sysctl.conf添加fs.file-max = 2097152，执行sysctl -p生效。

怎么验证是否生效

不要只看ulimit -n，要看运行中进程的实际限制。执行cat /proc/<pid>/limits | grep "Max open files"，确认"Soft Limit"和"Hard Limit"均已更新。对于 systemd 服务，可用systemctl show 服务名 | grep LimitNOFILE确认配置已加载。

常见坑

1. service 未继承限制：用sudo -u user cmd启动服务不触发 PAM 登录，limits.conf 不生效，必须在 systemd 中配 LimitNOFILE。
2. 只改软限制：若硬限制仍为 1024，软限制无法调高，需同步提升硬限制。
3. 未重新登录：修改 limits.conf 后，已登录的会话不会自动更新，需退出重登或重启服务进程。
4. 容器环境：容器内进程受宿主机和容器 runtime 双重限制，docker run 时需加`--ulimit` nofile=65535:65535。

参考来源

• 如何在 Linux 利用 Ulimit 调整系统最大打开文件数限制解决并发瓶颈
• 怎么在 Linux 利用 Ulimit 调整系统最大打开文件数限制解决高并发瓶颈
• Linux 系统资源限制工具 Ulimit 设置进程打开文件数指南
• Linux 系统如何修改最大文件打开数？解决 ulimit 报错限制【教程】
• Linux 打开文件数 too many open files 的解决办法是哪个命令
• linux 怎么修改最大文件限制_linux 优化内核参数【指南】
• Linux 新手必看：解决'Too many open files'错误的完整指南
• 关于 linux too many open files 的解决方案
• Linux 怎么设置文件描述符上限_Linux limits.conf 配置教程【性能】
• linux 查看/修改各种资源限制 ulimit