Linuxで開くことができるファイルの最大数を設定できる大きさに（技術的または実用的な）制限はありますか？非常に大きな数（1〜100Mなど）に構成すると、いくつかの悪影響がありますか？
ここでは、組み込みシステムではなく、サーバーの使用法を考えています。もちろん、開いているファイルを大量に使用するプログラムはメモリを消費して遅くなる可能性がありますが、制限が必要以上に大きく設定されている場合の悪影響に興味があります（たとえば、設定だけで消費されるメモリ）。
回答:
制限の主な理由は、過剰なメモリ消費を避けるためだと思います（開いている各ファイル記述子はカーネルメモリを使用します）。また、バグのあるアプリケーションがファイル記述子をリークし、システムリソースを消費するのを防ぐ手段としても機能します。
しかし、現代のシステムが10年前のシステムと比べて非常に多くのRAMを持っていることを考えると、今日のデフォルトはかなり低いと思います。
2011年、Linuxでのファイル記述子のデフォルトのハード制限が1024から4096に引き上げられました。
一部のソフトウェア（MongoDBなど）は、デフォルトの制限よりも多くのファイル記述子を使用します。MongoDBの人々は、この制限を64,000に上げることを推奨しています。rlimit_nofile特定のアプリケーションでは300,000を使用しました。
ソフト制限をデフォルト（1024）に保つ限り、ハード制限を増やすことはおそらくかなり安全です。プログラムはsetrlimit()、ソフト制限を超えて制限を上げるために呼び出す必要があり、ハード制限によって制限されます。
関連するいくつかの質問も参照してください。
通常、影響は観測されませんが、カーネルのIOモジュールは、これらすべてのオープンファイル記述子を処理する必要があり、キャッシュ効率にも影響を与える可能性があります。
このような制限には、ユーザー自身（または第三者）のミスからユーザーを保護するという利点があります。たとえば、無限に分岐する小さなプログラムまたはスクリプトを実行すると、最終的にulimitsの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で開くことができるファイル数の実際的な制限は、プロセスが開くことができるファイル記述子の最大数を使用してカウントすることもできます。
システムごとに制限が変更されるのを見てきました。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この数値は、単に無限を意味します。これに達する前に、常に他のリソース制限に到達します。システムのハード制限を変更する必要がある場合は、カーネルパラメータを変更する必要があります。