Optimizar un servidor de Minecraft en 2026: 20 TPS estables y MSPT bajo

[!TIP] Resumen rápido (TL;DR): Un servidor de Minecraft estable tiene que mantener 20,0 TPS (Ticks Per Second) y un MSPT < 50 ms (Milliseconds Per Tick). Si el MSPT supera los 50 ms, el servidor pierde ticks y empiezan a notarse los retrasos. Para conseguir la máxima fluidez, aplica lo siguiente: motor Paper o Purpur, Aikar's Flags (Java 21 G1GC), pregeneración del mapa con el plugin Chunky y ajuste de las distancias de simulación en server.properties y paper-world-defaults.yml.

El lag en un servidor de Minecraft es la pesadilla tanto de los jugadores como de los administradores. Enemigos que se teletransportan, bloques que tardan en romperse o granjas de animales que se atascan pueden arruinar hasta el modo de juego más interesante. Con las actualizaciones modernas (de la 1.20 a la 1.21+), los mundos se han vuelto más profundos (de Y: -64 a Y: 320) y exigen bastante más cálculo.

En esta guía te acompañamos por todo el proceso profesional de optimización de un servidor de Minecraft en 2026: desde la configuración de la máquina virtual de Java, pasando por los archivos de configuración del motor, hasta la pregeneración y el diagnóstico de hilos.

1. Entender las métricas de rendimiento: TPS vs MSPT

Antes de tocar ningún archivo, conviene entender cómo se mide el rendimiento del servidor:

• TPS (Ticks Per Second): Número de ciclos de cálculo que el servidor ejecuta en un segundo. El valor ideal es 20,0 TPS. Por debajo de 18,0 empieza el lag, y por debajo de 15,0 jugar se vuelve una tortura.
• MSPT (Milliseconds Per Tick): Tiempo que necesita el procesador para calcular un tick del juego. El servidor dispone de exactamente 50 milisegundos (50 ms) para hacer todos los cálculos de un tick (1000 ms / 20 ticks = 50 ms).
  • MSPT < 30 ms: El servidor tiene un gran margen de potencia y va perfectamente fluido.
  • MSPT 30–48 ms: El juego va fluido (20 TPS), pero ante una carga repentina pueden aparecer microtirones.
  • MSPT > 50 ms: El servidor no llega a tiempo y los TPS bajan automáticamente de 20.

2. Flags de arranque de la JVM (Aikar's Flags para Java 21)

La forma en que la máquina virtual de Java (JVM) gestiona la memoria RAM y la recolección de basura (Garbage Collection) es fundamental. Unos parámetros inadecuados provocan las llamadas GC Pauses: congelaciones de todo el servidor que duran segundos mientras se limpian los objetos que ya no se usan.

Aplica el conjunto optimizado de Aikar's Flags adaptado a Java 21 y al recolector G1GC:

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1ReservePercent=20 \
-XX:G1HeapRegionSize=8M -XX:G1ReservePercent=15 -XX:G1HeapWastePercent=5 \
-XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
-Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar server.jar nogui

[!TIP] Memoria -Xms y -Xmx: Pon siempre la memoria RAM mínima (-Xms) y la máxima (-Xmx) con el mismo valor (por ejemplo, las dos en 6G u 8G). Así evitas que el sistema operativo asigne memoria de forma dinámica mientras se juega. ¡En MCHost.pl las Aikar's Flags vienen integradas por defecto en el panel de control!

3. Optimización de los archivos de configuración

Los archivos de configuración por defecto de Minecraft están pensados para ofrecer la máxima calidad visual a un solo jugador, no para el rendimiento de un servidor multijugador. Los ajustes siguientes pueden ahorrarte hasta un 40–60 % de la potencia de cálculo de la CPU.

A. Archivo server.properties

• view-distance=7 (Por defecto 10. Bajarlo a 6–8 reduce el radio de carga del terreno sin una pérdida visual apreciable).
• simulation-distance=4 (Por defecto 10. ¡Parámetro clave! Define la distancia en chunks a la que están activos los mobs, los hornos y las plantas. Un valor de 4 o 5 alivia drásticamente al procesador).
• network-compression-threshold=256 (Umbral óptimo de compresión de los paquetes de red).
• sync-chunk-writes=false (Fuerza la escritura asíncrona de chunks en disco).

B. Archivo spigot.yml

En la sección world-settings.default:

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 32
  misc: 8
  water: 12
  villagers: 16
  flying-monsters: 24
  tick-inactive-villagers: false
entity-tracking-range:
  players: 48
  animals: 32
  monsters: 32
  misc: 24
  other: 48
merge-radius:
  item: 4.0
  exp: 6.0

Estos parámetros desactivan los cálculos avanzados de inteligencia artificial de los mobs cuando el jugador está fuera del radio de bloques indicado.

C. Archivo config/paper-world-defaults.yml

Paper ofrece las opciones de optimización más profundas:

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

entities:
  spawning:
    despawn-ranges:
      monster:
        soft: 28
        hard: 56
  behavior:
    despawn-shulker-bullets: true
    should-remove-dragon: true

redstone-implementation: ALTERNATE_CURRENT

hopper:
  cooldown-when-full: true
  disable-move-event: true

• ALTERNATE_CURRENT: Activa un algoritmo de Redstone muy optimizado que reduce la carga del procesador con relojes y mecanismos enormes hasta en un 80 %.
• Despawn-ranges: Reduce el radio en el que los mobs desaparecen al instante, evitando que las cuevas se llenen.

D. Archivos purpur.yml / pufferfish.yml (si usas Purpur)

Si has elegido el motor Purpur (echa un vistazo a nuestra comparativa de motores de servidor), activa optimizaciones multihilo adicionales:

• dab.enabled: true (Dynamic Activation of Brain: pone a dormir la IA de los mobs que no están haciendo nada importante).
• async-mob-spawning: true (Comprobación asíncrona de las condiciones de aparición de monstruos).

4. Pregeneración del mapa con el plugin Chunky

Generar terreno nuevo sobre la marcha (cuando un jugador vuela con élitros o navega en barco) es la causa más habitual de las caídas bruscas de TPS a valores de un solo dígito. Generar el complejo terreno de la 1.21, con sus cuevas y biomas, requiere una potencia de cálculo enorme.

La solución es pregenerar el mapa antes de abrir el servidor con el plugin gratuito Chunky:

# 1. Elige el mundo que vas a generar
/chunky world world

# 2. Define la forma circular del borde
/chunky shape circle

# 3. Define el radio de pregeneración (p. ej., 3000 bloques desde el centro)
/chunky radius 3000

# 4. Lanza la tarea de pregeneración
/chunky start

Cuando termine la pregeneración, establece el borde oficial del mundo para que los jugadores no salgan de la zona preparada:

/worldborder set 6000

5. Diagnóstico y caza de culpables: el profiler spark

Cuando el servidor pierde fluidez a pesar de los cambios, no adivines la causa. Instala el plugin de diagnóstico spark (lo encontrarás en nuestra lista de los mejores plugins para servidores).

¿Cómo hacer un análisis de rendimiento?

1. Escribe el comando de profiling justo cuando aparezca el lag:

   /spark profiler --timeout 60
   

2. A los 60 segundos aparecerá en el chat un enlace a un informe web detallado.
3. En el informe, haz clic en la pestaña Thread Dump -> Server Thread. El árbol de procesos te indicará exactamente qué método, plugin, mecanismo de Redstone o coordenadas del mundo (world: x, y, z) consumen más tiempo de procesador.

Comandos útiles de spark:

• /spark healthreport - resumen rápido de TPS, MSPT, uso de memoria RAM y carga de CPU.
• /spark tps - resumen detallado de los valores medios de ticks de los últimos 1, 5 y 15 minutos.
• /spark gc - historial de trabajo del recolector de basura.

Tabla de parámetros clave de optimización

FAQ - Preguntas frecuentes

¿Por qué mi servidor va a 20 TPS y los jugadores siguen notando retrasos?

Si el servidor mantiene 20,0 TPS constantes, el problema no es el rendimiento del procesador, sino la latencia de red (ping) o un tiempo de respuesta alto del cliente. Asegúrate de que el servidor esté en Europa Central (Polonia/Alemania) y de que la conexión del jugador sea estable.

¿Optimizar rompe los mecanismos de Redstone y las granjas de los jugadores?

Usar el algoritmo ALTERNATE_CURRENT no rompe el 99 % de los mecanismos estándar, puertas de pistones y granjas. Eso sí, al reducir simulation-distance, las granjas dejan de funcionar cuando el jugador se aleja más de 4–5 chunks, algo totalmente intencionado para ahorrar recursos.

¿Hacen falta plugins que limpien los objetos del suelo (p. ej., ClearLag)?

En 2026 usar plugins del tipo ClearLag no se recomienda. Borrar objetos de forma agresiva molesta a los jugadores, y los motores modernos Paper/Purpur ya se las apañan de maravilla fusionando los objetos del suelo (merge-radius) sin necesidad de instalar scripts de limpieza externos.

¿Dónde encuentro la documentación oficial sobre optimización?

Encontrarás descripciones detalladas de todas las flags y parámetros del motor en la documentación de PaperMC y en Minecraft Wiki - Server Optimization.

Conclusión

Optimizar un servidor de Minecraft es un proceso de eliminar cuellos de botella:

1. Usa un motor moderno (Paper o Purpur).
2. Configura la memoria con las Aikar's Flags (G1GC).
3. Limita la distancia de simulación a 4–5 chunks.
4. Haz una pregeneración completa del mundo con el plugin Chunky.
5. Diagnostica las anomalías con el profiler spark.

¿Buscas un hardware que mantenga los 20 TPS sin esfuerzo incluso con partidas intensas? Echa un vistazo a la oferta de servidores NVMe de MCHost.pl con procesadores de hasta 5,0 GHz.