我注意到，在一个新的CentOS镜像上，我刚从EC2启动ulimit默认是1024打开文件，但/ proc / sys / fs / file-max设置为761,408，我想知道这两个限制是如何工作的一起。 我猜测，ulimit -n是每个用户的文件描述符的数量限制，而/ proc / sys / fs / file-max是系统范围的？ 如果是这样的话，说我已经login了两次，作为同一个用户 – 每个login的用户有1024个打开文件的限制，或者它是在每个login用户之间1024个组合打开文件的限制，在用户？
如果您的系统没有打开过多的文件，那么是否会将您的最大文件描述符设置为很高的性能？
file-max是在内核级别强制执行的最大文件描述符（FD），所有进程都不能超越而不增加。 ulimit在进程级别上强制执行，该级别可以小于file-max 。
通过增加file-max不会影响性能。 现代分布的FD设置最高，而过去它需要内核重新编译和修改，增加到1024以上。除非有技术需求，否则我不会增加系统范围。
每个进程的configuration通常需要调整为服务一个特定的守护进程，无论是数据库还是Web服务器。 如果完全删除限制，该守护进程可能会耗尽所有可用的系统资源; 这意味着您将无法解决问题，除非按下重置button或重新开机。 当然，其中任何一个都可能导致任何打开文件的损坏。
ulimit的限制是每个唯一的用户。 所以，无论login或进程运行多less次，user1都将被限制为1024.这是合并的。
我不确定是否完全理解这句话的含义（英文不是我的母语）如果这句话意味着文件描述符的限制configuration不是每个进程的限制，那么接受的答案（AFAIK）是错误的。
我的意思是，如果某个用户启动了4个进程，并且FD的ulimitconfiguration为1024，则每个进程可能会打开1024个FD。 用户不限于1024个FD，而是由该用户启动的过程。
例如：
me@superme:~$ ulimit -n 1024 me@superme:~$ lsof | grep $USER | wc -l 8145
这里是一个perl示例，我们达到了极限（这是一个per-process限制）：
#!/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）
对不起，如果我完全错了，或者我误解了答案。