file-nrとlsofがオープンファイルを別々に計算するのはなぜですか? [閉鎖]

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をチェックしなかったことです。だから私は大きな違いを見ています。

file -nrとlsof | wc -l(ルートディレクトリから)の出力にはまだ違いがあります。 lsof の数がファイルの -nr 個より大きい。その理由は、file -nrが一部のディレクトリ(lsofがファイルとして扱う)を無視するためです。これは、Google自体の調査を通じて見つけたものです。それでも!みんなの助けをありがとう!

ベストアンサー1

これには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)に送信されるようです。

  1. プロセスで使用されるファイル記述子の良い近似を得るには、「lsofを使用」して出力を適切にフィルタリングしてください。
  2. 時間に合わせてファイルディスクリプタを使用するためのスナップショットを取得するには、/procファイルシステムを巡回します(出力はフィルタリングする必要があります)。

特定のポイントで使用されるFDの量はシステム内で非常に迅速に変動する可能性があるため、正確な指標を得ることは困難です。

次のスレッドは、「lsof」メソッドのフィルタリング方法を提案します。

https://serverfault.com/questions/396872/why-or-how-does-the-number-of-open-file-descriptors-in-use-by-root-exceed-ulim

おすすめ記事