¿Cuánta RAM necesita un servidor de Minecraft?

Qué determina realmente cuánta RAM necesitas

Dos palancas deciden cuánta memoria quiere un servidor de Minecraft. Todo lo demás es ruido a su lado.

• El número de jugadores añade RAM de forma gradual. Cada jugador conectado carga los chunks a su alrededor, así que más jugadores —y un view-distance más alto— implican tener más mundo en memoria a la vez. Pasar de 4 jugadores a 20 es un aumento real, pero manejable.
• Los mods y plugins son la palanca grande, con diferencia. Vanilla consume poco. Un puñado de plugins de Paper añade algo. Un modpack es una categoría completamente distinta: cada mod carga en memoria su propio código, objetos, bloques y generación de mundo antes de que entre un solo jugador, y por eso un pack de CurseForge con 200 mods puede necesitar varias veces la RAM de un servidor vanilla con el mismo número de jugadores.

Ese es todo el modelo: vanilla escala con los jugadores, modded escala con los mods. El tamaño y la antigüedad de un mundo también empujan la cifra hacia arriba —un mapa enorme y con años de vida, con muchos chunks cargados, cuesta más que uno recién creado—, pero los jugadores y los mods son lo que marca el dimensionamiento. Mantén una cosa en mente mientras sigues leyendo: la RAM es solo uno de los recursos del servidor y, pasado cierto punto, deja de ser el que importa (más sobre esto en por qué más RAM no siempre es la solución).

Cuánta RAM necesita un servidor de Minecraft, según la configuración

Este es el dimensionamiento sobre el que construimos los planes: las mismas cifras que le daríamos a un amigo. La «RAM objetivo» es lo que hay que asignar al servidor en sí, no el total de tu PC, que necesita margen adicional por encima (consulta cómo asignarla).

¿Tienes un modpack y no sabes en qué banda encajas? Tanto el tamaño del pack como el número de jugadores te empujan hacia arriba en la tabla; la guía de servidores de Minecraft con mods desglosa los loaders y los tamaños de pack en detalle.

Cómo darle esa RAM a tu servidor

Conocer la cifra es la mitad del trabajo; la otra mitad es entregarle realmente esa memoria al servidor. Funciona de forma distinta según dónde se ejecute el servidor.

Autoalojado: los parámetros -Xmx y -Xms

Cuando eres tú quien lanza el jar del servidor, dos parámetros controlan su memoria. -Xmx fija el heap máximo (el techo) y -Xms fija el heap inicial. Para Minecraft, el consejo habitual y bien probado es ponerlos iguales, de modo que la JVM reserve toda su memoria de entrada en lugar de redimensionarla bajo carga:

java -Xms4G -Xmx4G -jar server.jar nogui

Esa línea arranca un servidor con 4 GB. Algunas cosas que suelen despistar:

• Usa Java de 64 bits. Java de 32 bits no puede direccionar más de 1,5 GB aproximadamente, así que si -Xmx4G se niega a arrancar, esa suele ser la razón. Cualquier compilación actual de Temurin o de Java 25 es de 64 bits.
• Nunca le des al servidor toda tu RAM. Deja al menos 1-2 GB para el sistema operativo, y más si además ejecutas el cliente de Minecraft en el mismo PC: el juego necesita su propia memoria aparte de la del servidor.
• Después, ajústalo con los flags de Aikar. Una vez que lo básico funciona, los conocidos «flags de Aikar» (estándar de la comunidad) reajustan el recolector de basura G1 de Java al patrón de memoria de Minecraft, sacrificando una pizca de RAM a cambio de ticks notablemente más estables. Son el siguiente paso estándar después de un simple -Xmx/-Xms. El tutorial completo de autoalojamiento —jar, EULA, apertura de puertos y demás— está en Cómo crear un servidor de Minecraft.

Gestionado: elige un tamaño y amplía sobre la marcha

En un servidor gestionado no hay parámetros que editar. Eliges la RAM con un deslizador al hacer el pedido y el plan se aprovisiona con ese tamaño; los parámetros de arranque (incluidos los de Aikar) ya vienen ajustados por ti.

La verdadera ventaja aparece cuando se te queda corta tu primera estimación: en la página de hosting de Minecraft subes el deslizador y la RAM extra se aplica al mismo servidor, con el mundo y la configuración intactos, sin reinstalar, sin migrar, en cosa de un minuto. Justo por eso la regla general de arriba es «empieza pequeño»: en un plan gestionado, añadir RAM más tarde no cuesta más que un minuto.

Señales de que tu servidor necesita más RAM

No tienes que adivinar si tu servidor está falto de recursos. Él mismo te lo dice, de varias formas reconocibles:

• Los ticks se retrasan. La consola muestra Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), y dentro del juego eso se traduce en rubber-banding, mobs que se congelan y bloques que tardan un instante en romperse.
• Guardar el mundo da tirones. Un breve parón cada pocos minutos, coincidiendo con el autoguardado, suele significar que el servidor pelea por memoria.
• Se cierra directamente. La señal más clara de todas es un cierre cuyo registro contiene java.lang.OutOfMemoryError: Java heap space: el servidor pidió más memoria de la que permitía su techo -Xmx.

Para ver cuál de los dos es, el perfilador gratuito spark (ejecuta /spark health o /spark profiler) muestra los tiempos de tick y el uso de memoria, y un panel gestionado dibuja la RAM en vivo en una gráfica. Si la memoria se queda clavada cerca del techo, amplía. Si la memoria tiene margen pero los ticks siguen yendo lentos, lee antes la siguiente sección.

Por qué más RAM no siempre es la solución

Esta es la parte que la mayoría de los consejos de dimensionamiento se dejan fuera. Minecraft ejecuta el bucle principal del juego —el «tick» que mueve a los mobs, hace crecer los cultivos y procesa la redstone— en gran parte en un único hilo de CPU. La memoria guarda el mundo; un solo núcleo hace el trabajo de pensar. Una vez que el servidor tiene suficiente RAM para albergarlo todo, añadir más no hace que ese núcleo vaya más rápido.

Merece la pena interiorizar dos consecuencias:

• Si los ticks van lentos mientras la RAM tiene margen, el cuello de botella es la CPU, no la memoria. Meterle 32 GB a un servidor atascado en un solo núcleo no cambia nada. Este es, con diferencia, el error de dimensionamiento más habitual que comete la gente.
• Demasiada RAM incluso puede perjudicar. Un heap muy grande le da al recolector de basura de Java más que barrer de golpe, lo que puede convertirse en pausas y tirones más largos: una razón más para que se cumpla la regla de «empezar más pequeño».

Lo que de verdad marca la diferencia cuando el límite es la CPU es una alta velocidad de reloj. Por eso HytHost ejecuta Minecraft en CPUs Ryzen e Intel i9 de alta frecuencia en lugar de muchos núcleos lentos: a Minecraft le importa lo rápido que sea un núcleo, no cuántos haya. En la parte del software puedes aligerar la carga de ese núcleo bajando view-distance y simulation-distance, pregenerando los chunks de tu mundo, usando Paper en lugar de vanilla o añadiendo mods de rendimiento como Lithium en una configuración con mods. La RAM hace que tu mundo se cargue; la CPU y tus decisiones de software determinan lo fluido que va.