開いているファイルの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コマンドを使用せずに開いているファイル記述子を表示する方法
回避策はありますか？突然、より多くのオープンファイルを使用し始めたプロセスを見つける必要があります。
[〜＃〜] update [〜＃〜]お手数をおかけして申し訳ありません。私はlsof | wc -lをルートからチェックしていなかった間違いを見つけました。それが私が大きな違いを見た理由です。
それでもファイル-nrとlsofの出力には違いがあります。 wc -l（ルートから）。 lsofカウントがfile -nrカウントを超えています。これの理由は、file -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番目の質問は上記のスレッドで回答されました（ https://serverfault.com/questions/485262/number-of-file-descriptors-different-between-proc-sys-fs-file-nr- and-proc-pi ）そして、どちらかに展開するようです
- 「lsofを使用」し、プロセスで使用中のファイル記述子の適切な概算を取得する必要がある場合は、出力を適切にフィルタリングします。または、
- ファイル記述子の使用時にスナップショットを取得するために、/ procファイルシステムをトラバースします（まだ出力をフィルタリングする必要があります）。
ある時点で使用中のFDの数はシステム上で非常に急速に変動する可能性があるため、これについて正確なメトリックを取得することの難しさは重大です。
次のスレッドは、「lsof」アプローチのフィルタリングスキームを提案しています。