Incluir en contenedores las aplicaciones de Java

En este artículo se proporciona información general sobre las estrategias y la configuración recomendadas para la contenedorización de aplicaciones Java.

Al incluir en contenedores una aplicación De Java, tenga en cuenta cuidadosamente cuánto tiempo de CPU tendrá disponible el contenedor. A continuación, tenga en cuenta la cantidad de memoria disponible en términos de cantidad total de memoria y el tamaño del montón de la máquina virtual Java (JVM). En entornos en contenedores, las aplicaciones pueden tener acceso a todos los procesadores y, por tanto, pueden ejecutar varios subprocesos en paralelo. Sin embargo, es habitual que los contenedores tengan aplicada una cuota de CPU que pueda limitar el acceso a las CPU.

JVM tiene heurística para determinar el número de "procesadores disponibles" en función de la cuota de CPU, lo que puede influir considerablemente en el rendimiento de las aplicaciones Java. La memoria asignada al propio contenedor y el tamaño del área de montón de la JVM son tan importantes como los procesadores. Estos factores determinarán el comportamiento del recolector de elementos no utilizados (GC) y el rendimiento general del sistema.

Contenedorización de una nueva aplicación

Al incluir en contenedores una carga de trabajo de Java para una nueva aplicación, debe tener en cuenta dos cosas al pensar en la memoria:

• Memoria asignada al propio contenedor.
• Cantidad de memoria disponible para el proceso de Java.

Descripción de la ergonómica predeterminada de JVM

Las aplicaciones necesitan un punto de partida y una configuración. JVM tiene la ergonómica predeterminada con valores predefinidos que se basan en el número de procesadores disponibles y la cantidad de memoria en el sistema. Los valores predeterminados que se muestran en las tablas siguientes se usan cuando se inicia la JVM sin marcas de inicio o parámetros específicos.

En la tabla siguiente se muestra el GC predeterminado usado para los recursos disponibles:

Recursos disponibles	GC predeterminado
Cualquier número de procesadores Hasta 1791 MB de memoria	SerialGC
Más de 2 procesadores 1792 MB o más de memoria	G1GC

En la tabla siguiente se muestra el tamaño máximo predeterminado del montón en función de la cantidad de memoria disponible en el entorno en el que se ejecuta la JVM:

Memoria disponible	Tamaño máximo predeterminado del montón
Hasta 256 MB	50 % de la memoria disponible
256 MB a 512 MB	~127 MB
Más de 512 MB	25 % de la memoria disponible

El tamaño del montón inicial predeterminado es 1/64 de memoria disponible.

Estos valores son válidos para OpenJDK 11 y versiones posteriores, y para la mayoría de las distribuciones, como Microsoft Build de OpenJDK, Azul Zulu, Eclipse Temurin, Oracle OpenJDK y otros.

Determinación de la memoria del contenedor

Elija una cantidad de memoria de contenedor que sirva mejor la carga de trabajo, según las necesidades de la aplicación y sus patrones de uso distintivos. Por ejemplo, si la aplicación crea gráficos de objetos grandes, probablemente necesitará más memoria de la que necesitaría para las aplicaciones con muchos gráficos de objetos pequeños.

Sugerencia

Si no sabe cuánta memoria asignar, un buen punto de partida es de 4 GB.

Determinación de la memoria del montón de JVM

Al asignar memoria del montón de JVM, tenga en cuenta que la JVM necesita más memoria que lo que se usa para el montón de JVM. Cuando se establece la memoria máxima del montón de JVM, nunca debe ser igual a la cantidad de memoria del contenedor, ya que esto provocará errores de memoria insuficiente (OOM) del contenedor y bloqueos de contenedor.

Sugerencia

Asigne el 75 % de la memoria del contenedor para el montón de JVM.

En OpenJDK 11 y versiones posteriores, puede establecer el tamaño del montón de JVM de las maneras siguientes:

Descripción	Marcar	Ejemplos
Valor fijo	-Xmx	-Xmx4g
Valor dinámico	-XX:MaxRAMPercentage	-XX:MaxRAMPercentage=75

Tamaño mínimo o inicial del montón

Cuando se garantiza que el entorno tiene una cierta cantidad de memoria reservada a una instancia de JVM, como en un contenedor, debe establecer el tamaño mínimo del montón (o el tamaño inicial del montón) en el mismo tamaño que el tamaño máximo del montón. Esta configuración indica a la JVM que no debe realizar la tarea de liberar memoria al sistema operativo.

Para establecer un tamaño mínimo de montón, use -Xms para cantidades absolutas o -XX:InitialRAMPercentage para cantidades porcentuales.

Importante

La marca -XX:MinRAMPercentage, a pesar de lo que sugiere el nombre, se usa para establecer el porcentaje de RAM máximo predeterminado para los sistemas con hasta 256 MB de RAM disponibles en el sistema.

Determinar qué GC se va a usar

Anteriormente, determinó la cantidad de memoria del montón de JVM con la que empezar. El siguiente paso es elegir la GC. La cantidad máxima de memoria del montón de JVM que tiene suele ser un factor en la elección de la GC. En la tabla siguiente se describen las características de cada GC.

Factores	SerialGC	ParallelGC	G1GC	ZGC	ShenandoahGC
Número de núcleos	1	2	2	2	2
Multiproceso	No	Sí	Sí	Sí	Sí
Tamaño del montón de Java	<4 GBytes	<4 GBytes	>4 GBytes	>4 GBytes	>4 GBytes
Pausar	Sí	Sí	Sí	Sí (<1 ms)	Sí (<10 ms)
Gastos generales	Mínimo	Mínimo	Moderado	Moderado	Moderado
Efecto de latencia de cola	Alto	Alto	Alto	Bajo	Moderada
Versión de JDK	All	All	JDK 8+	JDK 17+	JDK 11+
Más adecuado para	Montones pequeños de núcleo único	Montones pequeños de varios núcleos o cargas de trabajo por lotes con cualquier tamaño de montón	Capacidad de respuesta en montones medianos y grandes (interacciones de solicitud-respuesta/base de datos)	Capacidad de respuesta en montones medianos y grandes (interacciones de solicitud-respuesta/base de datos)	Capacidad de respuesta en montones medianos y grandes (interacciones de solicitud-respuesta/base de datos)

Sugerencia

Para la mayoría de las aplicaciones de microservicios de uso general, comience con la GC paralela.

Determinar cuántos núcleos de CPU se necesitan

Para cualquier GC que no sea SerialGC, se recomiendan dos o más núcleos de vCPU, o al menos 2000mcpu_limit en Kubernetes. No se recomienda seleccionar nada menos de 1 núcleo de vCPU en entornos en contenedores.

Sugerencia

Si no sabe cuántos núcleos empezar, una buena opción es 2 núcleos de vCPU.

Selección de un punto de partida

Se recomienda empezar con dos réplicas o instancias en entornos de orquestación de contenedores como Kubernetes, OpenShift, Azure Spring Apps, Azure Container Apps y App de Azure Service. En la tabla siguiente se resumen los puntos de partida recomendados para la contenedorización de la nueva aplicación Java.

vCPU cores	Memoria de contenedor	Tamaño del montón de JVM	GC	Réplicas
2	4 GB	75 %	ParallelGC	2

Los parámetros de JVM que se van a usar son: -XX:+UseParallelGC -XX:MaxRAMPercentage=75

Contenedorización de una aplicación existente (local)

Si la aplicación ya se está ejecutando de forma local o en una máquina virtual en la nube, se recomienda empezar por:

• La misma cantidad de memoria a la que tiene acceso la aplicación actualmente.
• El mismo número de CPU (núcleos de vCPU) que la aplicación tiene disponible actualmente.
• Los mismos parámetros de JVM que usa actualmente.

Si los núcleos de vCPU o la combinación de memoria del contenedor no están disponibles, elija el más cercano, redondeando los núcleos de vCPU y la memoria del contenedor.

Pasos siguientes

Ahora que comprende las recomendaciones generales para la inclusión en contenedores de aplicaciones Java, continúe con el siguiente artículo para establecer una línea de base de contenedorización:

• Establecimiento de una línea de base para aplicaciones Java en contenedor