制限の主な理由は、余分なメモリ消費を避けるためだと思います (開いている各ファイル記述子はカーネル メモリを使用します)。また、バグのあるアプリケーションがファイル記述子をリークしてシステム リソースを消費することに対する保護手段としても機能します。
しかし、最新のシステムが 10 年前のシステムと比較してどれほど多くの RAM を持っているかを考えると、現在のデフォルトはかなり低いと思います。
2011 年に、Linux のファイル記述子のデフォルトのハード リミットが 1024 から 4096 に引き上げられました。
一部のソフトウェア (MongoDB など) は、デフォルトの制限よりも多くのファイル記述子を使用します。 MongoDB 関係者は、この制限を 64,000 に引き上げることを推奨しています。 rlimit_nofile を使用しました 特定のアプリケーションでは 300,000 です。
ソフト リミットをデフォルト (1024) のままにしている限り、ハード リミットを上げてもおそらくかなり安全です。プログラムは setrlimit() を呼び出す必要があります 制限をソフト制限より上に引き上げるために、まだハード制限によって制限されています。
関連する質問も参照してください:
- https://serverfault.com/questions/356962/where-are-the-default-ulimit-values-set-linux-centos
- https://serverfault.com/questions/773609/how-do-ulimit-settings-impact-linux
通常、影響は観察できませんが、カーネルの IO モジュールは、開いているファイル記述子をすべて処理する必要があり、キャッシュ効率にも影響を与える可能性があります。
このような制限には、ユーザー自身 (またはサード パーティ) の間違いからユーザーを保護するという利点があります。たとえば、無期限に分岐する小さなプログラムまたはスクリプトを実行すると、最終的に ulimit のいずれかでブロックされます。 これにより、より深刻な (おそらく回復不能な) コンピューターのフリーズを防ぐことができます。
これらの制限のいずれかを増やす明確な理由がない限り、それを避けてよく眠る必要があります.
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 */
};