2012-06-22 32 views
5

Tengo una aplicación java ejecutándose en CentOS 6.0. Siempre se ejecuta en segundo plano a través de cron. A veces, esta aplicación entra en estado de espera mientras usa 100% de CPU.java usando 100% cpu

Mi versión de Java es:

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) 

Otros síntomas son:

a. Un hilo del proceso parece estar en un bucle esperando algo. Cuando trazada usando strace, muestra siguiente o/p continuamente:

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) 

b. Parece que el proceso ha terminado de funcionar, mirando los archivos que está usando. Solo quedan unos pocos archivos. La salida de 'ls/proc/PID/fd/espectáculos:

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 

se ha enfrentado a nadie situación similar? Cualquier pista o referencia sería muy útil.

Más específicamente, ¿hay algún problema conocido al ejecutar procesos Java basados ​​en openjdk en segundo plano en CentOS 6?

Ahora soy capaz de simular el problema con un simple bucle infinito, se indican a continuación

#!/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 

Cuando esta secuencia de comandos se ejecuta durante unos 3 - 4 horas, encuentro uno o dos procesos que son java colgado o en bucle infinito con síntoma idéntico, es decir

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

Esto ocurre en sistemas multiprocesador solamente, no en sistemas de un solo procesador. También se puede simular en RHEL6, no solo en CentOS6.

Respuesta

1

El problema se solucionó después de actualizar el kernel a kernel-2.6.32-220 que es el kernel de CentOS 6.2.

+0

Debido a la corriente ascendente [error de núcleo 32922] (https://bugzilla.kernel.org/show_bug.cgi?id=32922), en las versiones de núcleo ascendentes desde 3.14 y corregidas en 3.18. Pero el error había sido recogido en backports a versiones de kernel anteriores en algunas distribuciones (por ejemplo, CentOS 6). Vea una conversación larga en este [debate de Grupos de Google] (https://groups.google.com/forum/#!tema/simpatía mecánica/QbmpZxp6C64) –

4

Hay muchas razones posibles. Aquellos, que se me ocurre:

  1. Su proceso de el uso de memoria es muy cerca del tamaño máximo de almacenamiento dinámico, haciendo notorio GC completa. Habilite los registros de GC con las opciones -Xloggc:/path/to/logFile.log -XX:+PrintGCDetails y luego analícelos usando herramientas como GCViewer o HPJmeter.

  2. Su proceso está realmente haciendo algo (como un bucle infinito), y puede verificarlo haciendo unos pocos volcados de subprocesos y analizándolos. Puede hacerlo con VisualVM y Thread Dump Analyzer.

+0

Como dije anteriormente, puedo simular el prb con "/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java -version". Esto indica que no es ni un gc prb, ni un bucle infinito en la aplicación. – amolkul

Cuestiones relacionadas