開いているファイルでfile-nrとlsofのカウントが異なるのはなぜですか？[閉まっている]

私は突然問題に直面しています。すべてのアプリケーションとサーバーが正常に動作しており、突然開いているファイルの数が急増するのがわかります。

このコマンドで確認しています：

cat /proc/sys/fs/file-nr

これで確認すると、が表示される44544 0 128000ため、44544が開いているファイルの数です。

しかし、このコマンドで確認するとlsof | wc -l -28384と表示されます。

どちらが正しいですか？

私の最大オープンファイル制限は65535です

ulimit -a
open files                      (-n) 65535

開いているファイルを多く使用している上位5つのプロセスを知りたい。私はこれを取得できますlsofが、ここに示されているカウントは、前述した他のコマンドとは非常に異なります。

このコマンドでカウントされたプロセスの詳細を取得できますcat /proc/sys/fs/file-nrか？

以下のリンクによると、オープンファイル記述子を表示する方法はありますが、lsofコマンドを使用しないことはできません

回避策はありますか？開いているファイルが突然使用されるようになったプロセスを見つける必要があります。

更新おめでとう ございます。私がやっていた間違いを見つけましたlsof | wc -lをルートからチェックしていませんでした。それが大きな違いを見た理由です。

ファイル-nrとlsofの出力にはまだ違いがあります| wc -l（ルートから）。lsofカウントはfile -nr countを超えています。この理由は、ファイル-nrがディレクトリの一部（lsofによってファイルと見なされる）を無視するためです。この理由は、Google自体についてのちょっとした調査で見つけました。いずれかの方法！すべての助けに感謝します！

ここには2つの質問があるようです。まず、file-nrおよびfile-max構造の完全なドキュメントは、次の場所にあります。

https://www.kernel.org/doc/Documentation/sysctl/fs.txt

これにより、そのファイルのフィールドは次のように定義されます。

file-nrの3つの値は、割り当てられたファイルハンドルの数、割り当てられているが未使用のファイルハンドルの数、およびファイルハンドルの最大数を示します。Linux 2.6は、空きファイルハンドルの数として常に0を報告します。これはエラーではなく、割り当てられたファイルハンドルの数が使用済みファイルハンドルの数と正確に一致することを意味します。

うまくいけばそれで十分だ。2番目の質問は、上記のスレッド（/server/485262/number-of-file-descriptors-different-between-proc-sys-fs-file-nr-and-proc- pi）およびどちらかに委譲されるようです

1. プロセスで使用中のファイル記述子の適切な近似を取得する必要がある場合は、「lsofを使用」し、出力を適切にフィルタリングします。または、
2. ファイル記述子の使用時にスナップショットを取得するために、/ procファイルシステムを走査します（出力をフィルタリングする必要があります）。

特定のポイントで使用中のFDの数はシステム上で非常に急速に変動する可能性があるため、このための正確なメトリックを取得することは困難です。

次のスレッドは、「lsof」アプローチのフィルタリングスキームを示しています。

/server/396872/why-or-how-does-the-number-of-open-file-descriptors-in-use-by-root-exceed-ulim