问题描述
我有一个websocket服务。这是错误的阶段：“打开文件太多”，但是我将系统配置为：
/etc/security/limits.conf
* soft nofile 65000
* hard nofile 65000
/etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65000
ulimit -n
//output 6500
所以我认为我的系统配置是正确的。
我的服务是由主管管理的，可能受到主管的限制吗？
检查过程由主管启动：
cat /proc/815/limits
Max open files 1024 4096 files
检查流程手动启动：
cat /proc/900/limits
Max open files 65000 65000 files
原因是使用主管管理服务。如果我重新启动主管并重新启动子进程，则在重新启动系统主管自动启动时，它是“最大打开文件数”确定(65000)但错误(1024)。
超级用户启动时可能是超级用户启动级别过高并且系统配置无法正常工作吗？
编辑：
系统：ubuntu 12.04 64bit
这不是管理员问题，系统重启后所有进程自动启动都不使用系统配置(最大打开文件数= 1024)，但可以重启。
更新
也许问题是：
-
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/938669
-
http://bryanmarty.com/blog/2012/02/10/setting-nofile-limit-upstart/
现在的问题是，如何设置全局nofile限制，因为我不想在我需要的每个新贵脚本中都设置nofile限制。
最佳方案
通过设置文件中所有用户的限制来解决此问题：
$ cat /etc/security/limits.d/custom.conf
* hard nofile 550000
* soft nofile 550000
设置限制后，重新启动服务器。
非常重要：/etc/security/limits.d/文件夹包含用户特定的限制。在我的情况下，Hadoop 2(cloudera)相关的限制。这些特定于用户的限制将覆盖全局限制，因此，如果未应用您的限制，请确保检查文件夹/etc/security/limits.d/和文件/etc/security/limits.conf中的特定于用户的限制。
注意：在所有情况下，设置用户特定限制都是可行的方法。应避免设置全局(*)限制。就我而言，这是一个孤立的环境，只需要消除实验中的文件限制问题即可。
希望这可以节省一些头发，因为我花了太多时间将头发一点一点地拉出来！
次佳方案
我有同样的问题。即使ulimit -Sn显示了我的新限制，但在proc文件中运行supervisorctl restart all和cat并没有显示新限制。
问题在于，supervisord仍然具有原始限制。因此，它创建的任何子进程仍然具有原始限制。
因此，解决方案是终止并重新启动supervisord。
第三种方案
尝试编辑/etc/sysctl.conf并全局调整限制，例如：
强制限制为100000个文件。
vi /etc/sysctl.conf
附加：
fs.file-max = 100000
保存并关闭文件。用户需要注销并重新登录以使更改生效，或者只需键入以下命令：
sysctl -p
第四种方案
对于任何厌倦的Google员工：您可能正在the supervisor config中寻找minfds设置。此设置似乎对监督过程以及孩子均有效。我还有许多其他策略，包括在执行实际程序之前启动shell脚本来设置限制，但这是唯一有效的方法。
第五种方案
您可以通过以下方式找到限制：
cat /proc/sys/fs/file-max
或sysctl -a | grep file
在/proc /sys /fs /file-max文件中进行更改，或使用以下命令进行更改：
sysctl -w fs.file-max=100000