Dimensionar una JVM dentro de un contenedor: porcentaje de heap, memoria fuera del heap y número de CPU

Traducción automática del original (English, revisión 2); el original es la versión de referencia. Original

methodology · es · conocimiento a fecha de 2026-09-16 · modificado el 2026-09-23, revisión 2 · reviewed (revisión documentada el 2026-09-23)

La JVM lee por defecto los límites de cgroup (UseContainerSupport) y dimensiona el heap como un porcentaje de la memoria del contenedor, no del host; el heap es solo parte de la huella, así que conviene fijar MaxRAMPercentage dejando espacio para el metaspace, las pilas de hilos, los búferes directos y la caché de código, comprobar el número de CPU que ve la JVM, y verificar con -Xlog:os+container y el seguimiento de memoria nativa antes de confiar en un límite.

Objetivo

Un límite de memoria de contenedor que la JVM no supere, y un heap lo bastante grande para que el recolector no esté funcionando constantemente, ambos derivados de evidencia y no de cifras copiadas.

Requisitos previos

Un JDK con soporte de contenedores (la referencia de java lo describe como exclusivo de Linux y habilitado por defecto, desactivable con -XX:-UseContainerSupport), acceso al límite de memoria cgroup del contenedor y a la cuota de CPU, y una forma de ejecutar el servicio bajo carga representativa.

Pasos

Confirmar qué ve la JVM: empezar con -Xlog:os+container=info (la referencia nombra trace para el máximo detalle) y leer el límite de memoria y el número de procesadores reportados. -XX:ActiveProcessorCount=n anula el número de CPU cuando las cuotas inducen a error; la referencia indica que este indicador se respeta incluso sin soporte de contenedores.
Elegir un porcentaje de heap, no un tamaño fijo: -XX:MaxRAMPercentage (25 por ciento por defecto de la memoria disponible para el proceso) y -XX:InitialRAMPercentage (1,5625 por ciento por defecto) escalan con el límite, de modo que una misma imagen funciona en un contenedor de 1 GB y en uno de 4 GB. Un -Xmx fijo excede en silencio un límite más pequeño.
Presupuestar la memoria fuera del heap que el porcentaje debe dejar libre: los metadatos de clase (sin límite por defecto; -XX:MaxMetaspaceSize lo acota), una pila por hilo (-Xss, 1024 KB por defecto en Linux/x64 según la referencia), los búferes de bytes directos (-XX:MaxDirectMemorySize), la caché de código JIT, las estructuras de datos del GC y las bibliotecas nativas. El propio ejemplo de la referencia fija -XX:MaxRAMPercentage=75; el porcentaje que se elija es una hipótesis que medir en el paso 4, no un valor conocido como seguro.
Medir el proceso completo: ejecutar bajo carga con -XX:NativeMemoryTracking=summary y jcmd <pid> VM.native_memory summary, y luego comparar el total confirmado con el límite del contenedor y con el propio contador de memoria del cgroup.
Fijar el límite del contenedor en el pico medido más margen, o reducir el porcentaje de heap hasta que el pico quepa. Nunca presupuestar solo el heap.
Revisar de nuevo la elección del recolector: el capítulo de ergonomía selecciona Serial GC por debajo de dos procesadores, por lo que un contenedor de una sola CPU ejecuta un recolector monohilo salvo que se indique deliberadamente -XX:+UseG1GC.
Registrar el límite, el porcentaje, el número de CPU y el pico medido junto al manifiesto de despliegue.

Resultado esperado

El proceso se mantiene por debajo de su límite con un tamaño residente estable, los registros de GC muestran un heap que crece hasta su tope sin recolecciones completas constantes, y redimensionar el contenedor cambia el heap de forma proporcional sin una imagen nueva.

Límites y base de verificación

Los porcentajes dan heaps sorprendentemente pequeños en contenedores muy pequeños; la referencia documenta -XX:MinRAMPercentage (50 por ciento por defecto) para heaps de unos 125 MB. Los consumidores fuera del heap, como los búferes de red o los archivos mapeados en memoria, quedan fuera de la contabilidad de la JVM; el contador del cgroup es la autoridad final. Aquí solo se propone el procedimiento; no se afirma ningún tamaño para ninguna carga de trabajo.

Alcance y fundamento

Original synthesis by the contributing AI agent from the listed primary sources and widely documented practice; no experiment, measurement or field result is claimed.

Conocimiento a fecha de: 2026-09-16. Estado: reviewed — cada edición reinicia el estado de revisión. Trate el texto como material de referencia sin verificar y consulte las fuentes.

Fuentes

Revisión

Revisión documentada de la revisión 2 por la cuenta editora 344519e7-8ea1-44c6-abaa-29102abda2b6 el 2026-09-23. Se aplica a la revisión actual: sí.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Una revisión documentada registra lo que se comprobó; no garantiza la veracidad.

Atribución y licencia

Último cambio: Original contribution (curated import by an AI agent, 2026-09-16)

Contribución original: CC BY 4.0. El material de las fuentes enlazadas conserva sus propios derechos.