Convertir MiB a GiB

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

Un gibibyte son 1.073.741.824 bytes, alrededor de un 7 % más que un gigabyte. Windows mide en gibibytes pero los etiqueta «GB», y en eso consiste todo el misterio del espacio que desaparece.

En este sentido la cuenta es una división, y por un número entero: 1024 de estas caben en un gibibyte sin que sobre nada. Lo incómodo es solo que los resultados salen en fracciones —un tercio de gibibyte, un doceavo— en lugar de las cifras redondas que da el sentido contrario.

Aun así no se pierde nada al redondear, porque la división es exacta. Si el resultado no se queda quieto en decimales —0,0833… y parecidos—, eso es la fracción asomando, no un error colándose.

Un MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 0,001 GiB y 0,0009 GiB —un 4,9 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 4,9 %. Un disco vendido en MB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 0,0009 GiB donde la caja ponía 0,001 GiB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

Un gibibyte son 1.073.741.824 bytes y un mebibyte 1.048.576, así que la razón entre ambos es 1.024 clavados: un desplazamiento de diez bits sin redondeo. Un límite escrito 2048Mi y otro escrito 2Gi son la misma cantidad hasta el último byte, y cualquier herramienta que compare uno contra una cuota los trata como iguales. Es de las pocas conversiones de este sitio en las que no hay nada que decidir sobre decimales.

Lo que sí hay que decidir es en cuál de las dos se escribe. Por debajo de unos 2 GiB el mebibyte deja la cifra en número entero y se lee bien al lado de un ajuste de montículo; por encima, el gibibyte se compara mejor contra el tamaño de una máquina. Lo que conviene evitar es mezclar las dos dentro del mismo documento, porque obliga a convertir a todo el que quiera comparar dos líneas seguidas.

La CPU es comprimible: un contenedor que pide más de su límite se estrangula y sigue funcionando, despacio. La memoria no. Cuando el grupo de control del contenedor supera su límite, el núcleo termina un proceso de dentro, el contenedor devuelve el código de salida 137 y el pod se reinicia. No hay degradación progresiva ni aviso intermedio, y por eso un límite un cinco por ciento más pequeño de lo que se pretendía no es un error de redondeo sino un cambio en la frecuencia con la que muere un servicio.

De ahí que los dos sufijos fallen de manera asimétrica. Escribir M donde se quería Mi deja el límite más pequeño y el contenedor muere más a menudo: un fallo visible que alguien investiga. Escribir Mi donde se quería M lo deja más grande, y eso no se manifiesta en absoluto hasta que el nodo está sobrecomprometido y el planificador lleva meses colocando cargas sobre cifras ligeramente generosas. El segundo es el que cuesta dinero en silencio.

Una JVM arrancada con -Xmx4096m tiene un montículo de 4 GiB y una huella claramente mayor. El metaespacio guarda los metadatos de las clases y por defecto no tiene tope; cada hilo se lleva su pila, típicamente 1 MiB, fuera del montículo; la caché de código del compilador JIT tiene 240 MiB por defecto en HotSpot de 64 bits; los búferes directos que usan Netty y casi cualquier servidor basado en NIO son memoria nativa; y el recolector de basura mantiene sus propias estructuras. Un límite de contenedor igual a -Xmx es un contenedor que va a morir.

La práctica habitual es dar al contenedor entre un 25 y un 50 % más que el montículo, o dejar de fijar -Xmx y que la propia JVM se dimensione. Desde JDK 10 el entorno de ejecución lee el límite del grupo de control y aplica -XX:MaxRAMPercentage, cuyo valor por defecto es 25: lo bastante conservador como para que un contenedor de 4Gi acabe con un montículo de 1 GiB si nadie sube el porcentaje. Ponerlo en 70 o 75 y dejar que la máquina virtual haga la cuenta elimina uno de los dos números que pueden estar mal.

Un nodo anunciado como de 16 GiB no ofrece 16.384 MiB a los pods. La capacidad menos lo reservado para los componentes del clúster, menos lo reservado para el sistema, menos el umbral duro de desalojo da la cifra asignable, y en un clúster gestionado esa reserva va desde unos cientos de mebibytes en una máquina pequeña hasta bastante más de un gibibyte en una grande. Las dos cifras se imprimen una al lado de otra al describir el nodo, y la diferencia entre ellas es la que decide cuántas réplicas caben.

Aquí es donde convertir a gibibytes se gana el sueldo, porque hacer las cuentas de empaquetado en mebibytes invita al error. Nueve réplicas de 1.536Mi son 13.824Mi, es decir 13,5 GiB, que caben dentro de 14,6 GiB asignables con sitio para los demonios del nodo y no caben si la reserva resultó ser mayor de lo que parecía. Sumar en mebibytes y comparar contra un nodo anunciado en gibibytes es la manera habitual de acabar con una réplica menos de las previstas sin causa aparente.

La petición es lo que reserva el planificador y el límite es lo que hace cumplir el núcleo, y la relación entre ambos decide la prioridad de desalojo del pod. Petición y límite iguales dan la clase garantizada; una petición menor que el límite da la clase ampliable; no declarar ninguna de las dos da la clase de mejor esfuerzo, que es la primera en caer cuando el nodo aprieta. La clase se deduce de los dos números en lugar de declararse, así que un manifiesto con 512Mi y 1Gi ha elegido «ampliable» lo pretendiera alguien o no.

Para la memoria en concreto, el argumento a favor de igualarlas es más fuerte que para la CPU. Un pod ampliable que consume habitualmente más que su petición se planifica como si fuera pequeño y se mata como si fuera grande, y el nodo en el que aterriza queda sobrecomprometido sobre una cifra que nadie comprobó. Cuando el conjunto de trabajo se conoce, escribir dos veces el mismo número en gibibytes es más simple y más honesto que una horquilla que nadie va a revisar.

El manifiesto dice 1536Mi; el panel de métricas dice 1,5 GiB; la consola del proveedor dice 1,61 GB; el informe de costes dice 1,6 GB-hora. Los cuatro son los mismos 1.610.612.736 bytes presentados por cuatro herramientas con convenios distintos, y solo los dos primeros están del lado binario. Cuadrar una factura contra un manifiesto exige saber en qué lado está cada cifra antes de compararlas, y un hueco del 7,4 % es lo bastante grande como para parecer una discrepancia real.

La costumbre que ayuda es fijar una unidad canónica por documento. Los planes de capacidad en gibibytes, los manifiestos en la de las dos que deje la cifra entera, y cualquier número en unidad decimal etiquetado como tal. Una hoja de cálculo cuya cabecera diga GiB y cuyos números salgan de una consola que informa en GB está equivocada en una quinceava parte y seguirá estándolo hasta que alguien la rehaga entera.

La cifra que merece convertirse es la que la carga usa de verdad, y la métrica del conjunto de trabajo del contenedor es sobre la que actúa efectivamente el núcleo: memoria residente menos la caché de páginas que se puede reclamar. Tomar su máximo a lo largo de dos semanas, añadir holgura y redondear hacia arriba a una cifra limpia en mebibytes o gibibytes produce un límite defendible; tomar la memoria residente en bruto, o peor, lo que la propia JVM dice de su montículo, produce uno que no lo es.

Redondee hacia arriba a una potencia de dos siempre que salga gratis. Un límite de 1.536Mi son 1,5 GiB y encaja limpio en nodos medidos en gibibytes; uno de 1.600Mi son 1,5625 GiB, encaja mal y le cuenta al siguiente lector que el número salió de un cálculo decimal en algún punto de la cadena. La aritmética es exacta en los dos sentidos, así que lo único que se está optimizando es la legibilidad para quien tenga que cambiarlo.