Convertir GiB a 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.

Un megabyte es un millón de bytes. Los fabricantes de almacenamiento siempre han contado en decimal, y por eso sus cifras parecen mayores que lo que muestra el ordenador.

El factor es 1073,741824, y casi nadie lo lleva encima. Redondeado a 1070 se desvía un 0,35 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 GiB.

Ese es el dato que interesa antes de redondear: no el error en sí, sino a partir de dónde deja de ser despreciable. Por debajo de ahí el factor corto es el sensato; por encima, usa el campo de arriba, que no redondea hasta el momento de escribir el resultado.

Un GiB son 1.024 de la unidad de debajo; un GB, 1.000. En esta página eso es la diferencia entre 1073,7418 MB y 1000 MB —un 7,4 %—, 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 7,4 %. Un disco vendido en GB 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 1000 MB donde la caja ponía 1073,7418 MB. 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, así que 1 GiB equivale a 1.073,74 MB en lugar de a mil justos. La cifra que anuncia un plan de hosting —"2 GB de RAM", "4 GB de RAM"— es casi siempre binaria, porque es lo que informa el propio sistema operativo del servidor; el valor que pide memory_limit en el php.ini o en un .htaccess, en cambio, se escribe como 256M o 512M y PHP lo interpreta como megabytes binarios también, pero la costumbre de escribirlo así hace fácil pensar que son cifras decimales.

La confusión práctica aparece al sumar: un plan de "2 GB" no da margen para diez procesos PHP con memory_limit = 256M más el propio servidor web y la base de datos, aunque la aritmética ingenua de dividir 2.000 entre 256 sugiera que caben siete. 2 GiB son 2.147,48 MB reales, y descontando el sistema operativo y MySQL suele quedar sitio para bastantes menos.

El error clásico de WordPress —"Allowed memory size of X bytes exhausted"— imprime la cifra en bytes exactos, no en la unidad que se configuró, y esos bytes hay que convertirlos de vuelta para entender contra qué límite se chocó. Un aviso de 268.435.456 bytes es exactamente 256 MiB, la cifra habitual de un memory_limit = 256M: el número parece arbitrario hasta que se divide entre 1.048.576 y aparece el valor redondo.

Ese hábito de leer el mensaje de error en bytes y convertirlo a mebibytes en lugar de a megabytes decimales es lo que permite reconocer si el límite configurado es el que realmente se está aplicando, o si el panel de control está sobrescribiendo un valor distinto en otra capa —muy habitual en hosting compartido, donde cPanel, PHP-FPM y el propio código de WordPress pueden fijar tres límites distintos y solo el más bajo cuenta.

Un servidor con PHP-FPM lanza varios procesos hijos, y cada uno puede llegar a consumir hasta su memory_limit completo bajo carga. Si el plan anuncia 2 GiB de RAM y el pool de FPM permite diez procesos con un límite de 256M cada uno, el pico teórico son 2.560 MiB —2,5 GiB— antes de contar el proceso maestro, la base de datos y el propio sistema operativo, es decir, por encima de lo que el plan ofrece de verdad.

La cifra que evita el problema es pm.max_children multiplicada por el memory_limit de PHP, convertida a gibibytes y comparada con lo que el plan anuncia menos un margen razonable para MySQL y el propio Linux —entre 300 y 500 MiB en un servidor pequeño no es descabellado—. Ese cálculo, hecho una vez al configurar el servidor, evita el OOM killer matando procesos en el momento de más tráfico.

PHP puede consultar su propio consumo con memory_get_usage(), y el valor que devuelve está en bytes, no en la unidad del memory_limit. Convertirlo a MB decimales para compararlo con un panel de monitorización que reporta en GB —y ese panel casi siempre reporta gibibytes etiquetados como GB— es donde se cuela el error: un proceso que usa 200 MiB reales aparece como "0,2 GB" en un gráfico que en realidad está mezclando dos unidades sin decirlo.

La forma de no arrastrar el error es fijar una sola unidad de trabajo antes de comparar nada: convertir siempre a MiB —multiplicando GiB por 1.024— cuando la comparación es contra un límite de PHP, y dejar el megabyte decimal solo para las cifras que vienen ya así etiquetadas de fábrica, como el ancho de banda contratado.

Nada obliga a fijar memory_limit = 250M en vez de 256M, y funcionará igual. Pero 256 es una potencia de dos y divide de forma exacta la mayoría de los planes de hosting anunciados en GiB, mientras que 250 deja un resto en cada división y hace más difícil comprobar de cabeza cuántos procesos caben en el plan contratado.

La ventaja se nota sobre todo al revisar la configuración meses después: un administrador que ve 256M, 512M o 1024M en una lista de límites sabe de un vistazo que son fracciones limpias de un gibibyte, mientras que una cifra como 300M obliga a sacar la calculadora cada vez que hay que comprobar si el total sigue cabiendo en el plan.