我们最近开始对我们的应用程序进行负载测试，并注意到它在大约 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 参数增加几个数量级，然后重新运行测试，但我想知道将此变量设置得太高的任何潜在后果。
除了弄清楚我们的软件理论上可以打开多少个文件描述符之外，是否有任何最佳实践来设置它？
我在 XenServer 上运行 Ubuntu 16.04 Server，但遇到了 MySql 的打开文件限制问题。
这是我到目前为止所做的：
sudo nano /etc/security/limits.conf （参考）
* soft nofile 1024000
* hard nofile 1024000
* soft nproc 102400
* hard nproc 102400
mysql soft nofile 1024000
mysql hard nofile 1024000
sudo nano /etc/init/mysql.conf （参考）
limit nofile 1024000 1024000
limit nproc 102400 102400
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf （参考）
[mysqld_safe]
open_files_limit = 1024000
[mysqld]
open_files_limit = 1024000
当上述方法不起作用时，我继续执行以下操作：
须藤纳米 /etc/sysctl.conf
fs.file-max = 1024000
须藤纳米 /etc/pam.d/common-session
session required pam_limits.so
须藤纳米 /etc/pam.d/common-session-noninteractive
session required pam_limits.so
须藤纳米/lib/systemd/system/mysql.service
LimitNOFILE=infinity
LimitMEMLOCK=infinity …我们的服务器最近用完了文件描述符，对此我有一些疑问。ulimit -n应该给我最大数量的打开文件描述符。这个数字是 1024。我通过运行检查了打开的文件描述符的数量，lsof -u root |wc -l得到了 2500 个 fds。这比 1024 多得多，所以我猜这意味着数字 1024 是每个进程，而不是每个用户，就像我一样。好吧，我跑了lsof -p$PidOfGlassfish|wc -l，得到了 1300。这是我没有得到的部分。如果ulimit -n不是每个用户或每个进程的最大进程数，那么它有什么用？它不适用于root用户吗？如果是这样，我怎么能得到关于文件描述符用完的错误消息？
编辑：我能理解的唯一方法ulimit -n是它是否应用打开文件的数量（如 bash 手册中所述）而不是文件句柄的数量（不同的进程可以打开同一个文件）。如果是这种情况，那么仅列出打开文件的数量（grepping '/'，从而排除内存映射文件）是不够的：
lsof -u root |grep /|sort -k9 |wc -l #prints '1738'
要实际查看打开文件的数量，我需要对名称列进行过滤，仅打印唯一条目。因此，以下可能更正确：
lsof -u root |grep /|sort -k9 -u |wc -l #prints '604'
上面的命令需要 lsof 以以下格式输出：
java 32008 root mem REG 8,2 11942368 72721 /usr/lib64/locale/locale-archive
vmtoolsd 4764 root mem REG 8,2 18624 106432 /usr/lib64/open-vm-tools/plugins/vmsvc/libguestInfo.so
这至少给了我小于 …
我有一个正在泄漏文件描述符的 Java 进程（Glassfish）。我知道这一点，因为我得到了有用的java.io.IOException: Too many open files例外。我可以/proc/PID#/fd查看所有打开的文件描述符。当我使用 lsof 时，我得到了大量这样的条目：
java 18510 root 8811u sock 0,4 1576079 无法识别协议
java 18510 root 8812u sock 0,4 1576111 无法识别协议
java 18510 root 8813u sock 0,4 1576150 无法识别协议
我看到每分钟创建 12 个新的。我可以在 lsof 上使用哪些选项或我可以使用哪些其他工具来帮助跟踪无法识别协议的套接字文件描述符？
我知道 /proc/sys/fs/file-max 定义了打开文件描述符的最大数量，可以在运行时或启动期间设置。
但是：它的默认值是多少？检查我公司的 10 台服务器给了我 7 个不同的值，这些值似乎都是随机的。
内核文档只是不断提到可以更改该值 - 但没有提到如何计算默认值。
你们中有人知道如何确定默认值吗？
lsof 如何报告比 ulimit 所说的限制更多的打开文件？
prod_web3(i-ca0b05aa):~$ sudo lsof | wc -l
4399
prod_web3(i-ca0b05aa):~$ ulimit -n
1024
在 linux 上运行的服务器应用程序通常需要大量的打开文件处理程序，例如。HBase ulimit , Hadoop epoll 限制
这个 wiki 条目应该作为 Linux 文件限制配置的文档。
请描述您的配置在哪个 Linux 发行版下有效，因为不同的供应商配置不同。
更新基于 lstvan 答案：
对于希望自动执行此操作的人，至少在 Ubuntu 服务器上，您可以将其放入您的机器安装脚本中：
echo 'fs.file-max = 65000' > /etc/sysctl.d/60-file-max.conf
echo '* soft nofile 65000' > /etc/security/limits.d/60-nofile-limit.conf
echo '* hard nofile 65000' >> /etc/security/limits.d/60-nofile-limit.conf
echo 'root soft nofile 65000' >> /etc/security/limits.d/60-nofile-limit.conf
echo 'root hard nofile 65000' >> /etc/security/limits.d/60-nofile-limit.conf
我的问题很简单，实际上已在标题中说明。我的一个应用程序向我抛出关于“打开文件太多”的错误，即使应用程序运行的用户限制高于默认值 1024（lsof -u $USER 报告 3000 个打开的文件）。
因为我无法想象为什么会发生这种情况，我猜每个进程可能有一个最大值。
任何想法都非常感谢！
编辑：一些可能有帮助的值...
root@Debian-60-squeeze-64-minimal ~ # ulimit -n
100000
root@Debian-60-squeeze-64-minimal ~ # tail -n 4 /etc/security/limits.conf
myapp soft nofile 100000
myapp hard nofile 1000000
root soft nofile 100000
root hard nofile 1000000
root@Debian-60-squeeze-64-minimal ~ # lsof -n -u myapp | wc -l
2708
我有一个运行 java 应用程序的 tomcat，它偶尔会累积套接字句柄并达到我们为最大打开文件配置的 ulimit（软和硬），即 100K。发生这种情况时，java 似乎还活着，但我们无法再访问它。
然而，我的问题是关于伴随这种情况的一种奇怪现象：我不能mkdir在 tomcat 文件夹中。
[root@server /opt/apache-tomcat-7.0.52]# mkdir some_folder
mkdir: cannot create directory `some_folder': No space left on device
事实上，我在驻留在 下的多个不同文件夹下遇到相同的错误/opt，但不是/opt直接在/opt/apache-tomcat-7.0.52/logs.
我一辈子都无法解释，只能使用init 6. 关于如何解决问题并mkdir无需重新启动即可再次使用的任何建议？
设置是在 AWS 下运行的 CentOS 6.5，并从 EBS 卷挂载上述 tomcat 磁盘。
运行df -h显示磁盘明显未满：
[root@server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 9.9G 3.6G 5.9G 38% /
none 121G 0 121G 0% /dev/shm …linux tomcat centos disk-space-utilization max-file-descriptors
我在 Ubuntu 10.04 64 位上运行 Squid 2.7。我遇到了 Squid 耗尽文件描述符的问题，/var/log/squid/cache.log 中显示以下错误：
警告！您的缓存已用完文件描述符
我检查过：
鱿鱼客户端经理：信息 | grep '文件描述'
它显示我只有 1024 个可用的文件描述符。
我更改了 /etc/security/limits.conf，在末尾添加了以下内容：
* soft nofile 32768
* hard nofile 32768
proxy soft nofile 32768
proxy hard nofile 32768
将其添加到 /etc/squid/squid.conf 中：
max_filedescriptors 32768
还更改了/etc/default/squid：
SQUID_MAXFD=32768
什么都没有解决。最后我编辑/etc/init.d/squid添加“ulimit -n 32768”：
#!/bin/sh -e
# upstart-job
#
# Symlink target for initscripts that have been converted to Upstart.
set -e
ulimit -n 32768
<... snipped ...>
成功了！:)
我必须在实时生产 Squid 服务器极其缓慢的压力下完成这一切，所以我确信这不是正确的方法。
但正确的做法是什么？
为了增加在 Ubuntu Linux 机器上无头用户下运行的守护进程的 FD 限制，我们在 /etc/security/limits.conf 中进行了以下更改
soft nofile 10000
hard nofile 10000
我们还在 /etc/pam.d/login 中添加了会话所需的 pam_limits.so。所有注销并再次登录的用户都会反映这些更改。在这些用户下启动的任何新流程都将获得新的 FD 限制。
但是对于在无头用户下运行的守护程序，更改没有得到反映。对于在无头用户下运行的守护程序，可以通过什么方式反映更改？
我有一个在嵌入式 Linux 系统上运行的二进制进程（没有可用的源）。该进程会打开一个日志文件 (/tmp/dmaosd.log)，在其中记录其正在执行的操作。
问题是日志以块的形式更新（一次大约 1000 个字节），所以我无法使用 tail -f 实时查看日志。
我想知道是否有任何方法可以强制正在运行的进程刷新其数据（基于访问 /proc/1234/fd/3）而无需访问其源并且不向其发送任何信号（我不确定是什么信号它支持也不支持他们应该做什么）。
所讨论的过程是媒体播放器的 OSD，日志信息通常显示屏幕上选择/显示了哪些元素，因此最好尽快获得数据。
谢谢！
对其中一个 apache 子进程执行 strace，它显示两次系统调用之间的时间间隔为 24 秒。我如何确定导致此行为的原因。看起来两个子进程花费的时间几乎相同（24.7 和 23.92）秒。
我们使用 apache prefork 与 php5 和 mysql 5
/var/lib/php5/ 是 php 会话文件夹
带有 processid -20539 的 apache Children1 的 strace 输出
ps -u www-数据 | grep apache2 | awk '{print"-p " $1}' | xargs strace -o /strace/strace.log -ff -s4096 -r
20539 0.000064 关闭(13) = 0
20539 0.000060 打开（“/var/lib/php5/sess_9t2cvnvdoruh666rjpm515idm0”，O_RDWR|O_CREAT，0600）= 13
20539 0.000065 羊群(13, LOCK_EX) = 0
20539 24.711888 fcntl(13, F_SETFD, FD_CLOEXEC) = 0
20539 0.000056 fstat(13, {st_mode=S_IFREG|0600, st_size=211, ...}) = 0
20539 0.000080 …