Cuánta RAM necesita un servidor de Minecraft según jugadores y mods

Par Benjamin D. · PDG

12 de septiembre de 2026 · Mis à jour le 12 de septiembre de 2026 · Lecture 10 min

Índice

La RAM servidor Minecraft es el parámetro que más se sobreestima y peor se mide: mucha gente asigna 16 GB a una partida de diez amigos y sigue sufriendo tirones. La memoria no genera TPS por sí sola. Lo que importa es cuántos chunks se mantienen cargados, cuántas entidades se procesan y cómo gestiona el recolector de basura de Java ese espacio.

Qué consume realmente la RAM servidor Minecraft

Antes de calcular nada conviene entender dónde se va la memoria. En un motor Java, el heap se llena con objetos vivos: chunks cargados, entidades (mobs, ítems en el suelo, minecarts), inventarios, datos de bloques con NBT (cofres, hornos, shulkers), jugadores conectados y todo lo que los mods o plugins mantengan en caché.

Los tres grandes consumidores

Chunks cargados: cada jugador arrastra un radio de chunks alrededor suyo. Con view-distance=10 son 21 × 21 = 441 chunks por jugador, y si dos jugadores están lejos entre sí no se solapan. Un chunk cargado con su terreno, entidades y block entities ocupa del orden de decenas de kilobytes, y ese número se multiplica muy rápido.
Entidades y block entities: granjas de mobs, ítems acumulados, aldeanos, cofres dobles con hoppers. Son objetos vivos permanentes que el recolector de basura tiene que recorrer en cada ciclo.
Mods y plugins: cada mod carga clases, registros de bloques/ítems, recetas y estructuras. Un modpack grande puede ocupar 3-4 GB solo en registros antes de que entre el primer jugador.

Si administras una comunidad y quieres que la infraestructura acompañe al cálculo de memoria, la base es una CPU Ryzen de alta frecuencia y almacenamiento NVMe, porque Minecraft depende sobre todo del rendimiento monohilo y del acceso rápido a la región del mundo. Puedes ver las características técnicas en la página de alojamiento servidor Minecraft y contrastarlas con lo que te pide tu configuración real.

Heap no es igual a memoria total

Un error clásico: asignar -Xmx igual al límite total de la máquina o del contenedor. La JVM necesita memoria fuera del heap: Metaspace, buffers directos (red, compresión de chunks), pilas de hilos, el propio proceso. Regla práctica:

Fija -Xmx entre el 80 % y el 85 % de la memoria asignada a la instancia. El 15-20 % restante es para el proceso Java fuera del heap y para el sistema.

Si asignas el 100 %, tarde o temprano verás el proceso terminado por falta de memoria, con el típico corte seco en la consola del panel sin mensaje de crash en los logs del juego.

Cómo calcular la memoria según jugadores, mods y distancia de visión

No existe una fórmula universal, pero sí una aproximación que funciona en producción. Parte de una base y suma capas.

Fórmula de partida

RAM_heap = base_motor + (jugadores × factor_jugador) + extra_mods

base_motor      : 1,0 GB  (Paper/Purpur vanilla)
                  1,5 GB  (Spigot/Bukkit con 20-30 plugins)
                  3,0 GB  (Forge/NeoForge/Fabric con modpack mediano)
                  5,0 GB  (modpack pesado tipo ATM / GTNH)

factor_jugador  : 0,10 GB  con view-distance 6-8
                  0,15 GB  con view-distance 10
                  0,25 GB  con view-distance 12-16

extra_mods      : +0,5 GB por cada dimensión personalizada muy usada
                  +1 GB si hay generación de mundo modificada activa

Ejemplo real: 20 jugadores en Paper 1.21 con 25 plugins y view-distance=10 → 1,5 + (20 × 0,15) = 4,5 GB de heap. Con el margen fuera del heap, la instancia debería tener unos 5,5-6 GB. Asignar 12 GB a ese mismo escenario no mejora los TPS; solo alarga las pausas del recolector cuando por fin se llena.

Tabla de referencia rápida

Escenario	Jugadores	view-distance	Heap (-Xmx)	Memoria de la instancia
Vanilla / Paper entre amigos	2-8	8	2 GB	2,5 GB
Survival público con plugins	15-30	8-10	4-6 GB	6-8 GB
Red con minijuegos (una instancia)	30-60	6	6-8 GB	8-10 GB
Modpack mediano (80-150 mods)	5-10	8	6 GB	8 GB
Modpack pesado (250+ mods)	5-15	6-8	8-10 GB	12 GB
Modpack expert (GTNH y similares)	5-10	6	10-12 GB	14-16 GB

La distancia de visión es la palanca más rentable de ajustar

Pasar de view-distance=10 a view-distance=6 reduce los chunks cargados por jugador de 441 a 169: un 62 % menos de trabajo de memoria y de tick. En un survival con 40 jugadores la diferencia es brutal, y visualmente casi nadie lo nota porque desde 1.18 el cliente puede renderizar más lejos que lo que el servidor envía en simulación.

Desde 1.18 conviene separar los dos valores en server.properties:

view-distance=8
simulation-distance=5
max-players=40
entity-broadcast-range-percentage=75
sync-chunk-writes=false

simulation-distance controla dónde tiquean mobs, cultivos y redstone; view-distance solo controla lo que se envía visualmente. Bajar simulación a 4-5 libera CPU y memoria sin que el mundo parezca vacío.

Por qué más memoria a veces empeora las cosas

El recolector G1 recorre los objetos vivos del heap. Cuanto mayor es el heap, más largo puede ser un ciclo completo, y una pausa de 400 ms equivale a 8 ticks perdidos, es decir, un lag visible. Por eso un heap de 8 GB bien ajustado suele dar un tick más estable que uno de 16 GB sin flags. Salvo modpacks muy pesados, superar 12 GB rara vez aporta algo.

Ajustar la JVM y los archivos de configuración

Flags de arranque

Las flags de Aikar siguen siendo la referencia para G1GC en Minecraft. En el panel Pterodactyl se colocan en el campo de argumentos de arranque, o bien directamente en el script si trabajas por SSH sobre tu propia máquina:

java -Xms6G -Xmx6G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
  -jar server.jar nogui

Dos detalles que marcan la diferencia:

-Xms igual a -Xmx: evita que la JVM redimensione el heap constantemente. Con AlwaysPreTouch, la memoria se reserva en el arranque; la instancia mostrará uso alto desde el minuto cero y eso es normal.
Con heaps por encima de 12 GB, algunos administradores prefieren ZGC o Shenandoah para acortar pausas. Consulta la documentación de referencia sobre flags en la documentación de PaperMC antes de tocarlo.

Recortar entidades antes que añadir memoria

En Paper, el archivo config/paper-world-defaults.yml permite ganar más que un aumento de RAM:

entities:
  spawning:
    despawn-ranges:
      monster:
        hard: 96
        soft: 28
    per-player-mob-spawns: true
  behavior:
    disable-chest-cat-detection: true

chunks:
  max-auto-save-chunks-per-tick: 8
  prevent-moving-into-unloaded-chunks: true

collisions:
  max-entity-collisions: 2

Y en spigot.yml, los rangos de activación de entidades:

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      misc: 8
    merge-radius:
      item: 4.0
      exp: 6.0
    mob-spawn-range: 4

Fusionar ítems en el suelo y reducir el rango de activación baja el número de objetos vivos, y con ello la presión sobre el recolector. Es la vía directa para que el mismo heap rinda más.

Modpacks: dónde se dispara la memoria

En Forge o NeoForge el consumo base no depende de los jugadores sino del número de registros. Puntos a vigilar:

Mods de generación de mundo (biomas personalizados) que mantienen caché de ruido.
Dimensiones adicionales: cada una carga su propio conjunto de chunks y spawns activos.
Mods de almacenamiento masivo (drawers, redes de ítems) que crean miles de block entities con NBT.
Chunk loaders: un claim que mantiene 200 chunks cargados de forma permanente equivale a media docena de jugadores fantasma.

Antes de subir la memoria, revisa cuántos chunks se están forzando. Con el comando de consola del panel:

forge tps
forgemod list
/spark tps
/spark heapsummary

Diagnosticar problemas de memoria desde el panel

Distinguir falta de RAM de falta de CPU

Los síntomas se confunden, pero se separan fácil:

Síntoma	Causa probable	Acción
Tirones cada 30-60 s, gráfica de memoria en dientes de sierra que llega al techo	Heap insuficiente o fuga de un plugin	Perfilar con spark, revisar mods, subir heap si procede
MSPT alto y constante, memoria estable al 50 %	Carga de CPU (entidades, redstone, hoppers)	Ajustar activation range y simulation-distance
Proceso terminado sin crash report	`-Xmx` demasiado cerca del límite de la instancia	Bajar `-Xmx` al 80-85 %
Lag solo al explorar zonas nuevas	Generación de chunks y escritura en disco	Pregenerar el mundo, verificar NVMe

Pregenerar el mundo

Pregenerar evita picos de memoria y de CPU cuando alguien viaja lejos. Con Chunky, desde la consola:

chunky world world
chunky center 0 0
chunky radius 5000
chunky start

Hazlo con el servidor vacío y vigilando el uso de memoria. Después, una copia de seguridad antes de volver a abrir.

Medir en lugar de suponer

Instala spark y ejecuta /spark profiler start --timeout 300 durante una hora punta. El informe te dirá qué está ocupando ticks y qué objetos dominan el heap. Con esos datos, la decisión de subir o bajar la memoria deja de ser una corazonada.

Si gestionas varias instancias bajo Pterodactyl, recuerda que el límite de memoria del contenedor es un techo duro: el swap desactivado y un -Xmx mal ajustado provocan cierres inmediatos. Revisa también los registros de arranque tras cada actualización de Java o del motor. Encontrarás más guías técnicas sobre optimización y administración en el Blog de Fly-Serv, y la lista completa de juegos compatibles en Todos nuestros servidores de juegos.

Copias de seguridad y memoria

Una copia de seguridad en caliente lee el mundo entero y puede provocar un pico de I/O y de memoria si coincide con la hora punta. Programa las copias automáticas de madrugada, y antes de cambiar -Xmx o añadir mods, lanza una manual. Si algo se rompe, restaurar cuesta dos minutos desde el panel.

Resumen operativo

Calcula el heap con la fórmula: base del motor + jugadores × factor de distancia de visión + extra de mods.
Deja un 15-20 % de margen entre -Xmx y la memoria de la instancia.
Usa -Xms = -Xmx con flags G1 afinadas.
Baja simulation-distance antes de subir memoria.
Recorta entidades con spigot.yml y paper-world-defaults.yml.
Perfila con spark antes de cualquier cambio, y pregenera el mundo.

Una última nota sobre versiones: Java 21 es el requisito a partir de 1.20.5, y su recolector gestiona mejor heaps medianos que Java 8 o 11. Comprueba la versión activa en la consola con el comando de arranque; migrar una instancia antigua suele dar un margen de estabilidad gratuito en términos de pausas de GC. Puedes verificar los requisitos en la web oficial del juego.

Conclusión

La memoria no arregla un tick saturado: solo evita que la JVM se ahogue. Calcula el heap con datos reales, ajusta la distancia de simulación, recorta entidades y mide con spark antes de tocar nada. Con esa disciplina, la mayoría de comunidades funcionan de forma estable con bastante menos memoria de la que creían necesitar, y con partidas mucho más fluidas.

FAQ

¿Cuánta memoria necesito para 10 jugadores en Paper con plugins?

Con 20-30 plugins y view-distance=8, unos 3 GB de heap son suficientes: 1,5 GB de base + 10 × 0,15 GB. Reserva una instancia de 4 GB para dejar margen fuera del heap. Si usas WorldEdit, mapas dinámicos o protecciones con muchas regiones, sube a 4 GB de heap.

¿Por qué el uso de memoria está siempre al 90 % aunque no haya nadie conectado?

Es el comportamiento normal de la JVM con -Xms = -Xmx y AlwaysPreTouch: reserva el heap completo en el arranque. Lo que debes vigilar no es el porcentaje mostrado, sino la gráfica de dientes de sierra y las pausas de GC. Usa /spark heapsummary para ver la ocupación real.

¿Es mejor bajar la distancia de visión o añadir RAM en un modpack pesado?

Primero baja view-distance y simulation-distance a 6 y 4-5. Reduce chunks cargados, entidades activas y presión de GC a la vez. Añade memoria solo si, tras ese ajuste, el perfilado sigue mostrando ciclos de recolección frecuentes con el heap cerca del techo.