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

El TPS de un servidor Minecraft mide cuántos ticks completa el motor cada segundo: 20 es el techo y cada tick dispone de 50 ms para resolver mobs, bloques, redstone y jugadores. Cuando baja de 19 la simulación se arrastra, los golpes fallan y las tolvas se atascan. Medir el MSPT, localizar la tarea que se pasa de tiempo y corregirla es todo el trabajo.

Qué mide la simulación por ticks y cuándo empieza el problema

El motor de Minecraft ejecuta el mundo en un bucle de 20 iteraciones por segundo. Si una iteración tarda más de 50 ms, el resto se retrasa y la cuenta de ticks efectivos cae. El valor que importa realmente no es el TPS, sino el MSPT: milisegundos consumidos por tick.

Un mundo sano se mueve entre 20 y 35 ms de MSPT. Entre 35 y 50 ms el margen desaparece y cualquier pico (una explosión, un chunk nuevo, un guardado) hunde la cifra. Por encima de 50 ms el TPS ya no puede mantenerse en 20, por definición matemática.

MSPT medio	TPS resultante	Qué nota el jugador
menos de 35 ms	20,0	Nada, simulación estable
35 a 50 ms	20,0 con picos	Micro tirones puntuales
50 a 70 ms	14 a 19	Mobs a saltos, retardo al minar
más de 100 ms	menos de 10	Rubber banding, tolvas paradas

El bucle principal es monohilo. Da igual cuántos núcleos tenga la máquina: la simulación del mundo se resuelve en un solo hilo, y lo que manda es la frecuencia por núcleo. Un Ryzen 9 7950X3D con DDR5 ECC y NVMe da margen ahí donde un núcleo compartido y lento no lo dará jamás.

Si el déficit está en la máquina, ningún archivo de configuración lo compensará del todo; conviene revisar antes la ficha de hosting Minecraft y confirmar qué recursos tiene reservados la instancia.

Cómo diagnosticar el TPS servidor Minecraft sin adivinar

Cambiar valores al azar en la configuración es la vía rápida para romper el gameplay sin ganar un solo tick. El diagnóstico empieza siempre con un perfilador que diga qué consume el tiempo del tick.

Comandos de lectura inmediata

/tps
/mspt
/spark tps
/spark health --memory
/paper mobcaps
/paper entity list

/tps devuelve la media a 1, 5 y 15 minutos. /mspt, exclusivo de Paper, muestra los percentiles de duración del tick: si la media es baja pero el percentil 99 se dispara, el problema son picos puntuales (guardado, generación de chunks, explosiones) y no una carga constante.

Perfilar con spark

spark viene integrado en las compilaciones recientes de Paper y es la herramienta que devuelve un árbol de llamadas con el porcentaje real de cada plugin y cada sistema del motor.

/spark profiler start --timeout 300 --thread "Server thread"
/spark profiler stop
/spark entities
/spark heapsummary

Lanza el perfilador en horario de máxima ocupación, nunca con el mundo vacío. Cinco minutos bastan. El informe generado se lee en el navegador y ordena el gasto por método, así que un plugin que consume el 30 % del hilo principal salta a la vista sin margen de duda. La documentación oficial de Paper (fuente) detalla cada clave citada más abajo.

Correlacionar con los registros

Desde la consola live del NexusPanel, revisa el log mientras cae el TPS. Mensajes como Can't keep up! Did the system time change? confirman ticks perdidos; Saving chunks for level repetido cada pocos segundos apunta al autoguardado; los avisos del watchdog señalan un bloqueo del hilo principal, casi siempre por un plugin que hace consultas SQL síncronas.

Causas habituales de una simulación lenta

Chunks cargados de más

Cada chunk cargado se tickea. Con view-distance a 10 y veinte jugadores repartidos por el mapa, el motor mantiene miles de chunks activos. Los chunk loaders permanentes, los portales del Nether mal colocados y las granjas en el fin del mundo multiplican esa cifra sin que nadie esté cerca.

Entidades y mobs

Los ítems tirados por el suelo, los mobs de granja apilados y los aldeanos son los tres grandes consumidores. Un solo chunk con 300 entidades ya arrastra el tick completo. La pathfinding de aldeanos y piglins es especialmente cara.

Redstone y tolvas

Un reloj de redstone olvidado en una base ejecuta actualizaciones de bloque cientos de veces por segundo. Las cadenas de tolvas comprueban su inventario en cada tick aunque estén vacías, y una granja industrial con 200 tolvas encadenadas cuesta más que todos los jugadores conectados juntos.

Síntoma	Sospechoso principal	Comprobación
Caída constante todo el día	Entidades o chunks cargados	/spark entities
Picos cada 5 minutos	Autoguardado o tarea de plugin	/mspt y log
Caída al explorar	Generación de chunks	Pregenerar el mundo
Caída en una zona concreta	Redstone o tolvas	Perfilar con jugadores allí
Congelación de varios segundos	Pausa de GC o E/S de disco	/spark health --memory

Ajustes de configuración que devuelven ticks completos

server.properties

view-distance=8
simulation-distance=6
sync-chunk-writes=false
network-compression-threshold=256
max-tick-time=60000

Separar view-distance de simulation-distance es la palanca más rentable: los jugadores siguen viendo lejos, pero el motor solo simula mobs y bloques en un radio corto. Bajar la simulación de 10 a 6 recorta el trabajo por tick de forma drástica y apenas se percibe en juego.

spigot.yml

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
    mob-spawn-range: 6
    nerf-spawner-mobs: true
    merge-radius:
      item: 3.5
      exp: 4.0
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8

entity-activation-range congela las entidades fuera de rango en lugar de tickearlas. nerf-spawner-mobs desactiva la IA de los mobs nacidos en generadores: siguen sirviendo para granjas de experiencia y drops, pero dejan de calcular rutas. Subir ticks-per.hopper-check a 8 divide por ocho el trabajo de las tolvas.

bukkit.yml

spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 2
  ambient: 1
ticks-per:
  monster-spawns: 4
  autosave: 6000

paper-world-defaults.yml

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

ALTERNATE_CURRENT sustituye el algoritmo vanilla de propagación de redstone por uno que evita las actualizaciones redundantes; en mundos con mucha maquinaria el ahorro es inmediato y el comportamiento sigue siendo compatible. disable-move-event corta un evento que muchos plugins escuchan sin necesidad en cada movimiento de ítem.

Pregenerar el mapa

Generar terreno nuevo es la operación más cara del motor. Pregenerar el radio jugable con Chunky elimina esos picos de una vez, y combinarlo con un world border evita que alguien vuelva a arrastrar la simulación explorando a 20 000 bloques del spawn.

/chunky world world
/chunky center 0 0
/chunky radius 4000
/chunky start

Plugins, datapacks y tareas programadas: aislar al responsable

Un plugin mal configurado supera con facilidad el gasto de cien jugadores. Los patrones que más ticks queman son las consultas a base de datos en el hilo principal, los escaneos periódicos de todos los bloques del mundo, los sistemas de protección que recalculan regiones en cada evento y los anticheat con comprobaciones síncronas.

• Ordena el informe de spark por porcentaje del hilo principal y ataca solo los tres primeros.
• Sube el intervalo de las tareas repetitivas (guardado de datos, contadores, hologramas) de 1 tick a 20 o 100.
• Desactiva módulos que no usas dentro de cada plugin, no solo el plugin entero.
• Sustituye los limpiadores agresivos de entidades por límites de spawn bien ajustados: borrar ítems cada minuto rompe granjas y no arregla la causa.
• Prueba con arranques sucesivos si el perfilador no es concluyente: mitad de plugins fuera, se mide, se repite.

Los datapacks con funciones ejecutadas en tick.mcfunction merecen el mismo escrutinio. Un bucle que recorre @e[type=item] cada tick en un mundo poblado cuesta más que cualquier plugin. Encontrarás más recursos de administración en el Blog de Nexus Games, y el mismo método de perfilado sirve en Todos nuestros servidores de juegos con motor por ticks.

Memoria, Java y arranque: afinar la JVM

Una pausa larga del recolector de basura se ve como una congelación total, no como una bajada progresiva. Asignar demasiada memoria es tan dañino como asignar poca: cuanto más grande es el heap, más larga es la pausa cuando toca limpiar.

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

Fija -Xms y -Xmx al mismo valor para que la JVM no redimensione el heap en caliente. Un mundo vanilla con veinte jugadores funciona holgado con 4 a 6 Go; un modpack pesado pide 8 Go o más. Reservar 16 Go a un survival ligero solo alarga las pausas.

Usa siempre la versión de Java exigida por la build del juego, y actualiza el motor: cada versión de Paper trae correcciones de rendimiento en carga de chunks y seguimiento de entidades. Sobre almacenamiento, el guardado incremental sobre NVMe evita los bloqueos de E/S que se notan con discos mecánicos.

Regla práctica: mide, cambia un parámetro, vuelve a medir. Tocar diez claves a la vez impide saber cuál funcionó y cuál rompió una granja.

Conclusión

Empieza por /mspt y un perfilado de cinco minutos con jugadores dentro: sin ese dato, cualquier ajuste es lotería. Después baja simulation-distance, recorta las entidades activas y pregenera el mapa; en la mayoría de mundos esos tres cambios recuperan los 20 ticks. El error que más tiempo cuesta es instalar un limpiador automático de entidades para tapar un plugin que consume el hilo principal: el síntoma desaparece, la causa sigue ahí.

FAQ

¿El TPS bajo y el ping alto son lo mismo?

No. El TPS mide la velocidad de simulación del mundo en la máquina, mientras que el ping mide el tiempo de ida y vuelta de los paquetes por la red. Con 20 TPS estables y 200 ms de latencia notarás retardo al pegar, pero los mobs se moverán con fluidez. Con 8 TPS y 15 ms de ping todo el mundo irá a saltos, incluso en local. Diagnostícalos por separado: /tps para lo primero, la barra de conexión o /ping para lo segundo.

¿Reiniciar automáticamente cada pocas horas ayuda a mantener el TPS?

Ayuda como parche, no como solución. Un reinicio programado libera memoria fragmentada, descarga chunks huérfanos y reinicia tareas de plugins que acumulan objetos, así que el TPS sube durante un rato. Si la caída reaparece a la hora, tienes una fuga real que hay que localizar con un perfilado de memoria. Un ciclo de seis a doce horas, avisado en el chat y con guardado previo, es una práctica razonable de mantenimiento; cada treinta minutos es señal de que algo está mal configurado.

¿Cuánta memoria necesita un mundo con mods para no perder ticks?

Depende del número de mods y de jugadores. Un modpack ligero de 60 mods con diez jugadores suele funcionar con 6 Go asignados a la JVM; un pack industrial de 250 mods pide 8 a 12 Go, y los packs con generación de terreno personalizada pueden necesitar más durante la exploración. Asigna siempre menos de la memoria física total para dejar margen al sistema, y comprueba con /spark health --memory si el heap se llena o si simplemente sobra sitio sin usar.