☰

Linuxで許可されているオープンファイルの最大数

tag-icon • tag-icon linux files limit open-files
Linuxで許可されているオープンファイルの最大数

Linuxで設定できるオープンファイルの最大数に（技術的または実際的な）制限はありますか？構成が大きい場合（例：1-100M）、副作用はありますか？

ここでは、組み込みシステムではなくサーバーの使用を考えています。開いているファイルを多用するプログラムはもちろん、メモリを消費して速度が遅くなりますが、制限が必要なものよりはるかに大きく設定されている場合（たとえば、設定だけでメモリが消費される）、副作用に興味があります。

答え1

私はこの制限の主な理由が過度のメモリ消費を避けるためだと思います（開いている各ファイル記述子はカーネルメモリを使用します）。また、バグのあるアプリケーションがファイル記述子を漏洩し、システムリソースを消費するのを防ぎます。

しかし、現代システムのRAMが10年前のシステムと比べてどれほど面白いのかを考えると、今日のデフォルトはかなり低いと思います。

2011年以降、Linuxのファイル記述子の基本的なハード制限は次のとおりです。1024から4096に増加。

MongoDBなどの一部のソフトウェアは、デフォルトの制限よりも多くのファイル記述子を使用します。モンゴルDBの人々この制限を64,000に増やすことをお勧めします。。rlimit_nofile一部のアプリケーションでは300,000を使用しました。

ソフト制限をデフォルト値（1024）に保つ限り、ハード制限を増やすことはおそらく非常に安全です。プログラムは、setrlimit()制限をソフト制限の上に上げるように呼び出す必要があり、ハード制限によって制限されます。

また、いくつかの関連質問を参照してください。

答え2

技術的には unsigned long(C Lang) の最大値である 4,294,967,295 に制限されます。

参照fs.h文書

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

答え3

この効果は一般的には観察できませんが、カーネルのIOモジュールはこれらのすべてのオープンファイル記述子を処理する必要があり、キャッシュ効率にも影響を与える可能性があります。

この制限は、ユーザー自身（または第三者）のエラーからユーザーを保護するという利点があります。たとえば、無限に分岐している小さなプログラムやスクリプトを実行すると、最終的にそれらの1つがブロックされ、ulimitより深刻な（そして潜在的に回復不可能な）コンピュータの停止を防ぐことができます。

この制限を増やす明確な理由がなければ、そうしないでください。

答え4

あなたの懸念は理解できると思いますが、Linuxは設定されている（ただし未使用のファイル記述子）のために多くのメモリを消費しない可能性があります。 :)

私は過去10年間、私のキャリアでこのような問題が発生したことを覚えていません。

挨拶。

関連情報