より短く集中的な他の質問を試してみてください。これは一般的な「なぜfile-nrが予想より低い数字を報告するのですか？」という質問ではありません。私は反対の問題があります。
Linux 2.6システムでは、ファイルハンドルが漏れています。私は定期的に/proc/sys/fs/file-nrをcatするので、これを知っています。最初の数字は数時間にわたって上昇傾向であり、2番目の数字は常にゼロです。最初の数字が3番目の数字に達すると、ログインできなくなり、新しいシェルは作成されません。だから私はfile-nrの出力を信頼し、深刻なファイルハンドルリークがあると信じる理由があります。 （システムは必ずしもこれを行うわけではなく、これが起こり始める韻や理由を見つけることはできませんでしたが、かなり一般的です。）
今奇妙な部分が出てきます。 rootで実行しながら、/ proc / eachプロセスID / fdを介してすべてのfdに対してls -lを実行しました。私はこれをrootとして実行しているので、すべてのプロセスのすべてのファイルハンドルを見ることができます。
私の制限された理解によると、ls出力にはfile-nrが表示するのと同じ数のハンドルを表示する必要があります。 /proc/#の実行中にプロセスが行き来してファイルを開いたり閉じたりすることができるので、それが正しいとは思いません。しかし、十分な時間が経過すると、平均的におおよその合意が達成されると期待します。最初の質問は、これが合理的な仮定であることです。言わないとしたらどうしようかな？
file-nr は、ハンドルの数がゆっくりと増加して徐々に 65536 に向かっていくことを示しているので、この質問をします。ただし、/proc/ids../fd の合計出力は次のようになります。数千ハンドルの数が少ない。たとえば、かつてfile-nrは「9900 0 65536」のように見えましたが、procのプロセスあたりのファイルハンドルの数は2000個未満で、繰り返し実行でもほぼ同じままです。漏洩したハンドルは何でもプロセスとして表示されません。
違いは7,000以上ですか？プロセスが狂ったように起動および停止されず、ファイルが狂ったように開いて閉じてはいけません。プロセスあたりのハードファイルハンドルの数は1024に制限されているため、この問題を引き起こすプロセスは1つではありません。システムには数十のデッドプロセスが表示されますが、デッドプロセスがファイルハンドルを保持できないようです。そして私は他の人に自分の仕事を確認させ、それがlsを愚かに誤用しているように見えないようにします。
これは私にとって重要な問題であり、誰かがカウントに大きな違いがある理由を説明できれば、重要な問題と生産停止の問題を解決できる方向に進むことができます。
私はlsofを使用していないことに注意してください。これはシステムから削除されました。しかし、私は「オープンファイル」と同じではない可能性がある実際のファイルハンドルにのみ興味があるので、/proc/#sを歩くだけで十分です。それともそう思いました。
答え1
少なくともLinux 2.6では、死んだプロセスがファイルハンドルを維持できることがわかりました。何が起こったのかわかりませんが、死んだsshdプロセスを強制的にクリーンアップすると、ハンドルの数が再び減少しました。