我注意到，在我刚从 EC2 启动的新 CentOS 映像上，ulimit 默认值为 1024 个打开文件，但 /proc/sys/fs/file-max 设置为 761,408，我想知道这两个限制如何协同工作。我猜 ulimit -n 是每个用户的文件描述符数量限制，而 /proc/sys/fs/file-max 是系统范围的限制？如果是这样，假设我以同一个用户身份登录两次 - 每个登录用户的打开文件数限制是否为 1024，还是每个登录用户的打开文件数总和限制为 1024？
如果您的系统从未打开过很多文件，那么将最大文件描述符设置为非常高的数字是否会对性能产生很大影响？
答案1
file-max是内核级别强制执行的最大文件描述符 (FD)，所有进程如果不增加则无法超过该值。是ulimit在进程级别强制执行的，可以小于file-max。
增加 不会带来性能影响风险file-max。现代发行版的最大 FD 设置得相当高，而过去需要重新编译和修改内核才能增加到 1024 以上。除非有技术需要，否则我不会增加整个系统的 FD。
每个进程的配置通常需要调整以服务于特定的守护进程，无论是数据库还是 Web 服务器。如果完全取消限制，该守护进程可能会耗尽所有可用的系统资源；这意味着您将无法解决问题，除非按下重置按钮或关闭电源。当然，这两种方法都可能导致任何打开的文件损坏。
答案2
ulimit 的限制是针对每个唯一用户的。因此，无论 user1 登录了多少次或运行了多少个进程，其限制都为 1024。这是组合。
我不确定我是否完全理解那句话的意思（英语不是我的母语）如果那句话的意思是文件描述符的 ulimit 配置不是每个进程的限制，那么接受的答案（据我所知）是错误的。
我的意思是，如果某个用户启动了 4 个进程，并且 FD 的 ulimit 配置为 1024，则每个进程可以打开 1024 个 FD。用户不会受到 1024 个 FD 的限制，而是该用户启动的进程会受到限制。
例如：
me@superme:~$ ulimit -n
1024
me@superme:~$ lsof | grep $USER | wc -l
8145
下面是一个我们达到限制的 perl 示例（这是每个进程的限制）：
#!/usr/bin/perl
$count = 0;
@filedescriptors;
while ($count <= 1024) {
$FILE = ${count};
open $FILE, ">", "/tmp/example$count" or die "\n\n FDs: $count $!";
push(@filedescriptors, $FILE);
$count ++;
}
结果：
FDs: 1021 Too many open files at ./test.pl line 8.
1021 因为在到达 while 循环之前有 3 个打开的文件描述符（stdout、stdin 和 stderr）
如果我完全错了或者误解了答案，我很抱歉。