java - jdk - ¿Cómo investigo la causa de un bloqueo de JVM?
java offline (5)
Cambiar a otra versión de linux-kernel "soluciona" el problema de aplastamiento de JVM ( http://forum.proxmox.com/threads/6998-Best-strategy-to-handle-strange-JVM-errors-inside-VPS?p=40286#post40286 ). Me ayudó con mi servidor real. Había un servidor Ubuntu 10.04 LTS OS con la versión del kernel 2.6.32-33. Así que la actualización del kernel resolvió este problema. JVM no tiene ningún bloqueo más.
Hace un día, después de algunos meses de trabajo normal, nuestra aplicación java comienza a fallar ocasionalmente con el siguiente error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (safepoint.cpp:247), pid=2075, tid=140042095163136
# guarantee(PageArmed == 0) failed: invariant
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# An error report file with more information is saved as:
# /var/chat/jSocketer/build/hs_err_pid2075.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Busqué en hs_err_pid2075.log y vi que había un hilo activo que procesaba una comunicación de red. Sin embargo, no se realizaron cambios en la aplicación o el entorno en los últimos meses. También no hubo ningún crecimiento de carga. ¿Qué puedo hacer para entender, cuál es la razón de la caída? ¿Existen pasos comunes para investigar un accidente de JVM?
El bloqueo se produce en la JVM, no en el código nativo externo. Sin embargo, la operación en la que se estrelló ha sido iniciada por un DLL externo.
Esta línea en el archivo hs_err_pid explica la operación que se estrelló:
VM_Operation (0x00007f5e16e35450): GetAllStackTraces, mode: safepoint, requested by thread 0x0000000040796000
Ahora, el hilo 0x0000000040796000 es
0x0000000040796000 JavaThread "YJPAgent-Telemetry" daemon [_thread_blocked, id=2115, stack(0x00007f5e16d36000,0x00007f5e16e37000)]
que es un hilo creado por Yourkit. "GetAllStackTraces" es algo a lo que necesita llamar un generador de perfiles para realizar el muestreo. Si eliminas el perfilador, el fallo no se producirá.
Con esta información, no es posible decir qué causa el bloqueo, pero puede intentar lo siguiente: Eliminar todos los parámetros de -XX VM, -verbose: gc y los parámetros de depuración de VM. Pueden interferir con la interfaz de creación de perfiles de la JVM.
Actualizar
El código que llama a java.lang.Thread#getAllStackTraces() o java.lang.Thread#getStackTrace() puede desencadenar el mismo bloqueo
Las dos veces que he presenciado bloqueos recurrentes de JVM se debieron a una falla del hardware, a saber, RAM. Ejecutar una utilidad memtest es lo primero que intentaría.
Puedo ver en el informe de errores que tienes cargado el agente de YourKit . Su hilo de telemetría se menciona como el solicitante de la operación que parece fallar. Intente ejecutar la aplicación sin el agente YJP para ver si aún puede reproducir el bloqueo.
En general, los bloqueos de JVM son bastante difíciles de diagnosticar. Pueden ocurrir debido a un error en algún código JNI o en el propio JRE. Si sospecha lo último, puede valer la pena enviar un informe de error a Oracle.
De cualquier manera, recomiendo actualizar a la última versión de Java 6 para asegurarse de que no sea un problema conocido que ya se haya solucionado. En el momento de escribir este artículo, la versión actual es Java 6 actualización 29.
Si no se está metiendo con nada que pudiera causar esto directamente (lo que básicamente significa usar código nativo o bibliotecas que llaman código nativo), casi siempre se debe a un error en la JVM o un problema de hardware.
Si ha estado funcionando bien durante años y ahora ha comenzado a fallar, me parece que el problema de hardware es el más probable de los dos. ¿Puedes ejecutarlo en otra máquina para descartar el problema? Por supuesto, definitivamente no estaría mal actualizar a la última actualización de Java también.