Dimensionar en MiB el límite de memoria de un contenedor
La capacidad te llega en gibibytes: un nodo anuncia 16 Gi de memoria asignable, la cuota de un espacio de nombres le concede 64 Gi a un equipo. Pero el campo que tienes que llenar —resources.limits.memory en el manifiesto de un pod, o el número después de -Xmx— casi siempre se escribe en mebibytes. Pasar ese cupo en Gi a la cifra en Mi es la primera cuenta de toda sesión de ajuste de montículo, y la que más se hace al ojo.
MiB = GiB × 1024. Una asignación de 6 GiB son 6 × 1024 = 6144 MiB, así que la línea del manifiesto queda limits.memory: 6144Mi. Divide entre 1024 para volver.Mi no es lo mismo que M
Mi es un mebibyte (1.048.576 bytes) mientras que una M sola es un megabyte. Escribir 512M donde querías 512Mi encoge la asignación en 23,72 MiB sin que nada te avise.-Xmx habla en la misma base
m y g de la JVM también son binarios, así que -Xmx4g y -Xmx4096m piden el mismo montículo. Eso convierte el ×1024 en el idioma compartido entre el manifiesto y las banderas de la JVM.El montículo no es el contenedor
-Xmx. Si igualas el montículo al límite, el cgroup toca su techo antes de que el recolector sienta la menor presión.Convertir un cupo en Gi en un número de montículo
Escribe la cifra en Gi
Mete en el campo izquierdo el número en gibibytes de tu cuota o de la descripción del nodo. Las fracciones no son problema: 1.5 y 1,5 funcionan igual, y los espacios se ignoran.
Copia el número pelado en MiB
El botón de copiar deja en el portapapeles solo los dígitos, sin unidad pegada: exactamente lo que va delante de Mi en el YAML o después de -Xmx en un argumento de la JVM.
Aparta la reserva nativa
Recorta una tajada de ese total en MiB para todo lo que vive fuera del montículo. Un cuarto del límite es una reserva inicial habitual en un servicio en Java, que después se ajusta con las gráficas de consumo.
Revisa un pod en marcha al revés
Los tableros reportan la memoria del conjunto de trabajo en MiB. Pulsa intercambiar unidades para voltear la dirección y leer esa cifra en vivo como gibibytes frente a la capacidad de nodo que te prometieron.
Los dos campos siguen editables, así que escribir del lado de los MiB convierte de vuelta a GiB sin ningún paso extra. Cada lado lleva además una lista de unidades con búsqueda, útil cuando un reporte de costos cita la misma asignación en otra unidad.
Límites de contenedor y valores de montículo, lado a lado
Estos son los límites que más aparecen en despliegues reales, convertidos a mebibytes y repartidos en montículo y reserva fuera del montículo con un 75/25. La columna de la reserva es la holgura que mantiene a un pod fuera de la lista de OOMKilled.
| Límite del contenedor | El mismo límite en MiB | Montículo al 75 % | Reserva fuera del montículo |
|---|---|---|---|
| 0,5 Gi | 512 MiB | 384 MiB | 128 MiB |
| 1 Gi | 1.024 MiB | 768 MiB | 256 MiB |
| 2 Gi | 2.048 MiB | 1.536 MiB | 512 MiB |
| 4 Gi | 4.096 MiB | 3.072 MiB | 1.024 MiB |
| 8 Gi | 8.192 MiB | 6.144 MiB | 2.048 MiB |
| 16 Gi | 16.384 MiB | 12.288 MiB | 4.096 MiB |
Los contenedores chicos son donde más muerde la proporción. Con 512 MiB la reserva es apenas 128 MiB, y el metaspace más unas cuantas decenas de pilas de hilos se comen casi todo, por eso los pods de Java pequeños necesitan un porcentaje de montículo más bajo que los grandes, y no el mismo a escala.
Lee los números del manifiesto tal cual
Los valores fraccionarios en Gi como 1,5 o 2,5 se convierten limpio a 1.536 y 2.560 MiB, así que puedes elegir un límite intermedio entre las potencias de dos redondas.
Listo para pegar en YAML y en banderas
Cada campo copia el número sin adornos, así que entra en limits.memory o en una cadena JAVA_OPTS sin que un sufijo perdido rompa el análisis.
Funciona desde cualquiera de los dos extremos
Empieza del lado de los MiB cuando el número salió de un panel de métricas, o del lado de los GiB cuando salió de una cuota. Intercambiar unidades reetiqueta el par en un clic.
Nada sale del navegador
Las cifras de dimensionamiento de un clúster son información interna. Todo se calcula en tu propia máquina una vez que la página cargó.
Dudas sobre la memoria de contenedores
¿Mi en un manifiesto de Kubernetes significa lo mismo que MiB?
Sí. Los sufijos de cantidad Ki, Mi, Gi y Ti son las unidades binarias del IEC, así que 1Gi son 1.024 mebibytes. Los sufijos sin la i pertenecen al conjunto decimal, y las dos formas son válidas dentro del mismo archivo: justo por eso una errata de un solo carácter pasa la revisión sin que nadie la note.
¿Por qué dejar holgura entre el montículo de la JVM y el límite del contenedor?
El cgroup cuenta cada byte que el proceso toca. Las pilas de hilos, el metaspace, la caché de código del JIT, las estructuras del recolector y los búferes directos se apilan encima de -Xmx. Cuando ese total cruza el límite, el núcleo mata el proceso de golpe, sin degradación amable previa, así que la reserva se planea de antemano y no se descubre durante un incidente.
¿Qué reserva realmente -Xmx4g y cómo lo escribo en MiB?
-Xmx4g limita el montículo a 4 GiB, que son 4.096 MiB e idéntico a -Xmx4096m. Esos sufijos siempre han sido binarios en la JVM, así que no hace falta ningún ajuste al mover un valor entre una bandera y un campo Mi. Las versiones modernas de la JVM también aceptan un porcentaje del límite de contenedor que detectan, lo que ahorra editar en dos lugares cada vez que cambia el límite.
¿La caché de páginas de Linux cuenta contra el límite de memoria de mi pod?
Las páginas de archivo en caché se le cargan al cgroup, así que un contenedor que lee o escribe mucho se ve mucho más cerca de su límite de lo que sugiere el montículo por sí solo. El núcleo recupera esa caché bajo presión en vez de matar al pod por ella. Cuando una gráfica en MiB se vea alarmante, revisa si el crecimiento es memoria anónima o solo caché antes de subir el límite en Gi.
¿Conviene escribir en Mi tanto las peticiones como los límites de memoria?
Mantener los dos en una sola unidad es la costumbre práctica, y Mi da control fino sin decimales. La petición es lo que usa el planificador para colocar el pod; el límite es lo que impone el núcleo. Escribir uno en Gi y el otro en Mi es válido, pero vuelve difícil juzgar de un vistazo la distancia entre ambos cuando revisas un diff.
Aún no hay comentarios. ¡Sé el primero en comentar!