我的Java进程的文件描述符去“坏”，我不知道为什么

我有一个java web应用程序，使用Lucene建，我不断收到各种“文件已关闭”例外 - 这取决于我使用的目录执行。我已经能够从Lucene中获得“java.io.IOException错误文件描述符”和“java.nio.channels.ClosedChannelException”，通常包含在IndexReader的AlreadyClosedException中。我的Java进程的文件描述符去“坏”，我不知道为什么

有趣的是，我没有关闭的IndexReader，似乎文件描述符都是靠自己去陈旧。我正在使用最新版本的Lucene 3.0（没有时间从3.0系列升级），最新版本的Oracle JDK6，最新版本的Tomcat 6以及最新版本的CentOS。我可以使用其他Linux系统上的相同软件复制该错误，但不能在Windows系统上复制该错误，并且我没有要测试的OSX PC。 linux服务器是用qEmu虚拟化的，如果可能的话。

这似乎也成为负载相关 - 如何经常发生这种情况对应于请求量/秒Tomcat正在服务（这个特定的Web应用程序）。例如，在一台服务器上，每个请求都按预期完成，直到它处理约2个请求/秒，然后大约10％开始让它们的文件描述符从它们下面关闭，在请求中间（代码检查有效的IndexReader对象和在处理请求的开始时创建一个）。一旦达到约3 reqs/sec，所有请求都会由于错误的文件描述符而失败。

我最好的猜测是，不知何故有资源匮乏在操作系统级别和操作系统被清理FDS ......但是这只是因为我已经消除了所有其他的想法，我有。我已经检查了ulimits和文件系统的fd限制，并且打开描述符的数量远低于任何限制（示例输出从sysctl fs.file-nr：1020 0 203404，ulimit -n：10240）。

我几乎完全没有测试过的东西，我也没有比我发现它的日子更接近解决这个问题。有没有人遇到类似的东西？

编辑07/12/2011：我发现了一个OSX机使用了一些测试，并已确认这发生在OSX。我也在物理Linux机器上进行了测试并复制了这个问题，所以我一直无法复制这个问题的唯一操作系统是Windows。我猜这与POSIX处理文件描述符有关，因为这似乎是两个测试系统（JDK版本，tomcat版本和webapp在所有平台上都相同）之间唯一的区别。

来源

2011-07-11 oorza

的？ – duskwuff

否。虚拟化服务器上的文件系统是ext3，就像主机上的文件系统一样。没有任何NFS涉及到。 – oorza

鉴于我现在已经在OSX（HFS）和使用ext4的物理Linux机器上复制了这个，我认为排除文件系统是一个罪魁祸首可能是安全的。 – oorza

的原因，你可能没有看到在Windows上出现这种情况，可能是因为其FSDirectory.open默认使用SimpleFSDirectory。在http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/store/NIOFSDirectory.html红色文本：

退房在FSDirectory和NIOFSDirectory顶部的警告

注：在它的中断可以立即如果关闭底层的文件描述符直接或间接地从一个线程访问这个类同时线程在IO上被阻塞。文件描述符将保持关闭状态，随后对NIOFSDirectory的访问将引发ClosedChannelException。如果应用程序使用两种了Thread.interrupt（）或Future.cancel（布尔），你应该你在你的安装使用NFS在任何地方使用SimpleFSDirectory赞成NIOFSDirectory

https://issues.apache.org/jira/browse/LUCENE-2239

来源

2011-07-18 06:32:39

我可以用NIOFSDirectory，SimpleFSDirectory和MMapDirectory重现问题。我已经跟我的老板说过了，我们已经决定最好的解决方案似乎是采取计划在遥远的将来的webapp重写，现在就做。为了好奇，我通过并删除了所有close（）调用，没有调用Thread.interrupt（）或Future.cancel（）调用。有一篇关于原始帖子的评论，描述了由JDK bug引起的类似情况，并且因为我无法在所有操作系统中重现这一点，所以我倾向于相信它就是这样。 – oorza

我的Java进程的文件描述符去“坏”，我不知道为什么

回答

相关问题