2

Glassifish サーバーが数時間正常に実行された後、CPU の 1 つが突然 100% にペグされるという問題に最近気付きました。この間、アプリケーションは応答しなくなります。再起動後、問題は最終的に再び発生します (通常は数時間後)。

このコマンドを実行して、スレッドが何をしているかを確認しました。

asadmin generate-jvm-report --type=thread

結果の出力では、1 つのスレッドが非常に疑わしいように見えました (他のどのスレッドよりも桁違いに多くの CPU 時間を消費していました)。

スレッド実行情報:

Thread "Grizzly-kernel-thread(1)" thread-id: 27 thread-state: RUNNABLE Running in native
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:273)
    at: sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:255)
    at: sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:136)
    at: sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
    at: sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
    at: com.sun.grizzly.TCPSelectorHandler.select(TCPSelectorHandler.java:513)
    at: com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:190)
    at: com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
    at: java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at: java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at: java.lang.Thread.run(Thread.java:662)

スレッド同期統計:

このスレッドがブロックされた回数 (モニターに入る/再入するため): 4,520

このスレッドが通知を待機した回数 (つまり、WAITING または TIMED_WAITING 状態): 0

このスレッドの合計 CPU 時間: 2,753 秒 703,125,000 ナノ秒。

このスレッドのユーザーレベルの CPU 時間: 2,753 秒 703,125,000 ナノ秒。

このスレッドによって現在保持または要求されているオブジェクト モニター: []

このスレッドによって保持されている所有可能なシンクロナイザー (ReentrantLock および ReentrantReadWriteLock など): []

Windows Server 2008 R2 Enterprise で Glassfish 3.1.2.2 を実行しています。何が起こっているのかについての洞察は高く評価されます。

4

1 に答える 1

1

JDKの問題かもしれません。Grizzly には、以前のバージョンの JDK 6 を使用する Linux で発生する、空のセレクター スピンの問題に対する回避策があります。ただし、Windows には適用されません。

Glassfish または Grizzly の問題の作成を依頼できますか?

于 2012-12-12T10:34:36.747 に答える