我们最近开始对我们的应用程序进行负载测试，并注意到它在大约 24 小时后耗尽了文件描述符。
我们在 Dell 1955 上运行 RHEL 5：
CPU：2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB RAM：8GB RAM HDD：2 x 160GB 2.5" SATA 硬盘
我检查了文件描述符限制，它被设置为 1024。考虑到我们的应用程序可能有大约 1000 个传入连接和 1000 个传出连接，这似乎相当低。更不用说需要打开的任何实际文件了。
我的第一个想法是将 ulimit -n 参数增加几个数量级，然后重新运行测试，但我想知道将此变量设置得太高的任何潜在后果。
除了弄清楚我们的软件理论上可以打开多少个文件描述符之外，是否有任何最佳实践来设置它？
任何人都可以通俗地解释软限制和硬限制之间的区别是什么？
我应该将软限制和硬限制设置为相同吗？或者软度应该显着降低？无论哪种方式，系统都会受益吗？
我有两台配置几乎相同的 CentOS 5 服务器。当我登录并执行时ulimit -u，在一台机器上我得到unlimited，而在另一台机器上我得到77824。
当我运行一个 cron 时：
* * * * * ulimit -u > ulimit.txt
我得到相同的结果 ( unlimited, 77824)。
我正在尝试确定这些设置的位置，以便我可以更改它们。他们不是在我的任何配置文件（设置.bashrc，/etc/profile等等）。这些无论如何都不会影响 cron ）或 in /etc/security/limits.conf（这是空的）。
我已经搜索了谷歌，甚至做了这么多grep -Ir 77824 /，但到目前为止没有任何结果。我不明白这些机器怎么会预设有不同的限制。
我实际上想知道的不是这些机器，而是另一台（CentOS 6）机器，它的限制1024太小了。我需要以更高的限制运行 cron 作业，我知道如何设置它的唯一方法是在 cron 作业本身中。没关系，但我宁愿将它设置为系统范围，这样它就不会那么笨拙了。
谢谢你的帮助。这似乎应该很容易（不是）。
编辑 - 已解决
好的，我想通了。这似乎是 CentOS 6 或我的机器配置的问题。在 CentOS 5 配置上，我可以设置/etc/security/limits.conf：
* - nproc unlimited
这将有效地更新帐户和 cron 限制。但是，这在我的 CentOS 6 机器中不起作用。相反，我必须这样做：
myname1 - nproc unlimited …我注意到在我刚从 EC2 启动的新 CentOS 映像上，ulimit 默认值是 1024 个打开的文件，但是 /proc/sys/fs/file-max 设置为 761,408，我想知道这两个限制是如何工作的一起。我猜 ulimit -n 是每个用户的文件描述符数量限制，而 /proc/sys/fs/file-max 是系统范围的？如果是这种情况，假设我已经以同一用户身份登录了两次——每个登录用户的打开文件数是否有 1024 个限制，或者每个登录的用户之间是否有 1024 个组合打开文件的限制——在用户？
如果您的系统从未打开过很多文件，那么将最大文件描述符设置为非常高的数字是否会对性能产生很大影响？
我有一个长时间运行的进程，最终会达到最大打开文件限制。我知道如何在它失败后更改它，但是有没有办法从命令行更改正在运行的进程？
现在nofileOS X 用户帐户的默认限制似乎是大约 256 个文件描述符。我正在尝试测试一些需要比一次打开更多连接的软件。
在运行 pam 限制模块的典型 Debian 机器上，我会编辑/etc/security/limits.conf为将运行该软件的用户设置更高的限制，但我不知道在 OS X 中设置这些限制的位置。
是否有适合它的 GUI？某处是否有配置文件？在 OS X 上更改默认 ulimit 的最简洁方法是什么？
在 Debian Wheezy 上，ulimit -a给出：
open files (-n) 1024
我将此添加到 /etc/security/limits.conf
* hard nofile 64000
然后重新启动。
并且ulimit -a仍然提供了 1024 个最大打开文件数。任何人都可以对此有所了解吗？
服务器是 Ubuntu 13.04 (GNU/Linux 3.9.3-x86_64-linode33 x86_64)。
nginx 是 nginx/1.2.6。
我已经为此工作了几个小时，所以这就是我得到的，这就是我所做的。
tail -f /usr/local/nginx/logs/error.log
2013/06/18 21:35:03 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 21:35:04 [crit] 3427#0: accept4() failed (24: Too many open files)
2013/06/18 …我正在尝试为 ubuntu 机器上的所有用户提高打开文件描述符的最大值。
这个问题有点像这个问题的后续。
即使需要 pam_limits.so，ulimit 也不会读取打开的文件描述符limits.conf 设置
除了我在limits.conf中添加了所需的“root”条目
这是条目
* soft nofile 100000
* hard nofile 100000
root soft nofile 100000
root hard nofile 100000
相关的pam_limits.so行在 /etc/pam.d/ 中的所有相关文件中已取消注释，并fs.file-max已在 /etc/sysctl.conf 中正确设置
然而，我仍然看到
abc@machine-2:/etc/pam.d$ ulimit -n
1024
重启后。
可能是什么问题呢？
我的默认 shell 是 /bin/sh 并且我不能使用 chsh 来更改我的默认 shell，因为我的机器上的用户是通过某种分布式身份验证方案进行身份验证的。
我的 MongoDB 数据库在负载下遇到问题，日志中出现以下错误：
[initandlisten] pthread_create failed: errno:11 Resource temporarily unavailable
[initandlisten] can't create new thread, closing connection
我得出的结论是，我需要提高 1024 的“ulimit -u”或“最大进程”设置，并且使用率可能已经超过了启动的 Web 前端（不知道如何检查） .
我编辑了 /etc/security/limits.conf 以添加最后两行（前两行已经存在）：
* soft nofile 350000
* hard nofile 350000
* soft nproc 30000
* hard nproc 30000
然后我重新启动了系统（顺便说一句，我应该这样做，还是重新启动 mongod 服务就足够了？）
重新启动后，查看 mongod 进程的进程限制，似乎软限制已被忽略：
$ cat /proc/2207/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 …