cpu overload with NIO - are sources available?
843790Dec 9 2007 — edited Oct 12 2009I am experiencing a CPU issue with NIO, basically the CPU goes 100% in the following method:
19 request-queue-handler-1 : Thread[request-queue-handler-1,5,main] : RUNNABLE ( null ) 26387540000 19245390000 59%
* sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
* sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:184)
* sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
* sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
* sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
The bug starts kind of randomly when app is under heavy load, usually within the day.
After looking around I found that NIO had numerous bugs with cpu issues (like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6595055) but after checking my code I don't think I do anything wrong:
- sockets are ALL registered for OP_READ, and OP_READ only (connection is done by another thread). The interestOps is never changed or set to 0.
- registrations are done by the same thread that does the selector.select() (no concurrency issue).
- whenever select() returns, within same thread, ALL selected keys are removed and canceled, and corresponding sockets are processed further by other threads in blocking fashion. Later on, those sockets might be re-added to the same selector.
This situation is very frustrating, since the fact that it happens randomly makes it difficult to debug, and I dont know if the bug is due to the jvm or to the Kernel epoll (looks like it's spending an awful lot of time in sun.nio.ch.EPollArrayWrapper.epollWait).
So basically:
- does anyone have an idea of what is going on?
- does anyone know if the sources of jvm's epoll implementation are available? I've got the jvm sources but no sun.nio.ch.SelectorImpl is there, only the common java.nio.
thanks a bunch