Análisis de los ficheros de registro del recolector de basura (GC) para supervisar incidencias de memoria
Se recomienda activar el registro de GC en entornos de producción. Consulte la sección
Supervisión del uso de la memoria de un servidor ThingWorx, para obtener más información sobre cómo activar el registro de GC. Una vez que se haya activado el registro de GC, se registra toda la actividad de GC en el servidor. Si la JVM no responde durante períodos de tiempo prolongados, puede que las herramientas externas, como PSM o VisualVM, no puedan recopilar datos de memoria. Sin embargo, la JVM puede imprimir la actividad de GC, lo que ayuda al usuario a identificar la causa de la incidencia de memoria.
Lectura de los registros de GC
Se pueden utilizar herramientas como, por ejemplo, GCEasy.io y Chewiebug GC Viewer, para analizar registros de GC. Los registros de GC también se pueden analizar manualmente en un editor de texto para verificar si hay incidencias comunes.
Por lo general, se imprime cada operación de limpieza de la memoria, tal como se muestra en el siguiente ejemplo.
1. Tiempo transcurrido desde el inicio de JVM
2. Tipo de GC
3. Motivo de la operación de GC
4. Young Generation ha limpiado de 549 M a 4 M
5. Tamaño total de Young Generation
6. Tiempo global para que se complete la operación de GC
7. Montón asignado
8. Memoria total de la aplicación que Java limpia
Consulte la documentación de Oracle para obtener más información sobre las operaciones de GC.
Una herramienta de análisis de GC convierte la representación de texto de las limpiezas en un gráfico más fácil de leer.
El análisis de los datos en el registro de GC ayuda a identificar los siguientes escenarios, que indican incidencias de memoria en la aplicación de ThingWorx:
• Operaciones de GC completas extremadamente largas (más de 45 segundos): se trata de operaciones stop-the-world, que no son nada deseables. Por ejemplo, la siguiente operación completa de GC tarda 46 segundos. Durante este tiempo, se detienen las demás actividades del usuario:
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• Operaciones completas de GC en un bucle: son operaciones completas de GC que ocurren en una sucesión rápida.
Por ejemplo, las cuatro recopilaciones de basura consecutivas siguientes tardan aproximadamente dos minutos en resolverse:
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• En el siguiente gráfico, los triángulos rojos de los picos del gráfico son indicaciones visuales de que las GC completas se producen en un bucle:
• Pérdidas de memoria: se producen cuando se conserva un número cada vez mayor de objetos en memoria y la memoria no se puede limpiar.
En el siguiente ejemplo, la memoria es cada vez más estable a pesar de los recolectores de basura:
Recomendación: si no se dispone de una herramienta automatizada, como PSM, para supervisar y registrar el uso de la memoria a lo largo del tiempo, se debe verificar diariamente si existen incidencias de memoria en los ficheros de registro de GC. Cuando se produzcan incidencias de memoria, se deben recopilar volcados de subprocesos o volcados de montón de JVM para identificar operaciones de ejecución prolongada. Estas operaciones pueden activar las incidencias de memoria subyacentes en la aplicación de ThingWorx.