長期実行アプリケーションが時々最大オープンファイル記述子制限()を超える理由を見つけようとしますulimit -n
。スパイクの発生を確認できるように、アプリケーションで開いているファイル記述子の数を定期的に記録したいと思います。
lsof
これには除外された項目がたくさん含まれていることがわかります/proc/$PID/fd
。これは開かれたファイル記述子の制限に関連していますか?つまり、lsof
で、またはで情報を記録する必要がありますか/proc/$PID/fd
?
答え1
tl;dr は、ls -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
彼らのハンドル。