Herramientas para solucionar problemas de memoria
Nota:
Azure Spring Apps es el nuevo nombre del servicio Azure Spring Cloud. Aunque el servicio tiene un nuevo nombre, verá el nombre antiguo en algunos lugares durante un tiempo mientras trabajamos para actualizar recursos, como capturas de pantalla, vídeos y diagramas.
La información de este artículo puede ponerse en práctica en: ✔️ Básico o Estándar ✔️ Enterprise
En este artículo se describen varias herramientas que son útiles para solucionar problemas de memoria de Java. Puede usar estas herramientas en muchos escenarios no solo de problemas de memoria, pero este artículo se centra solo en el tema de la memoria.
Alertas y diagnósticos
En las secciones siguientes se describen las alertas y diagnósticos de estado de los recursos disponibles a través de Azure Portal.
Estado de los recursos
Puede supervisar los eventos del ciclo de vida de la aplicación y configure alertas con el registro de actividad de Azure y Azure Service Health. Para más información, consulte Supervisión de eventos del ciclo de vida de la aplicación mediante el registro de actividad de Azure y Azure Service Health.
Resource Health envía alertas sobre los eventos de reinicio de la aplicación debido a problemas de memoria insuficiente (OOM) del contenedor. Para obtener más información, consulte Problemas de reinicio de la aplicación causados por problemas de memoria insuficiente.
En la captura de pantalla siguiente se muestra una alerta de estado de los recursos de la aplicación que indica un problema de OOM.
Diagnóstico y solución de problemas
Los diagnósticos de Azure Spring Apps constituyen una experiencia interactiva para la solución de problemas de las aplicaciones sin configuración. Para más información, consulte Autodiagnóstico y solución de problemas en Azure Spring Apps.
En Azure Portal, puede encontrar Uso de memoria en Diagnosticar y resolver problemas, como se muestra en la captura de pantalla siguiente.
Uso de memoria proporciona un diagnóstico sencillo para el uso de memoria de la aplicación, como se muestra en la captura de pantalla siguiente.
Métricas
En las secciones siguientes se describen las métricas que cubren problemas como el uso elevado de memoria, la memoria en montón demasiado grande y la recolección anómala de elementos no utilizados (demasiado frecuente o no lo suficientemente frecuente). Para más información, consulte Inicio rápido: supervisión de aplicaciones de Azure Spring Apps con registros, métricas y seguimiento.
Uso de memoria de la aplicación
El uso de memoria de la aplicación es un porcentaje igual a la memoria de la aplicación utilizada dividida por el límite de memoria de la aplicación. Este valor muestra toda la memoria de la aplicación.
jvm.memory.used/committed/max
Para la memoria de JVM, hay tres métricas: jvm.memory.used, jvm.memory.committed y jvm.memory.max, que se describen en la lista siguiente.
"Memoria de JVM" no es un concepto claramente definido. Aquí, jvm.memory es la suma de la memoria en montón y la antigua parte de permGen de la memoria sin montón. La memoria de JVM no incluye memoria directa ni otra memoria como la pila de subprocesos. El accionador de Spring Boot recopila estas tres métricas y determina el ámbito de jvm.memory.
jvm.memory.usedes la cantidad de memoria de JVM usada, incluida la memoria en montón usada y el antiguo permGen en memoria sin montón.jvm.memory.usedes un reflejo importante del cambio de la memoria en montón, ya que la antigua parte de permGen suele ser estable.Si encuentra que
jvm.memory.usedes demasiado grande, considere la posibilidad de establecer un tamaño máximo de memoria en montón más pequeño.jvm.memory.committedes la cantidad de memoria confirmada que usará la JVM. El tamaño dejvm.memory.committedes básicamente el límite de memoria de JVM utilizable.jvm.memory.maxes la cantidad máxima de memoria de JVM, que no debe confundirse con la cantidad disponible real.El valor de
jvm.memory.maxa veces puede resultar confuso, porque puede ser mucho mayor que la memoria de la aplicación disponible. Para aclararlo,jvm.memory.maxes la suma de todos los tamaños máximos de memoria en montón y la antigua parte de permGen de memoria sin montón, independientemente de la memoria disponible real. Por ejemplo, si una aplicación se establece con 1 GB de memoria en el portal de Azure Spring Apps, el tamaño de memoria del montón predeterminado es de 0,5 GB. Para obtener más información, consulte la sección Tamaño máximo predeterminado del montón de Administración de memoria de Java.Si el tamaño de espacio de clase comprimido predeterminado es de 1 GB, el valor de es mayor que 1,5 GB, independientemente de si el tamaño de memoria de
jvm.memory.maxla aplicación es de 1 GB. Para obtener más información, consulte Guía de ajuste de la recolección de elementos no utilizados de máquinas virtuales HotSpot de la Standard Edition de la plataforma de Java en la documentación de Oracle.
jvm.gc.memory.allocated/promoted
Estas dos métricas son para observar la recolección de elementos no utilizados (GC) de Java. Para obtener más información, consulte la sección Recolección de elementos no utilizados de Java de Administración de memoria de Java. El tamaño máximo del montón influye en la frecuencia de la GC secundaria y la GC completa. El metaespacio máximo y el tamaño máximo de memoria directa influyen en la GC completa. Si desea ajustar la frecuencia de recolección de elementos no utilizados, considere la posibilidad de modificar los siguientes tamaños máximos de memoria.
jvm.gc.memory.allocatedes el aumento del tamaño del grupo de memoria de nueva generación después de una recolección de elementos no utilizados y antes de la siguiente. Este valor refleja la GC secundaria.jvm.gc.memory.promotedes la cantidad de aumento en el tamaño del grupo de memoria de la antigua generación después de GC. Este valor refleja la GC completa.
Puede encontrar esta característica en Azure Portal, como se muestra en la captura de pantalla siguiente. Puede elegir métricas específicas y agregar filtros para una aplicación, una implementación o una instancia específicas. También puede aplicar una división.
Depuración adicional
Para realizar una depuración adicional, puede capturar manualmente volcados de memoria en montón y volcados de memoria en subprocesos, y usar Java Flight Recorder (JFR). Para más información, consulte Captura del volcado de memoria del montón y del volcado de memoria de subproceso manualmente y uso de Java Flight Recorder en Azure Spring Apps.
Los volcados de montón registran el estado de la memoria del montón de Java. Los volcados de subproceso registran las pilas de todos los subprocesos activos. Estas herramientas están disponibles a través de la CLI de Azure y en la página de la aplicación de Azure Portal, como se muestra en la captura de pantalla siguiente.
Para más información, consulte Captura del volcado de memoria del montón y del volcado de memoria de subproceso manualmente y uso de Java Flight Recorder en Azure Spring Apps. También puede usar herramientas de terceros como el Analizador de memoria para analizar volcados de memoria en montón.
Modificación de configuraciones para corregir problemas
Algunos problemas que puede identificar son OOM del contenedor, la memoria en montón demasiado grande y la recolección anómala de elementos no utilizados. Si identifica alguno de estos problemas, es posible que tenga que configurar el tamaño máximo de memoria en las opciones de JVM. Para obtener más información, consulte la sección Opciones importantes de JVM de Administración de memoria de Java.
Puede modificar las opciones de JVM mediante Azure Portal o la CLI de Azure.
En Azure Portal, vaya a la aplicación y seleccione Configuración en la sección Configuración del menú de navegación. En la pestaña General Configuración, actualice el campo Opciones de JVM, como se muestra en la captura de pantalla siguiente:
