Glassfish 4灰熊线程CPU使用率过高 [英] Glassfish 4 Grizzly Threads Heavy CPU usage

查看：150
本文介绍了Glassfish 4灰熊线程CPU使用率过高的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个在Glassfish 4（4.1版本13），JDK 1.7 update 67和AWS Linux AMI上运行的泽西岛应用程序，我注意到在运行它几个小时后，即使客户端停止运行，CPU使用率也会上升并保持不变。

运行top -H标识2个CPU使用率较高的http-listener-1-kernel线程（总数为16）。然后我使用线程转储来检查这两个线程： 

 http-listener-1-kernel（3）SelectorRunnerdaemon 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）
  - 锁定< 0x000000060263ad88> （a sun.nio.ch.Util $ 2）
  - 锁定< 0x000000060263ad78> （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：在org.glassfish.grizzly.nio.SelectorRunner.doSelect（SelectorRunner.java:338 114）
）
。在org.glassfish.grizzly.nio.SelectorRunner.run（SelectorRunner.java:278） 
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.doWork（AbstractThreadPool.java:565）
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.run（AbstractThreadPool.java:545）在java.lang.Thread.run（Thread.java:745）
 
 
 
 的HTTP监听-1-内核（8）SelectorRunner 守护程序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）
在sun.nio.ch.SelectionImpl.lockAndDoSelect（SelectorImpl.java:87）
  -  locked< 0x00000006026648b8> （a sun.nio.ch.Util $ 2）
  - 锁定< 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：在org.glassfish.grizzly.nio.SelectorRunner.doSelect（SelectorRunner.java:338 114）
）
。在org.glassfish.grizzly.nio.SelectorRunner.run（SelectorRunner.java:278） 
在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（select而不是selectNow）上使用不同的方法： 

  HTTP监听-1-内核（7）SelectorRunner 守护程序PRIO = 10 TID = 0x00007fbc68259800 NID = 0xaf2可运行的[0x00007fbcb51ca000] 
的java。 lang.Thread.State：RUNNABLE 
 at sun.nio.ch.EPollArrayWrapper.epollWait（Native Method）
 at sun.nio.ch.EPollArrayWrapper.poll（EPollArrayWrapper.java:269）
 sun.nio.ch.EPollSelectorImpl.doSelect（EPollSelectorImpl.java:79）
 at sun.nio.ch.SelectorImpl.lockAndDoSelect（SelectorImpl.java:87）
  -  locked< 0x0000000602665f20> （sun.nio.ch.Util $ 2）
  - 锁定< 0x0000000602665f10> （java.util.Collections $ UnmodifiableSet）
  -  locked< 0x0000000602665df8>在sun.nio.ch.SelectorImpl.select（一个sun.nio.ch.EPollSelectorImpl）
（SelectorImpl.java:98）
。在org.glassfish.grizzly.nio.DefaultSelectorHandler.select（DefaultSelectorHandler。的java：在org.glassfish.grizzly.nio.SelectorRunner.doSelect（SelectorRunner.java:338 112）
）
。在org.glassfish.grizzly.nio.SelectorRunner.run（SelectorRunner.java:278） 
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.doWork（AbstractThreadPool.java:565）
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.run（AbstractThreadPool.java:545） 
 at java.lang.Thread.run（Thread.java:745）

然后我重新启动客户端并让他们再运行几个小时，然后再次停止。果然，top -H表明CPU使用率再次增加。另一个线程转储显示，另外一个线程切换到selectNow，并且正在占用更多的CPU时间（以及另外两个线程）： 

 http-listener-1-kernel（6）SelectorRunner守护进程prio = 10 tid = 0x00007fbc68257800 nid = 0xaf1 runnable [0x00007fbcb52cb000] 
 java.lang.Thread.State：RUNNABLE 
 at sun.nio .ch.EPollArrayWrapper.epollWait（本机方法）
 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> （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：在org.glassfish.grizzly.nio.SelectorRunner.doSelect（SelectorRunner.java:338 114）
）
。在org.glassfish.grizzly.nio.SelectorRunner.run（SelectorRunner.java:278） 
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.doWork（AbstractThreadPool.java:565）
在org.glassfish.grizzly.threadpool.AbstractThreadPool $ Worker.run（AbstractThreadPool.java:545） 
 at java.lang.Thread.run（Thread.java:745）

它出现一些东西会导致线程调用sun.nio.ch.SelectorImpl的selectNow方法，一旦它们进入那里，CPU使用率将大量增加，并且不会减少，除非重新启动服务器。



这是一个已知的问题吗？这可能是由我的代码造成的？



感谢您的帮助！

解决方案

可能是此问题：



https://java.net/jira/browse/GLASSFISH-21211



问题中包含灰熊补丁，但我没有测试它。


I have a Jersey application running on Glassfish 4 (4.1 build 13), JDK 1.7 update 67 and AWS Linux AMI and I'm noticing that after some hours running it, CPU usage goes up and stays up even though clients are stopped.

Running "top -H" identifies 2 http-listener-1-kernel threads with high CPU usage (from a total of 16). I then took a thread dump to check these two threads:

"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)

Interestingly, the other threads that do not consume CPU are using a different method at sun.nio.ch.SelectorImpl (select instead of 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)

I then turned clients back on and left them running for a few more hours, before stopping them again. Sure enough, "top -H" shows that CPU usage increased again. Another thread dump reveals that one more thread switched to "selectNow" and is now taking more CPU time (along with the other 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)

It appears that something causes the threads to call the "selectNow" method of sun.nio.ch.SelectorImpl and once they enter there, CPU usage increases heavily and does not decrease unless server is restarted.

Is this a known issue? Can this be somehow caused by my code?

Thanks for the help!

解决方案

Could be this issue:

https://java.net/jira/browse/GLASSFISH-21211

There is a patch for grizzly included in the issue, but I have not tested it yet.

这篇关于Glassfish 4灰熊线程CPU使用率过高的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
Java开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆