1990年に初めてUNIXシステムでアカウントを借りたとき、ファイルの制限が1024に達したため、これを問題として考えたことはありません。
30年が過ぎた今日、（ソフト）制限は1024にすぎません。
1024年の歴史的な理由は、資源が不足しているためだと思います。たとえ彼の証拠を実際に見つけることはできませんが。
私のラップトップの制限は（2^63-1）です：
$ cat /proc/sys/fs/file-max
9223372036854775807
今日、私が見る数字は1990年の1,024人ほど衝撃的です。私のシステムのハード制限（）はulimit -Hn1048576にさらに制限されています。
しかし、なぜ制限があるのですか？ RAMを限られたリソースにするのはどうですか？
私はUbuntu 20.04（2020年から）とHPUX B.11.11（2000年から）でこれを実行しました。
ulimit -n `ulimit -Hn`
Ubuntuでは、この制限は1024から1048576に増えます。 HPUXでは、60から1024に増加します。どちらの場合も、メモリ使用量に違いはありませんps -edalf。不足しているリソースがRAMでない場合、それは何ですか？はい足りない資源はどうですか？
私は私や私のユーザーに役立つ1024制限を経験したことがありません。むしろ、それは私のユーザーが説明できず、自分で修正できないエラーの根本的な原因でしたulimit -n 1046576。タスクを実行する前に、すぐにクラッシュを考えないでください。
制限が役に立つことがわかりますみんなプロセスが大まかに実行された場合にシステム全体がクラッシュしないようにするプロセスのメモリサイズ。しかし、これがファイルの制限にどのように適用されるかはわかりません。
1990年に戻ると、どのような状況で（通常のメモリ制限ではなく）1024制限が役に立ちましたか？今日も同様の状況がありますか？
ベストアンサー1
@patbarronはまだ自分のコメントを回答として投稿していませんが、本当に素晴らしいです。答えを探している人がいるなら、ここにいます。
彼が書いた：
たとえば、7版のソースコードを見ることができます（minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/h/user.h）もともとどのように実装されているかを確認してください。 「NOFILE」はプロセスごとに開かれたファイルの最大数で、各プロセスが割り当てるデータ構造のサイズに影響します。これらの構造は、実際に使用されているかどうかに関係なくメモリを占有します。繰り返しますが、これはもはや行われていないため、ほとんど歴史的に興味深いものですが、それはその起源に関する追加の文脈を提供することができます。
別の定数「NFILE」は、システム全体（すべてのプロセス/ユーザー）の最大オープンファイル数であり、各プロセスのオープンファイルテーブルには「ファイル」構造へのポインタが含まれています。minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/conf/cc。これは、システム全体のオープンファイルテーブルのサイズを決定するコンパイル時定数でもあります（実際に使用されているかどうかにかかわらず、メモリを消費することもあります）。
これは歴史的な理由があることを示しています。 NOFILEファイル記述子は、使用するかどうかにかかわらず、各プロセスで維持されます。 RAMが足りない場合は、未使用のメモリを保持しないようにしたいと思います。最近では、RAMが安くなるだけでなく、事前注文ももはやそうではありません。
ulimit -nそれは私の観察を確認します。最大値までの高さではなく、1024に維持する理由が見つかりませんulimit -n $(ulimit -Hn)。ファイル記述子が実際に使用されている場合にのみメモリが占有されます。