Linuxで開くことができるファイルの最大数を設定できる大きさに(技術的または実用的な)制限はありますか?非常に大きな数(1〜100Mなど)に構成すると、いくつかの悪影響がありますか?
ここでは、組み込みシステムではなく、サーバーの使用法を考えています。もちろん、開いているファイルを大量に使用するプログラムは、メモリを消費して遅くなる可能性がありますが、制限が必要以上に大きく構成されている場合(たとえば、構成だけで消費されるメモリ)の悪影響に興味があります。
制限の主な理由は、過剰なメモリ消費を回避するためだと思います(開いている各ファイル記述子はカーネルメモリを使用します)。また、バグのあるアプリケーションがファイル記述子をリークし、システムリソースを消費するのを防ぐ手段としても機能します。
しかし、RAM現代のシステムは10年前のシステムと比べてどれほど不合理かを考えると、今日のデフォルトはかなり低いと思います。
2011年のLinuxでのファイル記述子のデフォルトのハード制限は 1024から4096に増加 でした。
一部のソフトウェア(MongoDBなど)は、デフォルトの制限よりもはるかに多くのファイル記述子を使用します。 MongoDBの人々 この制限を64,000に引き上げることをお勧めします 。特定のアプリケーションで300,000の_rlimit_nofile
_を使用しました。
ソフト制限をデフォルト(1024)に保つ限り、ハード制限を増やすことはおそらくかなり安全です。プログラムは、ソフト制限を超えて制限を引き上げるためにsetrlimit()
を呼び出す必要があり、ハード制限によって制限されます。
関連するいくつかの質問も参照してください。
通常、影響は観測されませんが、カーネルのIOモジュールは、開いているすべてのファイル記述子を処理する必要があり、キャッシュ効率にも影響を与える可能性があります。
このような制限には、ユーザー自身(または第三者)のミスからユーザーを保護するという利点があります。たとえば、無限に分岐する小さなプログラムまたはスクリプトを実行すると、最終的にはulimit
sの1つでブロックされ、より強力な(回復不可能な)コンピューターのフリーズが防止されます。
これらの制限のいずれかを増やす明確な理由がない限り、それを避けてよりよく眠る必要があります。
技術的には、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 */
};
私はあなたの懸念は理解できると思いますが、おそらくLinuxは構成された(しかし使用されていないファイル記述子)のために多くのメモリを消費しません:)
過去10年間、私のキャリアの中でこのような問題を思い出せません。
よろしく。
遅くなりましたが、これは他のすべての人がこの質問の答えを得るために役立つはずです。 Linuxで開くことができるファイル数の実際的な制限は、プロセスが開くことができるファイル記述子の最大数を使用してカウントすることもできます。
システムごとに制限が変更されるのを見てきました。 getlimit manページから、_RLIMIT_NOFILE-1
_が内部的に制限を指定していることがわかります。
RLIMIT_NOFILE値をチェックするには、以下のステートメントを使用してタプルを取得できます
python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"
タプルは結果を(Soflimit、hardlimit)として返します。複数のシステムで実行している私にとって、結果は以下のようになります
_(1024, 1048576) # on UBUNTU linux
(65536, 65536) # on Amazon linux
(1024, 9223372036854775807) # on macos
_
注:9223372036854775807この数値は、単に無限を意味します。これに達する前に、常に他のリソース制限に到達します。システムのハード制限を変更する必要がある場合は、カーネルパラメータを変更する必要があります。