“too many open files”错误本质是文件描述符耗尽，需分层解决：会话级（ulimit临时调整）、用户级（/etc/security/limits.conf永久设置软硬限制）、系统级（/etc/sysctl.conf调大fs.file-max），并注意systemd服务需显式配置limitnofile。
Linux中“Too many open files”错误本质是文件描述符（fd）耗尽，常见于高并发Web服务、数据库或消息队列场景。解决它不能只调一个值，需分层处理：会话级、用户级、系统级，三者缺一不可。关键在于理解软限制（实际生效值）和硬限制（软限制的上限），以及不同启动方式对限制的继承逻辑。
查清当前限制在哪一层卡住
先定位瓶颈位置，避免盲目修改：
- 查看当前shell软限制：ulimit -Sn；硬限制：ulimit -Hn
- 切换到目标用户验证（如www-data）：su - www-data -c 'ulimit -n'
- 查系统总容量：cat /proc/sys/fs/file-max
- 查某进程实际用了多少fd：ls /proc/
/fd | wc -l
若服务日志报错但ulimit -n显示65535，大概率是服务未继承限制——比如用sudo -u user cmd启动，或systemd服务未显式配置。
临时调高：快速验证是否有效
仅对当前终端及其子进程生效，适合调试：
- 提升软限制：ulimit -Sn 65535
- 如需同步提升硬限制（root权限下）：ulimit -Hn 65535
注意：该操作不重启服务无效，已运行的进程不受影响。
永久生效：用户级靠limits.conf
编辑/etc/security/limits.conf，添加对应用户规则：
- 对所有非root用户统一设限：* soft nofile 65535 和 * hard nofile 65535
- 单独为服务用户设限（如nginx用www-data）：www-data soft nofile 65535 和 www-data hard nofile 65535
- 确保PAM加载模块：检查
/etc/pam.d/common-session含session required pam_limits.so，无则添加
生效前提：用户需重新登录，或重启对应服务（不是systemctl restart，而是完整退出再启动进程）。
绕过systemd陷阱：服务必须显式声明
systemd默认忽略limits.conf，必须在unit文件中定义：
- 创建覆盖配置：sudo systemctl edit nginx.service
- 填入：
[Service] LimitNOFILE=65535
- 重载并重启：sudo systemctl daemon-reload && sudo systemctl restart nginx
- 确认生效：systemctl show nginx --property LimitNOFILE
若服务以root启动后降权（如nginx主进程root、worker用www-data），LimitNOFILE仍需设在unit中，且值要覆盖worker所需。
系统级兜底：扩大内核总池子
单个进程限制再高，也受限于内核全局上限：
- 临时调整：sudo sysctl -w fs.file-max=1048576
- 永久生效：向
/etc/sysctl.conf追加fs.file-max = 1048576，再执行sudo sysctl -p
该值建议设为单进程最大值 × 预期并发进程数 × 1.2，留出余量，避免OOM。
