У меня есть приложение на черной основе, работающее на Glassfish 4 (4.1 build 13), обновление JDK 1.7 и AWS Linux AMI, и я замечаю, что после нескольких часов работы процессор загружается и остается, даже если клиенты остановлены.Glassfish 4 Grizzly Threads Тяжелое использование процессора
Запуск «top -H» идентифицирует 2 потока HTTP-listener-1-ядра с высоким потреблением центрального процессора (из общего числа 16). Затем я взял нить дамп, чтобы проверить эти две темы:
"http-listener-1-kernel(3) SelectorRunner" daemon prio=10 tid=0x00007fbc68251000 nid=0xaee runnable [0x00007fbcb55ce000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x000000060263ad88> (a sun.nio.ch.Util$2)
- locked <0x000000060263ad78> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000006025fb068> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:106)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:114)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:338)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
"http-listener-1-kernel(8) SelectorRunner" daemon prio=10 tid=0x00007fbc6825b800 nid=0xaf3 runnable [0x00007fbcb50c9000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x00000006026648b8> (a sun.nio.ch.Util$2)
- locked <0x00000006026648a8> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000602664790> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:106)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:114)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:338)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Интересно, что другие потоки, которые не потребляют CPU используется другой метод в sun.nio.ch.SelectorImpl (выберите вместо selectNow):
"http-listener-1-kernel(7) SelectorRunner" daemon prio=10 tid=0x00007fbc68259800 nid=0xaf2 runnable [0x00007fbcb51ca000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x0000000602665f20> (a sun.nio.ch.Util$2)
- locked <0x0000000602665f10> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000602665df8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:112)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:338)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Затем я вернул клиентов и оставил их в течение нескольких часов, прежде чем их снова остановить. Разумеется, «top -H» показывает, что загрузка ЦП снова увеличилась. Другой поток дамп показывает, что еще один поток переключается на «selectNow» и в настоящее время принимает больше процессорного времени (наряду с другими 2):
"http-listener-1-kernel(6) SelectorRunner" daemon prio=10 tid=0x00007fbc68257800 nid=0xaf1 runnable [0x00007fbcb52cb000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x00000006026675c0> (a sun.nio.ch.Util$2)
- locked <0x00000006026675b0> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000602667498> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.selectNow(SelectorImpl.java:106)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:114)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:338)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Похоже, что-то заставляет нити называть «selectNow» метод sun.nio.ch.SelectorImpl, и как только они войдут туда, загрузка процессора сильно возрастает и не уменьшается, если сервер не перезапускается.
Это известная проблема? Может ли это быть вызвано моим кодом?
Спасибо за помощь!
Сколько потоков существует в «http-thread-pool»? Если для запросов на обслуживание недостаточно потоков, то SelectRunner может показаться «вращаться». – dlaudams