“too many open files”错误源于内核级、系统级和用户级文件描述符限制过低，需同步调整ulimit（/etc/security/limits.conf）、fs.file-max（/etc/sysctl.conf）及systemd服务limitnofile三者，缺一不可。
服务器遇到“Too many open files”错误，核心原因通常是内核级和用户级的文件描述符（file descriptor）限制过低。调整不是改一个参数就行，得按层级逐项确认和设置：用户进程上限、系统总容量、内核硬边界，三者缺一不可。
查清当前各层限制值
先别急着改，用几条命令快速定位瓶颈点：
- 当前 shell 的软/硬限制：ulimit -Sn（软）和 ulimit -Hn（硬）
- 当前系统总上限：cat /proc/sys/fs/file-max
- 单进程理论最大值：cat /proc/sys/fs/nr_open（默认约 1048576，一般不用动）
- 检查是否已生效：prlimit -n $PID（替换为实际进程 PID）
永久修改用户级文件数限制
这是最常被忽略但影响最直接的一环。所有普通用户（包括服务运行账户如 www-data、redis）都受此约束。
- 编辑 /etc/security/limits.conf，追加（以通配符为例）：
* soft nofile 65535
* hard nofile 65535 - 确保 PAM 加载 limits 模块：检查 /etc/pam.d/common-session 是否含 session required pam_limits.so；若无，添加该行
- 注意：root 用户默认不走 limits.conf，如需调整 root，显式写 root soft nofile 65535 等
- 修改后需重新登录或重启对应服务（如 systemd 服务需 reload）才生效
提升系统级总文件描述符上限
这个值必须 ≥ 所有进程 nofile 之和，否则即使用户设再高也无效。
- 临时生效：sudo sysctl -w fs.file-max=1048576
- 永久生效：向 /etc/sysctl.conf 追加一行：fs.file-max = 1048576
- 立即加载新配置：sudo sysctl -p
- 建议值：对于中高并发服务（如 Nginx、Redis、Java 应用），设为 100 万较稳妥
适配 systemd 服务的特殊处理
systemd 托管的服务（如 nginx.service、redis-server.service）默认不读取 limits.conf，必须单独配置。
- 执行 sudo systemctl edit nginx.service（替换成你的服务名）
- 在打开的 override 文件中写入：[Service]
LimitNOFILE=65535 - 保存后重载并重启：sudo systemctl daemon-reload && sudo systemctl restart nginx
- 全局设置（适用于所有服务）：编辑 /etc/systemd/system.conf，取消注释并修改 DefaultLimitNOFILE=65535
