Le 3/5/14 2:24 AM, Hidden a écrit :
> Hello,

Hi,

>
> we've been using MINA for a huge game server application for 3 years, and so 
> far it has served us well. However, a day ago, it started acting weirdly. 1-3 
> hours after the application was started, it starts hogging the CPU (100% on 
> all cores).
>
> Here are two example stack traces (approximately a third of all NioProcessors 
> are stuck/busy in the one or other wakeup method):
> "NioProcessor-56" prio=6 tid=0x000000004264c000 nid=0xa9c runnable 
> [0x000000004c09f000]
>    java.lang.Thread.State: RUNNABLE
>     at sun.nio.ch.WindowsSelectorImpl.resetWakeupSocket0(Native Method)
>     at 
> sun.nio.ch.WindowsSelectorImpl.resetWakeupSocket(WindowsSelectorImpl.java:473)
>     - locked <0x0000000200b91f40> (a java.lang.Object)
>     at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:174)
>     at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
>     - locked <0x0000000200b90990> (a sun.nio.ch.Util$2)
>     - locked <0x0000000200b90980> (a java.util.Collections$UnmodifiableSet)
>     - locked <0x0000000200b7b8b0> (a sun.nio.ch.WindowsSelectorImpl)
>     at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
>     at 
> org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:72)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1077)
>     at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:744)
>
>    Locked ownable synchronizers:
>     - <0x00000006bc378ec8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
>
> -----------------
>
> "NioProcessor-87" prio=6 tid=0x0000000042649000 nid=0xaa4 waiting for monitor 
> entry [0x0000000049b1e000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>     at sun.nio.ch.WindowsSelectorImpl.wakeup(WindowsSelectorImpl.java:604)
>     - waiting to lock <0x00000002009bcc98> (a java.lang.Object)
>     at 
> org.apache.mina.transport.socket.nio.NioProcessor.wakeup(NioProcessor.java:88)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.flush(AbstractPollingIoProcessor.java:430)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.write(AbstractPollingIoProcessor.java:418)
>     at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.write(AbstractPollingIoProcessor.java:67)
>     at 
> org.apache.mina.core.service.SimpleIoProcessorPool.write(SimpleIoProcessorPool.java:251)
>         .... more write related instruction
>         .... write request issued by our application
>
> -----------------

The BLOCKED threads are not really interesting, they aren't using any
CPU. The trace isn't either showing us anything that can help, sadly as
it's a snapshot :/

Have you tried to attach to the process using a profiler, to see where
the CPU is being eaten (VisualVM or anything else) ?

What is quite strange is that you say the problem was still present even
after rebooting the machine... Do you mean that the CPU peaks to 100%
immediately after you restart the machine and the process ?


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

Reply via email to