我們的java應用程序在長時間運行後拋出「太多打開的文件」問題。 在調試問題時,看到有許多fds按照lsof輸出打開。找到哪個線程導致太多的打開文件問題,爲什麼lsof輸出中有重複的節點ID
# lsof -p pid | grep "pipe" | wc -l
# lsof -p pid | grep "anon_inode" | wc -l
--------------很少lsof的數據----- ------
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 23994 app 464u 0000 0,9 0 3042 anon_inode
java 23994 app 465u 0000 0,9 0 3042 anon_inode
java 23994 app 466r FIFO 0,8 0t0 962495977 pipe
java 23994 app 467w FIFO 0,8 0t0 962495977 pipe
java 23994 app 468r FIFO 0,8 0t0 963589016 pipe
java 23994 app 469w FIFO 0,8 0t0 963589016 pipe
java 23994 app 470u 0000 0,9 0 3042 anon_inode
java 23994 app 471u 0000 0,9 0 3042 anon_inode
如何找到許多類型爲FIFO和0000的開放式FD的根本原因。 在我們的應用程序中沒有太多的文件讀/寫操作。有很多TCP消息使用apache mina框架在內部使用Nio從流中讀取。
這是我的問題
- 我們已檢查過的/ proc/PID /任務/文件夾。有很多文件夾。它是否對應於線程ID?但根據jstack,有141個線程,因爲這個文件夾有209個子文件夾。
- 如何找到哪個線程導致fd泄漏?在我們的案例中,任務文件夾中的大部分文件夾對應於許多fds。即。/proc /進程/任務/線程ID/FD文件夾中有很多FD記錄
- 什麼是管的可能原因,並anon_inodes在lsof的
- 什麼是FD型0000
- 所有anon_inode的意義與同一個節點ID 3042 。 這是什麼意思?
[Here](https://stackoverflow.com/questions/8170902/why-is-the-jdk-nio-using-so-many-anon-inode-file-descriptors)是一個相關的帖子/討論。這種泄漏的常見原因是沒有正確關閉和處理的插座和管道。這可能有助於隨時監測計數並將增長與外部因素聯繫起來。 –
@AxelKemper:在任何給定的時間內都會打開近12000個套接字,並且大多數處於TIMED_WAIT狀態。那麼我可以將此問題與TIMED_WAIT套接字關聯嗎? – Albin
隨時?系統重啓後,我預計線性增長。 –