Cómo mejorar los TPS de un servidor de Minecraft sin perder contenido

Un TPS servidor Minecraft sano se mantiene clavado en 20 ticks por segundo, y cuando baja de 18 la causa casi siempre está en entidades acumuladas, en la carga de chunks o en un view-distance demasiado generoso. La solución no es añadir RAM a ciegas: es medir qué consume tiempo dentro del tick y recortar exactamente ahí.

Cómo medir el TPS servidor Minecraft y localizar el cuello de botella

El TPS (ticks per second) es el pulso del mundo. Cada tick, el motor procesa movimiento de entidades, redstone, crecimiento de cultivos, IA de mobs y guardado de chunks. Si todo eso cabe en 50 ms, el TPS se queda en 20. Si no cabe, el tick se alarga y el mundo se ralentiza.

La primera comprobación se hace en consola. En Paper y derivados, el comando devuelve tres medias, a 1, 5 y 15 minutos:

/tps
/mspt

Interpretación rápida: MSPT por debajo de 40 ms es cómodo, entre 40 y 50 ms estás al límite, por encima de 50 ms ya hay pérdida de TPS. Un TPS de 20 con MSPT de 47 ms significa que cualquier evento nuevo (una granja que arranca, diez jugadores que entran) te tumba el rendimiento.

Si administras una comunidad y quieres delegar la parte de infraestructura para centrarte en la configuración y los plugins, un hosting Minecraft con CPU de alta frecuencia y NVMe elimina de la ecuación dos de los cuellos de botella más habituales: el tick lento por CPU compartida y el guardado de chunks bloqueando el hilo principal.

Perfilar antes de tocar nada

Bajar view-distance sin saber si el problema está en las entidades es perder tiempo. Instala spark y saca un perfil de 3 a 5 minutos mientras el servidor está poblado:

/spark profiler start --timeout 300
/spark profiler stop
/spark tps
/spark healthreport

El informe web te da el árbol de llamadas ordenado por tiempo. Ahí verás si el gasto está en ServerLevel.tickChunk (chunks y spawns), en EntityTickList (entidades), en un plugin concreto o en pausas del recolector de basura. La documentación de configuración de Paper detalla cada parámetro que vas a modificar después.

Causas habituales de las caídas de rendimiento

Las bajadas de ticks se repiten mucho entre servidores. Este cuadro cubre la mayoría de los casos que aparecen en un perfil:

Síntoma	Causa probable	Dónde actuar
MSPT alto y constante, sin picos	Demasiadas entidades activas o view-distance elevado	spigot.yml, server.properties
Picos periódicos cada pocos minutos	Autoguardado o guardado de chunks en bloque	bukkit.yml, paper-world-defaults.yml
Tirones al explorar el mundo	Generación de chunks nuevos en tiempo real	Pregeneración del mundo, worldborder
Caída brusca al entrar jugadores	Envío masivo de chunks y CPU al límite	Frecuencia de CPU, distancias de vista
Congelaciones de 1 a 3 segundos	Pausas del recolector de basura	Banderas de la JVM, tamaño del heap
Lag localizado en una zona	Granja de mobs, relojes de redstone, hoppers en cadena	Reglas de construcción, límites de tick

Entidades: el sospechoso número uno

Cada item en el suelo, cada mob, cada marco y cada barca ocupa tiempo de tick. Una granja de hierro mal diseñada o cien cofres con hoppers pueden costar más que veinte jugadores conectados. Localiza los focos con:

/spark entities
/minecraft:kill @e[type=item,distance=..64]

Mods, plugins y eventos mal escritos

Un plugin que consulta la base de datos dentro de un evento de movimiento, o que escanea bloques en cada tick, hunde el rendimiento sin importar el hardware. El perfil te da el nombre exacto de la clase. Desactiva el sospechoso, mide de nuevo y decide: quitar, actualizar o buscar un reemplazo con la misma función.

Almacenamiento y hardware

Minecraft depende sobre todo del rendimiento en un solo hilo, así que la frecuencia por núcleo pesa más que el número de núcleos. Un Ryzen 9 7950X3D con RAM DDR5 ECC y SSD NVMe reduce el tiempo de guardado de regiones y las pausas de acceso a disco, dos partidas que aparecen a menudo en los perfiles de servidores con mundos grandes.

Ajustes del motor y banderas de la JVM

Antes de retocar el mundo, asegura la base: versión de Java, tamaño del heap y recolector. Java 21 con Paper reciente es el punto de partida razonable para versiones modernas del juego.

Heap fijo y G1GC afinado

Asigna -Xms y -Xmx con el mismo valor para evitar que la JVM redimensione el heap en caliente. Un servidor vanilla con pocos jugadores funciona con 4 GB; uno modado con 60 mods suele pedir 8 GB o más. Pasar de 12 GB rara vez ayuda y alarga las pausas del recolector.

java -Xms8G -Xmx8G \
  -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 paper.jar nogui

Parámetros de red y guardado

Tres líneas de server.properties tienen efecto directo en el tick y se suelen olvidar:

sync-chunk-writes=false
network-compression-threshold=256
max-tick-time=-1

sync-chunk-writes=false mueve el guardado fuera del hilo principal, algo que se nota especialmente sobre NVMe. Subir el umbral de compresión reduce el gasto de CPU en paquetes pequeños. Desactivar el watchdog con -1 evita cierres automáticos durante un pico puntual, aunque conviene mantenerlo activo mientras depuras.

View-distance y simulation-distance: el ajuste de mayor impacto

Estos dos valores multiplican el trabajo por jugador. view-distance controla los chunks que se envían al cliente; simulation-distance controla los chunks donde el servidor simula mobs, cultivos y redstone. El segundo es el que realmente consume tick.

view-distance=8
simulation-distance=5

Con 10 de vista, cada jugador mantiene 441 chunks. Con 8, son 289. Con 6, 169. La bajada de carga no es lineal, es cuadrática, y por eso es el cambio que más TPS devuelve en menos tiempo. Para supervivencia con jugadores dispersos, 6 u 8 de vista y 4 o 5 de simulación funcionan bien.

Distancias por mundo

En Paper puedes afinar por mundo desde paper-world-defaults.yml o desde la carpeta de cada mundo. Un lobby o un mundo de minijuegos no necesita la misma distancia que el mundo principal:

# config/paper-world-defaults.yml
chunks:
  max-auto-save-chunks-per-tick: 8
  prevent-moving-into-unloaded-chunks: true
  delay-chunk-unloads-by: 10s
misc:
  chunk-tasks-per-tick: 500

Baja simulation-distance antes que view-distance: los jugadores notan mucho menos la diferencia y el ahorro de tick es mayor.

No-tick view distance

Paper permite mostrar terreno más lejano sin simularlo, con no-tick-view-distance (o el equivalente según versión). Así mantienes un horizonte visual amplio y una simulación corta. Es la combinación que suelen usar los servidores de construcción, donde la vista importa y la IA de mobs casi no.

Carga de chunks y control de entidades

Un mundo que crece sin límite arrastra el rendimiento hacia abajo. La generación de chunks nuevos es una de las operaciones más caras del juego, y ocurre justo cuando los jugadores exploran a caballo, en barca o con elytra.

Pregenerar y poner frontera

Pregenera el mundo con Chunky y fija un worldborder acorde. Después, explorar deja de generar terreno y solo carga desde disco, algo trivial sobre NVMe:

/chunky world world
/chunky radius 5000
/chunky start
/worldborder set 10000

Límites de spawn y rangos de actividad

Los límites de aparición de bukkit.yml y los rangos de activación de spigot.yml son el freno principal para la población de mobs. Valores de partida razonables para un servidor de supervivencia con varias decenas de jugadores:

# bukkit.yml
spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1
ticks-per:
  animal-spawns: 400
  monster-spawns: 4
  autosave: 6000

# spigot.yml
world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
    merge-radius:
      item: 3.5
      exp: 4.0
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8
    max-entity-collisions: 2

El agrupado de items (merge-radius) reduce miles de entidades a unos cientos en granjas activas. Bajar max-entity-collisions alivia los rebaños comprimidos en corrales, un clásico en servidores con granjas de animales.

Reglas de juego que ayudan

• /gamerule mobGriefing false reduce cálculos de bloques por parte de mobs.
• /gamerule randomTickSpeed 3 mantiene el valor por defecto; subirlo dispara la carga de bloques aleatorios.
• Límites por jugador de entidades y de hoppers mediante plugins de gestión de terrenos.
• Prohibir relojes de redstone permanentes en la normativa del servidor, con avisos automáticos.

Rutina de comprobación tras cada cambio

Cambiar diez parámetros a la vez impide saber qué funcionó. El método que da resultados es aburrido y efectivo: un cambio, reinicio, medición con el servidor poblado, anotación del MSPT medio.

1. Guarda una copia de la configuración antes de editar. Las copias automáticas del panel te cubren si algo se rompe.
2. Aplica un solo ajuste desde el gestor de archivos o el editor de configuración.
3. Reinicia y deja pasar 15 minutos con jugadores conectados.
4. Ejecuta /spark tps y compara el MSPT con la medición anterior.
5. Si no hay mejora medible, revierte y pasa al siguiente candidato del perfil.

Añade un reinicio programado diario en horas de baja actividad. Libera memoria fragmentada, descarga chunks huérfanos y limpia entidades acumuladas. En NexusPanel se configura como tarea programada, junto a la copia automática, y se supervisa desde la consola en vivo.

Si gestionas varias comunidades a la vez, la misma metodología sirve para otros títulos con tick fijo: puedes ver todos nuestros servidores de juegos para identificar qué juegos comparten este tipo de límites de simulación. Hay más guías técnicas de administración en el Blog de Nexus Games.

Conclusión

Empieza siempre por el perfil con spark: sin datos, cualquier ajuste es superstición. Después ataca en este orden: simulation-distance, entidades y merge-radius, pregeneración del mundo y, por último, banderas de la JVM. El error más caro es asignar 16 GB de RAM a un mundo que sufre por 30.000 items en el suelo y una CPU compartida. Un tick corto vale más que un heap enorme.

FAQ

¿Los TPS bajos y el ping alto son el mismo problema?

No. El ping mide el tiempo de ida y vuelta entre el cliente y la máquina, y depende de la red y de la distancia geográfica. Los TPS miden cuánto tarda el motor en procesar cada tick del mundo. Puedes tener 15 ms de ping y 12 TPS, o 150 ms de ping y 20 TPS clavados. Los síntomas se parecen (golpes que no registran, bloques que reaparecen), pero se diagnostican y se corrigen por separado.

¿Cuánta RAM debo asignar para que no bajen los TPS?

Lo justo para el mundo y los mods que ejecutas, ni más ni menos. Vanilla con pocos jugadores funciona con 4 GB; un pack modado grande suele necesitar 8 GB o más; los modpacks muy pesados llegan a 12 GB. Asignar mucho más de lo necesario alarga las pausas del recolector de basura y produce congelaciones de uno o dos segundos. Deja siempre memoria libre para el sistema y no asignes todo el total disponible.

¿Reiniciar el servidor cada pocas horas mejora el rendimiento?

Ayuda como medida de mantenimiento, no como solución. Un reinicio programado libera memoria fragmentada, descarga chunks que quedaron cargados y elimina entidades acumuladas, así que el TPS vuelve a su valor sano durante un tiempo. Si necesitas reiniciar cada dos horas para mantener 20 TPS, tienes una fuga real: un plugin que no libera recursos, una granja abusiva o un heap mal dimensionado. Un reinicio diario en horas de baja actividad es suficiente en un servidor bien ajustado.