开发者

Any Java debugging tips for finding the cause of "Too Many Files Open"

开发者 https://www.devze.com 2023-04-04 23:33 出处:网络
I\'m developing in a linux environment and the system is intended to run continuously over a long period of time. After an overnight test we see the FileNotFoundException with a message of \"Too Many

I'm developing in a linux environment and the system is intended to run continuously over a long period of time. After an overnight test we see the FileNotFoundException with a message of "Too Many Files Open". We started logging the output of the lsof command at various times in the system to see if we can see what is happening. We noticed lots of unnamed pipes opened. So I figured these were due to File Streams not getting closed. I searched through the source for any *Stream objects used and made sure they were all getting closed in a finally{} block. Are there any other Java object types that I could search for that I might not be closing that would cause all开发者_如何学JAVA these unnamed pipes to be opened?

Also, my ulimit is 1024 and I also searched for *Writer and made sure those were all closing too.


YourKit might be worth a look. Its probes are meant to help with this type of problems, although I've never had the occasion to try that functionality myself.


I'm assuming your ulimit is the output of ulimit -n. 1024 is a fairly small number of file descriptors to allow for in a production system. For a debugging step, rather than running lsof at random times and trying to correlate, why not catch the FileNotFound exception and run a Runtime.exec("lsof") and print the output to a log file to get a fairly accurate view of exactly what file descriptors were used when the problem occurred.


Other classes that might leak file descriptors are FileChannel and RandomAccessFile - the latter doesn't even seem to have a finalizer, so its leaks might be permanent.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号