我的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進程的文件描述符去「壞」，我不知道爲什麼

回答

相關問題