Problemas de reinicio de la aplicación causados por problemas de memoria insuficiente
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 los problemas de memoria insuficiente (OOM) para las aplicaciones Java en Azure Spring Apps.
Tipos de problemas de memoria insuficiente
Hay dos tipos de problemas de memoria insuficiente: OOM en contenedor y OOM en JVM.
El OOM en contenedor, también denominado OOM en el sistema, se produce cuando se ha agotado la memoria de la aplicación disponible. El problema de OOM en contenedor provoca eventos de reinicio de la aplicación, que se notifican en la sección Resource Health de Azure Portal. Normalmente, el problema de OOM en contenedor se debe a configuraciones de tamaño de memoria incorrectas.
El problema de OOM en JVM se produce cuando la cantidad de memoria usada ha alcanzado el tamaño máximo establecido en las opciones de JVM. OOM en JVM no hará que se reinicie la aplicación. Normalmente, OOM en JVM es un resultado de código incorrecto, que puede encontrar buscando excepciones
java.lang.OutOfMemoryErroren el registro de la aplicación. OOM en JVM tiene un efecto negativo en la aplicación y en las herramientas de generación de perfiles de Java, como Java Flight Recorder.
Este artículo se centra en cómo corregir problemas de OOM en contenedor. Para corregir problemas de OOM en JVM, consulte herramientas como volcado de memoria de montón, volcado de memoria de subproceso y Java Flight Recorder. 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.
Corrección de problemas de reinicio de la aplicación debido a OOM
En las secciones siguientes se describen las herramientas, las métricas y las opciones de JVM que puede usar para diagnosticar y corregir problemas de OOM en contenedor.
Visualización de alertas en la página Resource Health
En la página Resource Health de Azure Portal se muestran los eventos de reinicio de la aplicación debido a OOM en contenedor, como se muestra en la captura de pantalla siguiente:
Configuración del tamaño de memoria
Las métricas Uso de memoria de la aplicación, jvm.memory.used y jvm.memory.committed proporcionan una vista del uso de memoria. Para más información, consulte la sección Métricas de Herramientas para solucionar problemas de memoria. Configure los tamaños máximos de memoria en las opciones de JVM para asegurarse de que la memoria está por debajo del límite.
La suma de los tamaños máximos de memoria de todas las partes del modelo de memoria de Java debe ser menor que la memoria real disponible de la aplicación. Para establecer los tamaños máximos de memoria, consulte el diseño de memoria típico descrito en la sección Diseño de uso de memoria de Administración de memoria de Java.
Busque un equilibrio al establecer el tamaño máximo de memoria. Cuando se establece un tamaño máximo de memoria demasiado alto, existe un riesgo de OOM en contenedor. Cuando se establece un tamaño máximo de memoria demasiado bajo, hay un riesgo de OOM en JVM y la recolección de elementos no utilizados ralentizará la aplicación.
Control de la memoria en montón
Puede establecer el tamaño máximo del montón mediante las opciones de JVM -Xms, -Xmx, -XX:InitialRAMPercentage y -XX:MaxRAMPercentage.
Es posible que tenga que ajustar la configuración de tamaño máximo del montón cuando el valor de jvm.memory.used sea demasiado alto en las métricas. Para más información, consulte la sección jvm.memory.used/committed/max en Herramientas para solucionar problemas de memoria.
Controlar la memoria directa
Es importante establecer la opción de JVM -XX:MaxDirectMemorySize por los siguientes motivos:
- Es posible que no se de cuenta cuándo los marcos como nio y gzip usan memoria directa.
- La recolección de elementos no utilizados de memoria directa solo se controla durante la recolección completa de elementos no utilizados y la recolección completa de elementos no utilizados solo se produce cuando el montón está cerca de lleno.
Normalmente, puede establecer MaxDirectMemorySize en un valor menor que el tamaño de memoria de la aplicación menos la memoria en montón menos la memoria sin montón.
Control del metaespacio
Puede establecer el tamaño máximo del metaespacio estableciendo la opción de JVM -XX:MaxMetaspaceSize. La opción -XX:MetaspaceSize establece el valor de umbral para desencadenar la recolección completa de elementos no utilizados.
La memoria del metaespacio suele ser estable.