java.lang.OutOfMemoryError: Java heap space significa que el servidor ha pedido más memoria de la que tiene disponible y se ha detenido. Hay dos causas: un plan demasiado pequeño para lo que hace el servidor o una fuga de memoria en un complemento. Para distinguirlas, mira la forma del gráfico Memoria en la pestaña Consola.
#Lo que necesitas
- Acceso a las pestañas Consola y Registros en el panel de manage.mchost.gg.
#Paso 1: Lee el gráfico de memoria
Debajo de la consola encontrarás el gráfico Uso de recursos con la sección Memoria.
| Forma del gráfico | Diagnóstico |
|---|---|
| Diente de sierra: sube, baja tras la recolección de basura y vuelve a subir | Funcionamiento normal |
| Nivel constante en el límite, línea plana | Plan demasiado pequeño para la carga |
| Subida lineal hasta el fallo, sin bajadas | Fuga de memoria en un complemento |
| Pico en un momento concreto | Un evento: pregeneración, carga de una estructura grande, granja de mobs |
Una fuga de memoria se reconoce porque el servidor funciona bien tras reiniciarlo y se cae solo tras unas horas, siempre a una hora parecida. Un plan demasiado pequeño se nota de inmediato bajo carga.
#Paso 2: Reduce el consumo de memoria
Orden de mayor a menor beneficio:
- Elimina los complementos que no usas. Cada plugin y mod ocupa memoria aunque nadie lo utilice.
- Reduce las distancias. En la pestaña Configuración → Red y rendimiento, establece la Distancia de visualización en 6–8 y la Distancia de simulación en 4–6. Es el cambio más sencillo y con mayor impacto.
- Limita el número de jugadores. El panel avisa: «Un número elevado de jugadores puede afectar al rendimiento».
- Limita el mundo. El Tamaño máximo del mundo reduce el número de chunks que el servidor puede generar y mantener en memoria.
- Desactiva los complementos pesados. Dynmap, BlueMap y los plugins con mucha caché pueden consumir cientos de megabytes.
#Paso 3: Encuentra el origen de la fuga
Instala el plugin Spark y ejecuta el análisis de memoria:
spark heapsummaryEl informe muestra qué clases ocupan más memoria; el nombre del paquete indica el complemento. Para perfilar la carga:
spark profiler --timeout 300Un parche temporal es reiniciar automáticamente una vez al día, pero eso solo trata el síntoma: el culpable hay que encontrarlo.
#Paso 4: Comprueba si el plan es suficiente
Necesidad orientativa:
| Tipo de servidor | Mínimo razonable de RAM |
|---|---|
| Vanilla / Paper, hasta 10 jugadores | 2 GB |
| Paper con unos pocos plugins, 10–30 jugadores | 4 GB |
| Servidor completo con economía y mapa online | 6–8 GB |
| Modpack ligero (hasta 100 mods) | 6 GB |
| Modpack grande (más de 200 mods) | 8–12 GB |
La necesidad de memoria crece con el número de mods, no con el número de jugadores. Un modpack con 300 mods consume más memoria con un solo jugador que un Paper limpio con treinta.
Si tras reducir las distancias y eliminar los complementos innecesarios el gráfico Memoria sigue pegado al límite, necesitas un plan con más memoria.
#Problemas frecuentes
#El servidor se cae todos los días a una hora parecida
Es una fuga de memoria. Ejecuta spark heapsummary justo antes de la caída prevista: así verás qué ha crecido.
#OutOfMemoryError durante la pregeneración del mundo
La pregeneración es la operación que más memoria consume. Ejecútala con el servidor vacío y en lotes más pequeños.
#La memoria está llena, pero no hay nadie en el servidor
Los chunks cargados no se liberan de inmediato. Si el nivel no baja tras varios minutos sin jugadores, es una fuga.
#El servidor no se cae, pero va muy lento
Es un problema distinto: consulta Lag y optimización.
#El registro no contiene OutOfMemoryError, pero el servidor se apaga
Descarga latest.log completo con el botón Descargar. Si el proceso se ha matado de forma abrupta, la última entrada puede ser una línea cortada.