Поток гризли Glassfish потребляет 100% процессорного времени

Недавно мы заметили проблему, из-за которой наш сервер Glassifish после успешной работы в течение нескольких часов внезапно привязывал один из ЦП к 100%. В это время наше приложение перестает отвечать на запросы. После перезапуска проблема со временем повторится (обычно через несколько часов).

Я запустил эту команду, чтобы увидеть, что делают потоки:

asadmin generate-jvm-report --type=thread

В результате один поток выглядел очень подозрительно (потребляя на несколько порядков больше процессорного времени, чем любой другой поток):

Информация о выполнении потока:


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)

Статистика синхронизации потоков:


Количество раз, когда этот поток был заблокирован (для входа/повторного входа в Монитор): 4520

Количество раз, когда этот поток ожидал уведомления (т. е. находился в состоянии WAITING или TIMED_WAITING): 0

Общее время ЦП для этого потока: 2753 секунды 703 125 000 наносекунд.

Время ЦП на уровне пользователя для этого потока: 2753 секунды 703 125 000 наносекунд.

Мониторы объектов, которые в настоящее время удерживаются или запрашиваются этим потоком: []

Собственные синхронизаторы (например, ReentrantLock и ReentrantReadWriteLock), удерживаемые этим потоком: []

Мы используем Glassfish 3.1.2.2 на Windows Server 2008 R2 Enterprise. Любое понимание того, что происходит, высоко ценится.


person Jeff    schedule 11.12.2012    source источник
comment
какой jdk вы используете?   -  person Aksel Willgert    schedule 11.12.2012
comment
Мы используем JDK версии 1.6.0_37.   -  person Jeff    schedule 11.12.2012


Ответы (1)


Это может быть проблема с JDK. В Grizzly есть обходной путь для проблемы с пустым селектором, которая возникает в Linux с более ранними версиями JDK 6. Но он не применяется в Windows.

Могу я попросить вас создать выпуск Glassfish или Grizzly?

person alexey    schedule 12.12.2012
comment
В порядке. Я отправил сообщение о проблеме Glassfish 19444: java.net/jira/browse/GLASSFISH-19444 - person Jeff; 14.12.2012