¿Cuánta RAM necesita un servidor de Minecraft?

Estás abriendo un servidor para amigos en un PC con 8 GB de RAM. Escribir -Xmx8G en el archivo de inicio es fácil: que RAM use 8 y Java también 8. Luego recuerdas Windows, el navegador y, si vas a jugar en el mismo PC, el cliente de Minecraft. Antes de que nadie haya iniciado sesión, la memoria del sistema ya no encuentra dónde compartir. A veces el problema no está en el servidor, sino en esa única línea.

Mira por separado los resultados “Java heap recomendado” y “RAM total necesaria” en la calculadora. El primero lo usas para -Xmx. El segundo dice cuánta RAM debe haber en el PC o en el servidor que alquilas. Yo no doy la respuesta “8 GB alcanza” sin separar esos dos. El número de jugadores por sí solo no sostiene esa respuesta.

Diez jugadores no siempre son la misma carga

Reunirse en el spawn frente a repartirse por el mapa

Escribe el número de personas que entrarán al juego al mismo tiempo, no las cuentas registradas. 10 personas construyendo una base alrededor del spawn miran los mismos chunks. Cuando se dispersan en cuatro direcciones con elytra, la cosa cambia. El servidor, por un lado, carga nuevas zonas; por otro, genera terreno que nadie ha visto todavía. Los 10 del inicio de la noche y los 10 del final no dejan la misma carga de RAM.

Al calcular, miro cómo juega el grupo. Si todos se quedan en una zona común, la opción “Mayormente en la misma zona” es adecuada. Si en el mundo survival cada uno se reparte a su propia base, “En zonas diferentes / no lo sé” se acerca más. Si la exploración también es intensa, márcala aparte. La calculadora añade un 25 % a la carga de chunks. Subir el número de jugadores a veinte porque sí, solo para parecer prudente, oculta de dónde viene la diferencia.

Controla también la distancia de visión y de simulación desde el archivo server.properties. La visión es el área que envías al jugador. La simulación es el entorno donde funcionan los mobs y los eventos del juego. Cuando el formulario se abre por primera vez, escribe 8 y 6 chunks. En el cálculo de versiones modernas, la distancia mayor de las dos es determinante. Con visión 8, si subes la simulación de 6 a 7, el resultado de RAM puede seguir igual. Para la carga de ticks no podemos decir lo mismo. En el perfil “1.17 y anteriores”, la herramienta no tiene en cuenta la distancia de simulación.

No leas el número de plugins por sí solo

Para Paper, Purpur y Spigot introduces el número de plugins y su carga media. En Fabric, Forge y NeoForge entra en juego el número de mods. En Vanilla, la calculadora no usa ninguna de esas entradas antiguas. No creas que las opciones “ligera / media / pesada” son el consumo de RAM medido de cada plugin. 10 pequeños plugins de permisos y un plugin que renderiza el mapa en segundo plano no se ponen en la misma balanza.

Al instalar un modpack, yo busco primero la recomendación de heap que el paquete da para el servidor. Si la encuentras, introdúcela en la parte “Usar la recomendación de RAM del modpack”. La herramienta no bajará de esa cifra. No traslades aquí la recomendación escrita para el cliente. Estamos hablando de dos procesos de juego distintos. Si no puedes estimar la carga del paquete, mira juntos el resultado “media” y “pesada”. La diferencia entre ambos sirve más que el número de mods para discutir si hace falta un paquete de hosting más grande.

¿Qué número escribir y dónde en la calculadora?

Si estás montando un servidor nuevo, elige “Calcular la necesidad de RAM”; si vas a probar el PC que tienes, elige “Comprobar mi computadora”. El cálculo del servidor es el mismo en ambos caminos. Lo que más fácilmente se pasa por alto son los valores iniciales del formulario: Paper y 10 plugins vienen listos. Si en tu instalación no hay ningún plugin, pon 10 en cero. Luego escribe la versión, la distancia de visión y, si hace falta, la distancia de simulación tal como están en tu servidor. Si tienes granjas intensivas, redstone, mapa web o un mundo adicional planeado, pasa a ajustes avanzados. Si no, no los marques solo porque aparezca la casilla.

El margen de trabajo al abrir por primera vez es del 25 %. En los ajustes avanzados puedes cambiarlo entre el 10 % y el 100 %. En el momento en que desactivas esos ajustes, sacas las cargas adicionales del cálculo y devuelves el margen al 25 %. Si en una prueba viste 6 GiB y en otra 9 GiB, mira primero qué interruptores están activados. Anota también junto al resultado las entradas que usaste. Así no tendrás que volver al principio cuando busques la diferencia.

8 GB equivalen a unos 7,45 GiB. Si el anuncio dice GB, introduce GB en el formulario. Si una máquina virtual o un contenedor solo puede usar una parte de la RAM física, escribe esa parte como límite. Es fácil tranquilizarse con “puse 8 y salió 8”. Si en los dos lados elegiste unidades diferentes, la comparación se desvía desde el principio. Sobre todo si el resultado está en el límite de medio GiB.

Los dos resultados de RAM en pantalla

No confundas el tamaño del heap con la capacidad de la máquina

El heap de Java es el límite superior que el servidor puede usar para los objetos Java. La RAM total también deja espacio para el sistema operativo y para la memoria que Java usa fuera del heap. La calculadora reserva al menos 1 GiB para ese uso adicional de Java. Si el 15 % del heap es mayor, toma eso, y luego redondea el resultado hacia arriba a medio GiB. Si en pantalla hay 3,5 GiB de heap, el -Xmx3584M que genera es eso mismo. Al elegir un paquete de hosting, no creas que la cifra de -Xmx es la RAM del paquete.

Prueba con esta configuración: Paper para 10 jugadores, versión moderna, visión 8 chunks, simulación 6 chunks, 10 plugins de carga media. Con los ajustes avanzados y Chunky desactivados, la herramienta da 3,5 GiB de heap y 6,5 GiB de RAM total. En una máquina de 8 GiB con Linux sin escritorio, si no reservas margen extra para otras aplicaciones, el cálculo de memoria cabe. Ahora piensa en Windows y en el cliente de Minecraft en el mismo PC. Si escribes 1 GiB para otras aplicaciones y 4 GiB para el cliente, el requisito total sube a 13,5 GiB. Una máquina de 8 GiB no alcanza aquí. Ni siquiera añadimos un plugin a Paper. Son las otras tareas las que se comen la RAM.

La comprobación del equipo pone un margen de sistema de 2 GiB para Linux sin escritorio, 3 GiB para Linux con escritorio y 4 GiB para Windows y macOS. En un contenedor no añade el margen del sistema operativo de la máquina anfitriona. Si dentro corren otros servicios, debes escribir su RAM en la sección “Otras aplicaciones”. Cuando la máquina no alcanza, la calculadora no reduce el heap automáticamente. Muestra claramente dónde falta.

De Vanilla a un modpack

Otra vez 10 jugadores y ajustes de 8/6 chunks. En Vanilla salen 3 GiB de heap y 6 GiB de RAM total. Si añades 10 plugins de carga media a Paper, 3,5 y 6,5 GiB. Un ejemplo de Fabric con 50 mods de carga media muestra 5 y 8 GiB; un ejemplo de Forge, 6 y 9 GiB. No interpreto estos resultados como “Fabric es más ligero que Forge en todas las condiciones”. Cuando cambian los mods dentro de los paquetes, la comparación también cambia. Los números solo muestran cómo se comporta la calculadora con las mismas entradas.

En el ejemplo de Paper, si los jugadores se quedan en la misma zona, ves 3 GiB de heap y 6 GiB de RAM total. Si se dispersan y exploran terreno nuevo, 4 y 7 GiB. En los dos escenarios el número de jugadores es 10. Por eso no me fío solo de la recomendación “tanta RAM por jugador”. Cuando añades granjas intensivas, mapa web, generación de mundos personalizada y dos mundos activos adicionales, el mismo cálculo llega a 6 GiB de heap y 9 GiB de RAM total. Aquí, en vez de activar los cuatro interruptores a la vez y mirar el resultado, pruébalos uno por uno. Así verás qué carga hace saltar el cálculo.

Cálculo de Chunky y medición del servidor en funcionamiento

En Chunky primero eliges el nombre del mundo, el centro, la forma y el radio. En un cuadrado, el área es 4 × radio²; en un círculo, π × radio². Como un chunk ocupa 16 × 16 bloques, la calculadora divide el área entre 256. Si el centro es 0, 0 y el radio del cuadrado es 3000 bloques, salen 140.625 chunks. Si la mitad ya está generada, quedan 70.313. Si pones el radio en 6000, 562.500 chunks. No porque añadas 3000 bloques el trabajo se duplica. El área llega a cuadruplicarse. Revisa una vez más el número en la casilla del radio.

Al activar Chunky, la recomendación de heap del servidor Paper de ejemplo sube a 4 GiB y su RAM total a 7 GiB. Para el disco y el tiempo puedes hacer una generación de prueba corta. Si introduces 10.000 chunks nuevos, 256 MiB de crecimiento de carpeta y 300 segundos, para los 140.625 chunks restantes verás aproximadamente 3,52 GiB de disco y 1,17 horas. Durante la generación del mundo, la velocidad puede no mantenerse constante. No incluyas en la medición las copias de seguridad ni los archivos del mapa web. Antes de enviar el comando, lee también el nombre del mundo y el radio. Un cero de más se refleja tanto en el tiempo como en el disco.

Abriste el servidor, los jugadores se dispersaron, bajó el TPS. No agrandes -Xmx de inmediato. TPS es el número de actualizaciones del juego por segundo, y MSPT, cuántos milisegundos tarda una actualización. Mira ambos con /spark tps. Si tomas un perfil de Spark en un momento de carga alta, puedes entender si el tiempo se va en la generación del mundo o en un plugin. Lee también la presión de recolección de basura en los datos de GC. En un servidor que se cierra con error OOM, el límite de RAM y -Xmx son lo primero que hay que mirar. Si el TPS baja con memoria libre, primero abro la salida del profiler. El nuevo paquete de RAM lo pienso después.