大量文件描述符对Java应用程序的影响

Question

我们在Tomcat上部署了一个web应用程序，它可以有超过300 k的文件描述符，而我们对单个进程的限制是250 K。奇怪的是:当服务器运行时，数字会上升(400 K)，下降(100 K)。有时，当数字很高时，我们无法将ssh放入操作系统中。但是，我们没有发现与许多打开的文件或套接字建立问题有关的任何错误。大多数文件描述符与JVM加载的jar文件相关。我的问题是：

1. OS (CentOS 7)如何计算tomcat的文件描述符？我不认为Tomcat在运行时会打开这些文件。2.为何数目不固定？相反，有很多重复的jar文件。3.有这么多文件描述符是正常的吗？

Answer 1

操作系统对任何一个进程可以并发打开的文件数量都有限制。大多数发行版的缺省值仅为1024文件。每个打开的文件也有一个相关的文件描述符。套接字连接被视为文件，它们使用文件描述符，因此受到相同的资源限制。

1. 可以通过命令ulimit验证或更改最大限制。
2. 您还可以通过运行JMX工具- MaxFileDescriptorCount & OpenFileDescriptorCount来查看MBean Attibutes - JConsole的值。
3. 当OpenFileDescriptorCount小于MaxFileDescriptorCount时，您的应用程序工作正常，否则会得到导致应用程序故障的java.io.IOException: Too many open files。
4. 通常，对于一个应用程序，FD(文件描述符)的计数会上升/下降到一定的水平。但应该在MaxFileDescriptorCount.内

Answer 2

如果您查看com.sun.management.internal.OperatingSystemImpl的相应本机方法的源代码(在src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c下)，

• OpenFileDescriptorCount是/proc/self/fds下的文件描述符数，并且
• MaxFileDescriptorCount只是RLIMIT_NOFILE的值

RLIMIT_NOFILE --它指定的值大于此进程可以打开的最大文件de编号。尝试(打开(2)、管道(2)、dup(2)等)若要超过此限制，请生成错误EMFILE。(历史上，这个限制在BSD上被命名为RLIMIT_OFILE。)从Linux4.5开始，这个限制还定义了一个非特权进程(一个没有CAP_SYS_RESOURCE功能的进程)可能通过跨UNIX域套接字传递到其他支持程序的文件描述符的最大数量。此限制适用于sendmsg(2)系统调用。有关更多细节，请参见unix(7)。