我有一个mmaps大量文件的应用程序。 3000+左右。它还使用大约75个工作线程。该应用程序是用Java和C ++混合编写的，Java服务器代码通过JNI调用C ++。
尽管不可预测，它经常会耗尽文件描述符。我已将/etc/security/limits.conf中的限制提高到：
* hard nofile 131072
/ proc / sys / fs / file-max是101752.该系统是运行Ubuntu 8.04 LTS且内核为2.6.35.4的Linode VPS。
在某个点之后，从代码的Java和C ++位打开失败。 Netstat没有显示大量的开放套接字（“netstat -n | wc -l”低于500）。 lsof或/ proc / {pid} / fd中打开文件的数量大约是预期的2000-5000。
这让我在稻草上抓了几个星期（不是经常，但每当我开始收到有关繁荣事件的通知时，恐惧和厌恶的闪光）。
还有一些其他松散的线程让我想知道他们是否提供了任何见解：
由于该进程有大约75个线程，如果mmaped文件以某种方式占用每个线程一个文件描述符，则数字加起来。也就是说，对/ proc / {pid} / tasks / * / fd中的事物进行递归计数当前列出了215575 fds，所以看起来它应该已经达到极限并且不是，所以这似乎不太可能。 / p>
Apache + Passenger也在同一个盒子上运行，对于最大数量的文件描述符排在第二位，但即使是孩子，这些进程也不会超过10k描述符。
我不确定从那里去哪里。显然有些东西正在使应用程序达到极限，但我完全空白接下来要检查的内容。有什么想法吗？
答案 0 :(得分：1)
所以，从我可以看出，这似乎是Ubuntu 8.04特有的问题。升级到10.04后，一个月后，没有一个这个问题的实例。配置没有改变，所以我认为这一定是内核错误。
答案 1 :(得分：0)
您的设置使用了大量代码，这些代码也可能会泄漏; JVM。也许你可以在sun和开源jvms之间切换，以检查代码是否偶然有罪。此外，jvm还有不同的垃圾收集器策略。使用不同的一个或不同的大小将导致或多或少的垃圾收集（在java中包括关闭描述符）。
我知道它有点牵强，但似乎你已经遵循了所有其他选项;）