我试图找到为什么我的长时间运行的应用程序有时会突破最大打开文件描述符限制 ( ulimit -n
) 的原因。我想定期记录应用程序打开了多少个文件描述符,以便我可以看到峰值何时发生。
我知道其中lsof
包括一堆被排除在外的项目/proc/$PID/fd
...这些项目与打开文件描述符限制相关吗?即我应该记录来自lsof
或来自的信息吗/proc/$PID/fd
?
答案1
tl;drls -U /proc/PID/fd | wc -l
会告诉您应该小于的数字ulimit -n
。
/proc/PID/fd
应该包含进程打开的所有文件描述符,包括但不限于奇怪的文件描述符,例如epoll
或inotify
句柄、用 或O_PATH
打开的“不透明”目录句柄、用signalfd()
或memfd_create()
返回的套接字accept()
等。
我不是一个很好的lsof
用户,但也lsof
从 获取其信息/proc
。我认为除了procfs
或通过附加到进程之外,没有其他方法可以获取进程在 Linux 上打开的文件描述符列表ptrace
。
ulimit -n
无论如何,进程的当前目录和根目录、映射文件(包括其自己的二进制和动态库)和控制终端不计入( )设置的限制,并且除非进程明确持有,否则RLIMIT_NOFILE
它们也不会出现在/proc/PID/fd
打开它们的句柄。