如何解决缓存文件写盘时引发的Linux内核文件描述符耗尽-Nginx-PHP中文网

缓存文件写盘触发“Too many open files”错误，本质是密集打开临时文件、日志、压缩流等导致FD耗尽；需三层协同：定位写盘进程FD泄漏、针对性提升其LimitNOFILE限制、优化逻辑复用句柄或原子写法并关闭未释放资源。

如何解决缓存文件写盘时引发的linux内核文件描述符耗尽

缓存文件写盘时触发“Too many open files”错误，本质是该操作密集打开临时文件、日志、压缩流或元数据句柄，叠加原有服务负载后突破了文件描述符（FD）限制。解决需分三层：定位写盘行为本身是否异常、检查并提升对应进程的FD限制、防止重复打开未关闭的缓存资源。

先明确哪个进程在执行缓存写盘，并查看其实际占用：

用 lsof -p $(pidof your-cache-process) 查看该进程当前打开的所有FD，重点关注 /tmp、/var/cache、.tmp、.log 等路径下的文件
统计数量：lsof -p $(pidof your-cache-process) | wc -l，若远超 ulimit -n 值（如 >5000），说明存在泄漏或高频创建
对比其 limits：cat /proc/$(pidof your-cache-process)/limits | grep "Max open files"，确认软限制是否过低（常见默认 1024）

不能只调系统全局值，必须让缓存进程启动时就获得足够FD：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

若进程由 systemd 管理（如 redis、varnish、自研缓存服务），编辑其 service 文件：sudo systemctl edit your-cache.service，添加：

[Service]
LimitNOFILE=65535
LimitNOFILESoft=65535

若进程由用户 shell 启动（如脚本中执行 tar、gzip、rsync 写缓存），需确保启动环境已加载更高限制——修改 /etc/security/limits.conf 中对应用户或 * 行，并确认 PAM 已启用 pam_limits.so
避免仅靠 ~/.bashrc 中 ulimit，因非交互式调用（如 cron、systemd、后台 nohup）不读该文件

单纯提高上限治标不治本，尤其当缓存模块存在资源管理缺陷时：

检查是否每次写缓存都新建临时文件（如 cache_XXXXXX.tmp）但未及时 close/unlink；应复用文件句柄或改用原子写法（write + rename）
确认日志轮转是否开启——大量缓存操作若伴随高频 debug 日志，未轮转会导致单个日志文件句柄长期持有
若使用压缩/归档（如 gzip、xz 流式写入），优先选用支持复用 fd 的库（如 libarchive），避免为每个块打开新管道
对基于 mmap 的缓存，注意 mmap() 不消耗 FD，但 backing file 的 open() 会；确保映射文件在不需要时已 munmap + close