2012-06-22 2 views
5

У меня есть приложение java, работающее на CentOS 6.0. Он всегда работает в фоновом режиме через cron. Иногда это приложение переходит в состояние ожидания при использовании 100% -ного процессора.java using 100% cpu

Моя ява версия:

java version "1.6.0_17" 
OpenJDK Runtime Environment (IcedTea6 1.7.4) (rhel-1.21.b17.el6-x86_64) 
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 

Другие симптомы:

а. Один поток процесса, похоже, находится в цикле, ожидающем чего-то. При прослежены с помощью Трассирование, он показывает следующее о/р непрерывно:

futex(0x7fb8000ac728, FUTEX_WAKE_PRIVATE, 1) = 0 
futex(0x7fb8000ac754, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1340347489,> 822867000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 

б. Кажется, что процесс завершил работу, глядя на файлы, которые он использует. Осталось всего несколько файлов. Выход «LS/Proc/PID/FD/шоу:

lr-x------ 1 root root 64 Jun 22 13:13 0 -> pipe:[77107601] 
l-wx------ 1 root root 64 Jun 22 13:13 1 -> pipe:[77120162] 
l-wx------ 1 root root 64 Jun 22 13:13 2 -> /var/log/mithi/mcs/agent_account_mailstore_exceed_limit.sh.log 
lr-x------ 1 root root 64 Jun 22 13:13 3 -> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar 

ли кто-нибудь сталкивался подобную ситуацию? Любые подсказки или ссылки были бы очень полезными.

В частности, существуют ли какие-либо известные проблемы при запуске openjdk на основе Java-процессов в фоновом режиме на CentOS 6?

Теперь я могу имитировать проблему с очень простым бесконечным циклом, приведен ниже

#!/bin/bash 

while [ 1 ] 
do 
    /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java -version & 
    sleep 1s 
done 

Когда этот скрипт запускаются в течение 3 - 4 часов, я считаю, один или два Java-процессы, которые висел или в бесконечной петле с одинаковым симптомом, т.е.

futex(0x7fb8000ac754, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1340347489,> 822867000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 

Это происходит только на многопроцессорных системах, а не на однопроцессорных системах. Его также можно моделировать на RHEL6, а не только CentOS6.

ответ

1

Проблема была решена после обновления ядра до ядра 2.6.32-220, являющегося ядром CentOS 6.2.

+0

Из-за восходящего потока [Ошибка ядра 32922] (https://bugzilla.kernel.org/show_bug.cgi?id=32922) в версиях ядра выше 3.14 и исправлено в 3.18. Но ошибка была обнаружена в backports для ранних версий ядра в некоторых дистрибутивах (например, CentOS 6). См. Длительный разговор в этом разделе [Обсуждение групп Google] (https://groups.google.com/forum/#!Тема/механико-симпатия/QbmpZxp6C64) –

4

Существует много возможных причин. Те, что я могу думать:

  1. Ваш процесс использования памяти очень близко к максимальному размеру кучи, в результате чего пресловутый Full ШС. Включите журналы GC с параметрами -Xloggc:/path/to/logFile.log -XX:+PrintGCDetails, а затем проанализируйте их с помощью таких инструментов, как GCViewer или HPJmeter.

  2. Ваш процесс на самом деле что-то делает (как бесконечный цикл), и вы можете проверить его, выполнив несколько дампов потоков и проанализируя их. Вы можете сделать это с помощью VisualVM и Thread Dump Analyzer.

+0

Как я сказал выше, я смогу имитировать prb с помощью "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java -version". Это означает, что это не gc prb, ни бесконечный цикл в приложении. – amolkul