too-many-open-files

文件描述符耗尽的定位与修复

现象

应用报 Too many open files、EMFILE，新连接无法建立，日志写入失败。accept()、open()、socket() 都可能返回错误。

快速定位

ulimit -n
cat /proc/<pid>/limits | grep 'open files'
ls /proc/<pid>/fd | wc -l
lsof -p <pid> | wc -l
lsof -p <pid> | awk '{print $5}' | sort | uniq -c | sort -rn | head
cat /proc/sys/fs/file-nr
ss -s

systemd 服务：

systemctl show <service> -p LimitNOFILE
systemctl status <service>

常见根因

1. 连接或文件句柄未关闭，常见于连接池、HTTP 客户端和日志句柄。
2. ulimit -n 或 systemd LimitNOFILE 太小。
3. 容器运行时默认 nofile 限制偏低。
4. 大量短连接没有复用，或 TIME_WAIT 堆积。
5. inotify、epoll 等也占用描述符，监控工具会放大占用。

修复

• 先用 lsof 看 fd 类型和增长趋势，确认是泄漏还是上限问题。
• 修代码：确保 finally 关闭、连接池有上限、复用长连接。
• 提高限制：shell 用 ulimit -n，服务用 systemd LimitNOFILE，容器用 --ulimit nofile=。
• 修改 /etc/security/limits.conf 只影响登录会话，不一定会作用于 systemd 服务。
• 调整后重启进程，确认 /proc/<pid>/limits 已生效。

相关命令

• lsof — 查看进程打开的文件
• ss — 套接字统计
• prlimit — 查看和设置进程资源限制
• systemctl — 服务限制

读完自测

合上页面，先回答，再展开对照。

1. 如何区分是文件描述符泄漏还是限制太小？
2. 为什么修改 /etc/security/limits.conf 可能对 systemd 服务无效？
3. 调整限制后如何确认真的生效？