Cómo detectar condiciones de falta de memoria?

Question

Tengo una aplicación que se ejecuta en Websphere Application Server 6.0 y se bloquea casi todos los días debido a falta de memoria. De verbose GC es cierto que hay pérdidas de memoria (muchos de ellos)

Lamentablemente, la aplicación es proporcionada por un proveedor externo y obtener las cosas arregladas es lento & proceso doloroso. Como parte del proceso, necesito recopilar los registros y los volcados de almacenamiento cada vez que se produce el OOM.

Ahora estoy buscando una forma de automatizarlo. El problema fundamental es cómo detectar la condición OOM. Una forma sería crear un script de shell que buscará periódicamente nuevos heapdumps. Este enfoque me parece un poco sucio. Otro enfoque podría ser aprovechar el JMX de alguna manera. Pero tengo poca o ninguna experiencia en esta área y no tengo mucha idea de cómo hacerlo.

¿O en WAS hay algún tipo de gatillo/ganchos para esto? ¡Muchas gracias por cada consejo!

Answer 1

Veo dos opciones si quiere que el volcado de pila sea automatizado pero @Mark's solution con el volcado de pila en OOM no es satisfactorio.

1. Puede utilizar el MemoryMXBean para detectar la presión de memoria alta, y luego programmatically create a heap dump si el uso (o delta uso) parece alta.
   • Puede obtener periódicamente información de uso de memoria y generar volcados de almacenamiento dinámico con un script de shell cron usando jmap (funciona tanto de forma local como remota).

Sería bueno si pudiera tener una devolución de llamada de OOM, pero, uhm, que acaba de devolución de llamada, probablemente se estrellaría con un error OOM. :)

Answer 2

Puede pasar los siguientes argumentos a la JVM al inicio y se generará automáticamente un volcado de pila en un OutOfMemoryError. El segundo argumento le permite especificar la ruta para el archivo de volcado de almacenamiento dinámico. Al usar esto, al menos, podría verificar la existencia de un archivo específico para ver si se ha producido un volcado de almacenamiento dinámico.

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=<value> 

Answer 3

Y alternativa a esperar hasta que la aplicación se ha estrellado puede ser a la escritura de un reinicio controlado como todas las noches si usted es optimista de que puede sobrevivir durante doce horas ..

Tal vez incluso puede hacer que WebSphere para ti !?

Answer 4

Puede agregar un detector (clase de ámbito de sesión o detector de atributo de ámbito de aplicación) que se llamaría cada vez que se agrega un nuevo objeto en el ámbito de sesión/aplicación.

En este - se puede tratar de comprobar la memoria total utilizada por la aplicación (Log ella) como como llamada de ejecución GC (tenga en cuenta que la invocación que no implica gc siempre de ejecución)

(Lo anterior es para el logging part and gc basado en el crecimiento del uso)

Para programar gc: Además, puede mantener una clase de tarea de temporizador que se ejecuta cada pocas horas y solicita gc.

Answer 5

¿Has mirado JConsole? Utiliza JMX para darle visibilidad de una variedad de métricas de JVM, incluida la información de memoria. Probablemente valga la pena monitorear su aplicación usando esto para comenzar, para tener una idea de cómo/cuándo se consume la memoria. Es posible que la memoria se consuma de manera uniforme durante el día o cuando se utilizan ciertas funciones.

Eche un vistazo a la sección detecting low memory del enlace de arriba.

Si lo necesita, puede escribir un JMX client para ver la aplicación automáticamente y desencadenar las acciones necesarias. JConsole indicará qué métodos JMX necesita para sondear.

Answer 6

¿Has echado un vistazo a la herramienta jvisualvm en los últimos Java 6 JDK's?

Es ideal para inspeccionar el código de ejecución.

Answer 7

Discutiría que necesita los volcados del montón cuando ocurre el OOM. La recopilación periódica de la información a lo largo del tiempo debería dar una idea de lo que está sucediendo.

Como se ha observado, existen varias herramientas para analizar estos problemas. He tenido éxito con ITCAM for WebSphere, como IBMer tengo acceso inmediato a eso. Rápidamente pudimos identificar las líneas exactas de código en nuestra situación problemática.

Si hay alguna manera de que pueda obtener una herramienta de esa naturaleza, ese es el camino a seguir.

Answer 8

Nuestra experiencia con ITCAM ha sido menos que estelar desde la perspectiva del monitoreo. Lo tiramos a favor de CA Wily Introscope.

Answer 9

Debería ser posible escribir un programa simple para obtener la lista de procesos del kernel y escanearla para ver si su proceso WAS aún se está ejecutando. En una caja de Unix probablemente puedas utilizar algo en Perl en pocos minutos (si conoces a Perl), sin estar seguro de lo difícil que sería con Windows. Ejecútelo como una tarea programada cada cinco minutos más o menos, y si el proceso no aparece, puede hacer que bifurque otro proceso que se ocupe del volcado de pila y vuelva a iniciar WAS.