TPS en un servidor de Minecraft: cómo medirlo y recuperar 20 ticks estables

El TPS de un servidor Minecraft indica cuántos ticks logra completar el mundo en un segundo, y el valor sano es 20. Por debajo de 19 ya aparecen mobs que patinan, tolvas lentas y golpes que llegan tarde. Medirlo con /tps y perfilarlo con spark permite identificar la causa exacta en pocos minutos y devolver el servidor a su ritmo normal.

Qué es el TPS y por qué 20 es el techo

El servidor divide el tiempo en ticks de 50 milisegundos. En cada tick mueve entidades, calcula redstone, procesa crecimiento de cultivos, guarda chunks y ejecuta las tareas de los plugins. Si todo ese trabajo cabe en 50 ms, el resultado son 20 ticks por segundo constantes. Si un tick necesita 70 ms, el reloj se retrasa y el TPS cae.

De ahí que el dato realmente accionable sea el MSPT (milisegundos por tick). El TPS solo empieza a bajar cuando el MSPT supera 50, así que un servidor a 20 TPS con 46 ms de MSPT ya está al borde del colapso. Vigilar el MSPT anticipa el problema antes de que los jugadores lo noten.

Conviene separar dos síntomas que se confunden. El lag de servidor (TPS bajo) afecta a todos por igual: los bloques tardan en romperse y el tiempo del mundo avanza despacio. El lag de red (ping alto) afecta solo a algunos jugadores, con teletransportes hacia atrás y bloques fantasma, mientras el TPS sigue en 20.

Cómo medir el TPS servidor Minecraft con /tps y spark

El bucle principal del juego se ejecuta en un solo hilo, así que la frecuencia por núcleo pesa más que el número de núcleos. Una máquina con Ryzen 9 7950X3D, RAM DDR5 ECC y almacenamiento NVMe absorbe más trabajo por tick que un núcleo compartido de baja frecuencia. Puedes consultar las características técnicas en la página de hosting Minecraft.

Los comandos integrados

En Paper, Purpur y derivados tienes dos comandos inmediatos desde la consola del panel o desde el chat con permisos de operador:

/tps
/mspt

/tps devuelve tres medias: último minuto, cinco minutos y quince minutos. /mspt muestra la media y el percentil 95 en ventanas de 5, 10 y 60 segundos. El percentil 95 es el que delata los picos: si la media es 25 ms pero el P95 llega a 90 ms, hay una tarea puntual que rompe el tick cada pocos segundos.

Perfilar con spark

spark es el perfilador estándar desde que Paper retiró Timings. Se instala como plugin (o como mod en Fabric y Forge) y genera un informe web navegable. La secuencia útil es esta, ejecutada en hora punta y nunca con el servidor vacío:

/spark tps
/spark health --memory
/spark profiler start --timeout 300
/spark profiler stop
/spark heapsummary

El perfilado de 300 segundos basta para capturar el comportamiento real de un servidor con jugadores conectados. La documentación oficial de spark detalla los modificadores adicionales, como el muestreo por hilo o el volcado de memoria.

Interpretar el informe sin perderse en la pila de llamadas

El informe se abre en el navegador con el árbol de llamadas ordenado por porcentaje de tiempo. Ignora las ramas de menos del 3 %: el ruido de fondo no sirve de nada. Baja por la rama más gruesa hasta encontrar un nombre reconocible, y ahí está el culpable.

Rama detectada	Significado	Primera acción
ServerLevel.tickNonPassenger	Demasiadas entidades activas	Reducir rangos de activación y límites de spawn
ChunkMap / ChunkHolder	Carga y generación de chunks	Bajar view y simulation distance, pregenerar el mundo
HopperBlockEntity.tickHopper	Redes de tolvas masivas	Ajustar hopper-transfer y desactivar el evento de movimiento
Nombre de un plugin en la pila	Tarea síncrona pesada	Revisar su configuración o sustituirlo
Level.tickBlockEntities con redstone	Relojes y circuitos permanentes	Cambiar la implementación de redstone y localizar el circuito

La vista health aporta el segundo bloque de información: uso de CPU del proceso, pausas del recolector de basura y ocupación de memoria. Pausas de GC largas y repetidas producen microcortes que el TPS medio a 15 minutos disimula, pero que los jugadores sienten como tirones cada pocos segundos.

Las causas más frecuentes de las caídas

Chunks cargados y generación al vuelo

Cada jugador que explora obliga al servidor a generar terreno nuevo, la operación más costosa del juego. Con view-distance a 12 y varios exploradores simultáneos, el MSPT se dispara sin que ninguna entidad tenga la culpa. Los chunk loaders artificiales, los portales del Nether y los aldeanos con puestos de trabajo mantienen zonas activas incluso sin jugadores cerca.

Entidades acumuladas

Ítems tirados sin recoger, cofres de minecarts, barcos abandonados y granjas de mobs sin cámara de matanza suman miles de entidades que se procesan tick tras tick. Un solo chunk con 300 objetos ya penaliza. Las granjas de aldeanos y las de hierro son casos clásicos: funcionan bien aisladas y hunden el servidor cuando hay diez repartidas por el mapa.

Redstone y tolvas

Un reloj de redstone actualiza bloques veinte veces por segundo, siempre, aunque su dueño esté desconectado. Las cadenas de tolvas hacen lo mismo: cada tolva verifica el inventario superior de forma constante. Una granja industrial con doscientas tolvas cuesta más que cincuenta jugadores conectados.

Plugins mal configurados

El problema rara vez es el número de plugins, sino cómo trabajan. Los que guardan datos en disco de forma síncrona, los que ejecutan tareas cada tick o los que consultan una base de datos remota dentro del hilo principal bloquean el servidor entero. Un plugin de protección de terreno con miles de regiones sin indexar produce el mismo efecto.

Ajustes concretos para recuperar 20 TPS estables

Cambia un bloque de parámetros cada vez y vuelve a medir tras un reinicio. Tocar cinco archivos a la vez impide saber qué funcionó.

server.properties

view-distance=8
simulation-distance=5
network-compression-threshold=256
entity-broadcast-range-percentage=80
sync-chunk-writes=false

La distancia de simulación es la que decide cuántos chunks reciben ticks completos. Bajarla de 10 a 5 reduce de forma drástica el trabajo por tick sin que los jugadores pierdan visión, porque view-distance sigue controlando lo que se ve a lo lejos.

bukkit.yml

spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1
ticks-per:
  monster-spawns: 4
  autosave: 6000
chunk-gc:
  period-in-ticks: 400

spigot.yml

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
    merge-radius:
      exp: 4.0
      item: 3.5
    mob-spawn-range: 6
    hopper-transfer: 8
    hopper-check: 8
    max-entity-collisions: 2

El rango de activación es el ajuste con más impacto sobre las entidades: fuera de ese radio, los mobs quedan en reposo y dejan de calcular rutas. La fusión de ítems y experiencia recorta el recuento de entidades en granjas y zonas de combate.

paper-world-defaults.yml

chunks:
  autosave-interval: 6000
  max-auto-save-chunks-per-tick: 8
entities:
  spawning:
    per-player-mob-spawns: true
    despawn-ranges:
      monster:
        hard: 96
        soft: 32
hopper:
  disable-move-event: true
misc:
  redstone-implementation: ALTERNATE_CURRENT

La implementación alternativa de redstone reduce mucho el trabajo de los circuitos grandes sin alterar su comportamiento. Desactivar el evento de movimiento de tolvas quita carga siempre que ningún plugin dependa de él, así que verifica antes qué plugins escuchan ese evento.

Pregenerar el terreno

Generar el mundo por adelantado elimina la causa número uno de picos. Con el plugin Chunky, desde la consola:

/chunky world world
/chunky center 0 0
/chunky radius 3000
/chunky start

Combínalo con un límite de mundo (/worldborder set 6000) para que nadie salga de la zona ya generada. Encontrarás más rutinas de administración en el Blog de Nexus Games.

Java, memoria y arranque del proceso

Las versiones 1.20.5 y posteriores requieren Java 21. Ejecutar el servidor con una versión antigua provoca pausas de GC innecesarias y, en algunos casos, errores de arranque. Verifica la versión activa antes de investigar nada más:

java -version

Asignar más memoria de la necesaria empeora el rendimiento: el recolector de basura tiene que recorrer un heap mayor y las pausas se alargan. Un mundo vanilla con veinte jugadores funciona con 4 GB; un modpack pesado pide entre 8 y 12 GB. Iguala siempre -Xms y -Xmx.

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:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 -XX:SurvivorRatio=32 \
-XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
-jar paper.jar nogui

Estos parámetros de G1GC son los que usa la mayoría de administradores en producción y reducen las pausas largas. Desde el NexusPanel puedes editar la línea de arranque, revisar la consola en vivo y programar reinicios; el resto de juegos con requisitos parecidos aparece en Todos nuestros servidores de juegos.

Conclusión

No toques ningún archivo antes de perfilar. La secuencia correcta es medir con /mspt, lanzar spark cinco minutos en hora punta, leer la rama más gruesa y actuar solo sobre esa causa. El error más caro es subir la RAM esperando recuperar ticks: el bucle del juego es monohilo y la memoria extra no lo acelera. Si tras los ajustes el MSPT sigue alto, busca la granja o el circuito concreto que aparece en el informe.

FAQ

¿Por qué el TPS marca 20 pero los jugadores siguen notando tirones?

Porque el TPS es una media y esconde los picos aislados. Ejecuta /mspt y observa el percentil 95: si supera 50 ms mientras la media se mantiene baja, hay una tarea puntual (autoguardado, evento de un plugin, generación de chunks) que rompe ticks concretos. También puede tratarse de latencia de red o de FPS bajos en el cliente, que nada tienen que ver con el rendimiento del mundo.

¿Cada cuánto conviene reiniciar el servidor para mantener el rendimiento?

Un reinicio programado cada doce o veinticuatro horas es suficiente en la mayoría de casos. Libera memoria fragmentada, descarga chunks huérfanos y reinicia tareas de plugins que acumulan objetos. Si necesitas reiniciar cada dos horas para que el TPS aguante, no es una rutina de mantenimiento sino un síntoma de fuga de memoria: perfila el heap con /spark heapsummary e identifica el plugin responsable antes de disimular el problema.

¿Sirven los plugins que eliminan entidades automáticamente?

Sirven como parche temporal, no como solución. Borrar ítems del suelo cada cinco minutos recorta el recuento de entidades, pero frustra a los jugadores que pierden material y no corrige la granja o el circuito que genera la carga. Es preferible ajustar los rangos de activación, los límites de spawn y la fusión de ítems, y usar el borrado automático solo para objetos antiguos con un aviso previo en el chat.