Servidor de Minecraft sin memoria: qué significa "Out of memory" y cómo arreglarlo

"Mi servidor se queda sin memoria" puede significar tres cosas distintas, y las tres se arreglan de forma diferente. Una es un error de Java en la consola. Otra es un servidor que simplemente muere sin decir nada. Y la tercera, la más común, es que el servidor va a tirones y alguien asume que es falta de RAM cuando no lo es. Esta guía te enseña a distinguirlas, con lo que dice la documentación de Java, de Paper y de Pterodactyl, y a encontrar al culpable antes de pagar un plan más grande.

Primero, cómo usa la memoria un servidor de Minecraft

El servidor corre dentro de la máquina virtual de Java. Al arrancar se le dice cuánta memoria puede usar para los objetos del juego (el heap) con los argumentos -Xms (inicial) y -Xmx (máxima). Pero el proceso de Java usa más memoria que el heap: metaspace para las clases, los hilos, los búferes de red… La documentación de Paper lo dice sin rodeos: que el proceso use más de lo que marca -Xmx es comportamiento normal, no una fuga.

Ese detalle es la clave de la mitad de los problemas: si tu plan tiene 8 GB y arrancas con -Xmx8G, el proceso va a necesitar más de 8 GB en total, y el contenedor lo va a matar.

Caso 1: "java.lang.OutOfMemoryError: Java heap space"

Según la guía oficial de Java, significa que no se pudo reservar un objeto en el heap porque el tamaño configurado es insuficiente para lo que la aplicación intenta hacer, y aclara que no implica necesariamente una fuga de memoria. Hay dos posibilidades:

• De verdad hace falta más heap: muchos jugadores explorando a la vez, view-distance alta, un modpack pesado con poco -Xmx. La solución es subir -Xmx (dentro de lo que permite el plan, ver caso 2) o subir de plan.
• Algo está acumulando objetos que nunca libera: un plugin o mod con fuga, chunks que no se descargan, entidades acumuladas. Aquí más RAM solo retrasa el error. Hay que encontrar al culpable (más abajo).

Caso 2: el servidor muere sin ningún error en la consola

El proceso desaparece, el panel lo marca como detenido y el último mensaje de la consola es cualquier cosa normal. La documentación de Paper describe exactamente este síntoma: "crash sin logs, a menudo un OOM kill". Lo que pasa es que el contenedor del servidor (Docker, en paneles como Pterodactyl) tiene un límite de memoria, y cuando el proceso lo supera, el sistema operativo lo mata sin darle tiempo a escribir nada.

Pterodactyl lo intenta amortiguar: Wings da al contenedor un margen por encima de la RAM del plan (un 5 % en planes grandes, 10 % por debajo de 4 GB y 15 % por debajo de 2 GB, según su código) precisamente para procesos como Java que se pasan un poco. Pero si pones -Xmx igual a la RAM del plan, ese margen no cubre el metaspace y los búferes, y el servidor cae en los picos.

La regla práctica, que coincide con la recomendación de Paper: deja entre 1000 y 1500 MB libres respecto al total. Con 8 GB de plan, -Xmx6500M es un valor seguro; con 4 GB, unos 3 GB de heap. En un panel, la RAM que ves en el servidor es el límite del contenedor; el -Xmx va en el comando de arranque, y nuestro generador de start lo calcula con ese margen.

Caso 3: "GC overhead limit exceeded"

La guía de Java lo define así: el recolector de basura está ocupando más del 98 % del tiempo y recuperando menos del 2 % del heap durante cinco ciclos seguidos. En lenguaje llano: el servidor pasa todo el tiempo intentando liberar memoria y no consigue nada, porque todo lo que hay en el heap sigue en uso. Es el mismo diagnóstico que el caso 1 (heap insuficiente o fuga), solo que Java se rinde antes de llegar al error de heap. Desactivar el límite con una flag solo esconde el mensaje; no arregla nada.

Caso 4: no es la memoria, es el lag

El servidor no se cae, pero va a tirones y en el panel la memoria parece "llena". Dos aclaraciones: Java usa todo el heap que le das antes de limpiar (es su forma de trabajar, no una señal de alarma), y los tirones periódicos suelen ser pausas del recolector de basura, que se controlan con las flags de arranque correctas (las de Aikar) y no con más gigas. Si sospechas que es rendimiento y no memoria, la guía de optimización y la página qué causa el lag van por ahí.

Cómo encontrar lo que consume la memoria

Paper trae Spark integrado (está activado por defecto en paper-global.yml). Dos comandos bastan:

1. /spark healthreport para ver el uso de memoria en el momento y cuánto se libera en cada ciclo del recolector.
2. /spark heapsummary para obtener un resumen del heap: qué tipos de objeto ocupan más. Si arriba del todo aparece una clase con el nombre de un plugin o un mod, ya tienes al sospechoso; si aparecen chunks o entidades, el problema es el mundo (view-distance, chunks que no se descargan, granjas).

Pega el enlace que te da Spark en nuestro analizador de Spark y te resume qué está pesando. Con un perfil de CPU (/spark profiler start --timeout 300) también verás si ese mismo plugin está tirando el TPS.

Culpables habituales, por frecuencia: plugins de mapas web mal configurados, plugins de "protección" que guardan todo en memoria, mods con cachés sin límite, hoppers y entidades sin control, y view-distance o simulation-distance demasiado altas para la cantidad de jugadores.

Cuánta RAM es "suficiente" (y por qué nadie da una cifra exacta)

No existe una tabla oficial de megabytes por jugador, y desconfía de quien te la venda. Lo que sí está documentado: la wiki de Minecraft considera que 2 GB bastan para unos cinco jugadores con la simulación a distancia por defecto, y Paper recomienda 6-10 GB como punto cómodo para la mayoría de servidores con plugins, y avisa de que a partir de cierto punto más memoria no mejora nada. Nuestra guía de cuánta RAM necesita tu servidor y la calculadora te dan un punto de partida por jugadores, plugins y mods.

Checklist cuando aparece el problema

1. ¿Hay error en consola o el servidor murió en silencio? Silencio = OOM kill del contenedor: baja -Xmx entre 1 y 2 GB por debajo del plan.
2. ¿-Xms y -Xmx son iguales y arrancas con las flags de Aikar? Si no, corrige el arranque antes de nada.
3. Saca un /spark heapsummary en el momento malo. ¿Encabeza un plugin o mod? Actualízalo, configúralo o quítalo.
4. ¿Encabezan chunks o entidades? Baja view-distance y simulation-distance, pregenera el mapa con Chunky y revisa granjas.
5. Si después de todo eso el heap sigue lleno con uso normal, entonces sí: sube de plan. Es el último paso, no el primero.

Si eres cliente, manda el enlace de Spark por Discord y lo miramos contigo; es más rápido que adivinar y, muchas veces, más barato que cambiar de plan.