La detección de la memoria de fugas mediante programación

Question

Si, en efecto, se crea una aplicación que cruje los datos mientras que sufren de memoria-fugas, puedo notar que la memoria según lo informado por, digamos:

Runtime.getRuntime().freeMemory() 

comienza a oscilar entre 1 y 2 MB de memoria libre.

La aplicación luego ingresa en un bucle que dice así: GC, procesando algunos datos, GC, etc. pero debido a que el GC ocurre con tanta frecuencia, la aplicación básicamente ya no hace mucho más. Incluso la GUI tarda años en responder (y, no, no estoy hablando de los problemas de EDT aquí, en realidad es la máquina virtual básicamente atrapada en un modo interminable de GC).

Y me preguntaba: ¿hay alguna forma de detectar mediante programación que la JVM ya no tiene suficiente memoria?

Tenga en cuenta que no estoy hablando de errores de memoria insuficiente ni de detectar la pérdida de memoria en sí.

Estoy hablando de detectar que una aplicación tiene tan poca memoria que básicamente está llamando al GC todo el tiempo, dejando casi ningún momento para hacer otra cosa (en mi ejemplo hipotético: datos crujientes).

¿Funcionaría, por ejemplo, leer repetidamente la cantidad de memoria disponible durante, digamos, un minuto, y ver si el número ha estado "oscilando" entre diferentes valores, digamos 4 MB, y concluye que ¿Ha habido alguna fuga y la aplicación se ha vuelto inutilizable?

Answer 1

Puede pasar argumentos a la máquina virtual de Java que proporciona diagnósticos GC como

1. -verbose:gc Esta bandera se convierte en el registro de la información de GC. Disponible en todas las JVM.

2. -XX:+PrintGCTimeStamps imprime las horas a las que suceden los CG en relación con el inicio de la aplicación .

Si captura que la salida en un archivo, en su aplicación se puede leer periodcly ese archivo y analizarlo para saber cuando el GC ha sucedido. Para que pueda calcular el tiempo promedio entre cada GC

Answer 2

Y me preguntaba: ¿hay alguna forma de detectar mediante programación que la JVM ya no tiene suficiente memoria?

No lo creo. Puede averiguar aproximadamente cuánta memoria Heap es gratuita en un instante dado, pero AFAIK no puede determinar de manera confiable cuándo se está quedando sin memoria. (Claro, puede hacer cosas como raspar los archivos de registro de GC o tratar de elegir patrones en las oscilaciones de memoria libres. Pero es probable que sean poco fiables y frágiles frente a los cambios de JVM).

Sin embargo, existe otro (y mejor IMO) enfoque.

En versiones recientes de Hotspot (versión 1.6 y posteriores, creo), puede sintonizar la JVM/GC para que se rinda y arroje un OOME antes.Específicamente, la JVM puede ser configurado para verificar que:

• la relación del montón libre de montón total es mayor que un umbral dado después de un GC completo, y/o
• el tiempo pasado de ejecutar el GC es menos que un cierto porcentaje del total.

Los parámetros de JVM relevantes son "UseGCOverheadLimit", "GCTimeLimit" y "GCHeapFreeLimit". Desafortunadamente, los parámetros de ajuste de Hotspot no están bien documentados en la web pública, pero estos están listados here.

Suponiendo que desea que su aplicación haga lo sensato ... renuncie cuando ya no tenga suficiente memoria para ejecutarse correctamente ... entonces simplemente inicie la JVM con un "GCTimeLimitor" o "GCHeapFreeLimit" más pequeño que los valores predeterminados.

EDITAR

he descubierto que el MemoryPoolMXBean API le permite buscar en el uso máximo de los bloques de memoria individuales (pilas) y conjunto de umbrales. Sin embargo, nunca lo he probado, y las API tienen muchas sugerencias que sugieren que no todas las JVM implementan la API completa. Por lo tanto, aún recomendaría el enfoque de opción de ajuste HotSpot (ver arriba) sobre este.

Answer 3

Veo dos vectores de ataque.

Cualquiera de los dos monitoree su consumo de memoria.

Cuando usa más o menos constantemente mucha de la memoria disponible, es muy probable que tenga una pérdida de memoria (o que esté utilizando demasiada memoria). El vm intentará constantemente liberar algo de memoria sin mucho éxito => uso de memoria constante.

Debe distinguirlo de un patrón en zigzag grande que ocurre a menudo sin ser un indicador de problema de memoria. Básicamente, usted usa más y más memoria, pero cuando gc encuentra tiempo para hacer su trabajo, encuentra mucha basura para llevar a cabo, así que todo está bien.

El otro vector de ataque es controlar la frecuencia y el tipo de éxito que ejecuta el gc. Si se ejecuta a menudo con solo pequeñas ganancias en la memoria, es probable que tenga un problema.

No sé si puede acceder a este tipo de información directamente desde su programa. Pero si nada más creo que puede especificar parámetros en el inicio que hace que la información de registro de gc en un archivo que a su vez podría ser analizado.

Answer 4

Puede usar getHeapMemoryUsage.

Answer 5

Lo que podría hacer es engendrar un hilo que se despierta periódicamente y calcula la cantidad de memoria utilizada y registra el resultado. Luego puede hacer regression analysis en el resultado para estimar la velocidad de crecimiento de la memoria en su aplicación. Si conoce la tasa de crecimiento y la cantidad máxima de memoria, puede predecir (con cierta confianza) cuándo se agotará la memoria de su aplicación.

Answer 6

Creo que la JVM hace exactamente esto por usted y arroja java.lang.OutOfMemoryError: GC overhead limit exceeded. Entonces, si tomas OutOfMemoryError y buscas ese mensaje, entonces tienes lo que quieres, ¿no?

Ver this question para más detalles

Answer 7

He estado usando plumbr para la detección de pérdida de memoria y ha sido una gran experiencia, aunque la licencia es muy caro: http://plumbr.eu/