限製文件描述符的歷史原因是什麼（ulimit -n）
當我在 1990 年第一次在 UNIX 系統上借用一個帳戶時，文件限制是驚人的 1024，所以我從來沒有真正認為這是一個問題。
30 年後的今天，（軟）限制是微不足道的 1024。
我想 1024 的歷史原因是它是一種稀缺資源——儘管我無法真正找到證據。
我的筆記型電腦的限制是 (2^63-1)：
$ cat /proc/sys/fs/file-max 9223372036854775807在我今天看來，這與 1990 年的 1024 一樣令人驚訝。
ulimit -Hn我係統上的硬限制 ( ) 將其進一步限制為 1048576。但是為什麼要限制呢？為什麼不讓 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在執行他們的工作之前通常不會立即想到的神秘崩潰.我可以看到限制程序的總記憶體大小很有用，所以如果它執行異常，它不會關閉整個系統。但我不明白這如何適用於文件限制。
1024 的限制（而不僅僅是一般的記憶體限制）會在 1990 年有所幫助的情況是什麼？而今天有沒有類似的情況？
@patbarron 仍然沒有發布他的評論作為答案，他們真的很棒。因此，對於任何尋找答案的人來說，它都在這裡。
他寫：
您可以查看第七版的原始碼，例如 (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)。僅在實際使用文件描述符時才佔用記憶體。