TPS en un servidor de Minecraft: por qué cae y cómo recuperar los 20 ticks

El TPS servidor Minecraft mide cuántos ciclos de simulación completa el mundo cada segundo, y el techo es 20: por encima no se sube, por debajo el juego va literalmente a cámara lenta. Cuando cae, casi siempre hay una causa localizable (entidades acumuladas, chunks de más, redstone en bucle o una granja mal diseñada) y se corrige con ajustes concretos del motor.

¿Qué significa un tick y por qué 20 es el límite?

Un tick es un ciclo completo de lógica: movimiento de entidades, crecimiento de cultivos, propagación de redstone, IA de mobs, física de fluidos y guardado de chunks. El juego reserva 50 milisegundos para ejecutarlo todo. Si el trabajo cabe en esos 50 ms, el hilo principal duerme el resto y marcas 20 TPS clavados.

Cuando un tick necesita 70 ms, el motor no acelera: simplemente ejecuta menos ticks por segundo. Ahí aparece el síntoma clásico de que los mobs se mueven a saltos, las tolvas tardan una eternidad y romper un bloque tarda medio segundo en registrarse. El indicador real que debes vigilar es el MSPT (milisegundos por tick), porque avisa antes.

Un mundo puede estar a 20 TPS con 45 MSPT y aun así estar al borde del colapso: cualquier explosión, portal o carga de chunk nueva lo tumba. Trabaja siempre con margen, apuntando a MSPT por debajo de 35 en horas punta.

La otra mitad de la ecuación es el hardware. La simulación de Minecraft depende sobre todo del rendimiento de un solo núcleo, así que un hosting Minecraft con CPU de alta frecuencia como el Ryzen 9 7950X3D, RAM DDR5 ECC y discos NVMe evita que el cuello de botella sea la máquina en lugar de tu configuración.

Cómo medir el TPS servidor Minecraft sin adivinar

Antes de tocar un solo archivo, necesitas datos. Cambiar quince parámetros a ciegas suele empeorar la jugabilidad sin recuperar ni un tick. Estas son las herramientas útiles según la plataforma:

• Paper, Purpur y derivados: /tps y /mspt desde la consola o en juego.
• Spark (plugin y mod, disponible para Fabric, Forge y NeoForge): perfilador que dice qué método concreto consume el hilo principal.
• Forge / NeoForge: /forge tps muestra el tiempo de tick por dimensión.
• Vanilla: /debug start y /debug stop generan un informe en la carpeta debug/.

# Instalar spark y sacar un perfil de 5 minutos en carga real
/spark tps
/spark health
/spark profiler start --timeout 300
# al terminar, spark devuelve un enlace con el desglose por método

Lee el perfil de arriba abajo buscando el porcentaje del hilo principal. Si EntityLiving.tick se lleva el 40 %, tienes un problema de mobs. Si domina ChunkMap o ServerChunkCache, el problema son chunks. Si aparece un plugin por nombre, ya sabes a quién apuntar.

Registra también el número de entidades por dimensión antes y después de cada cambio. Sin ese antes y después no sabrás si el ajuste ha funcionado o si simplemente había menos gente conectada.

Causas habituales de las caídas de rendimiento

Entidades acumuladas

Es la causa número uno en mundos con más de unos meses de vida. Ítems tirados que nadie recoge, marcos de armadura de decoración, vagonetas olvidadas, barcos, aldeanos criados sin control y granjas de mobs sin sistema de matanza eficiente. Cada entidad viva pide IA, colisiones y búsqueda de camino en cada tick.

Los aldeanos merecen mención aparte: su lógica de trabajo, sus brain sensors y su pathfinding son de lo más caro del juego. Doscientos aldeanos apiñados en una granja de intercambio pueden costar más MSPT que todos los jugadores conectados juntos.

# Recuento rápido de entidades cargadas (Paper)
/paper entity list
# Limpieza puntual de ítems tirados en el mundo principal
/minecraft:kill @e[type=item]

Chunks cargados de más

Cada chunk cargado se guarda, se simula y se envía por red. Un view-distance de 12 con veinte jugadores dispersos multiplica el trabajo del hilo principal y del guardado en disco. Los cargadores de chunks por portal del Nether, las vagonetas en raíles largos y los jugadores explorando terreno virgen son los peores enemigos del tick.

La generación de terreno nuevo es especialmente costosa porque implica ruido, estructuras, cuevas y escritura de archivos. Un jugador volando con élitros a 60 bloques por segundo por zonas sin generar puede tirar el TPS él solo.

Redstone, tolvas y granjas

Los relojes de redstone permanentes, los observadores en bucle y las líneas largas de repetidores disparan actualizaciones en cascada. En vanilla, el algoritmo de redstone es recursivo y su coste crece de forma poco predecible con la longitud del circuito.

Las tolvas son otra fuente silenciosa: cada tolva comprueba el contenedor superior varias veces por segundo, incluso vacía. Cientos de tolvas en un sistema de clasificación equivalen a miles de comprobaciones por segundo que nadie ve pero que el servidor paga.

Plugins y mods mal comportados

Un plugin que consulta una base de datos en el hilo principal, guarda el mundo entero cada minuto o registra un evento en cada movimiento de jugador arruina cualquier optimización posterior. Los mods de generación de terreno, de dinámica de fluidos o de física realista tienen un coste estructural que no se ajusta con parámetros.

Síntoma	Sospechoso principal	Primera comprobación
Caída constante todo el día	Entidades o granjas	Recuento por chunk
Caída solo con jugadores explorando	Generación de chunks	Perfilar ChunkMap
Micro tirones cada pocos segundos	Pausas del recolector de basura	Flags de la JVM
Caída en una zona concreta	Redstone o tolvas	Visitar y desactivar
Caída tras añadir contenido	Plugin o mod nuevo	Arranque sin él

Ajustes del motor para volver a 20 ticks estables

server.properties

Separar la distancia de visión de la distancia de simulación es el ajuste con relación esfuerzo/resultado más alta. Los jugadores siguen viendo lejos, pero solo se simula lo cercano.

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

bukkit.yml y spigot.yml

Los límites de aparición y los rangos de activación de entidades reducen el número de mobs vivos y el radio en el que se les aplica IA completa. Bajarlos en exceso rompe las granjas, así que ajusta en pasos pequeños y comprueba el resultado en juego.

# bukkit.yml
spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1
ticks-per:
  monster-spawns: 2
  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
    mob-spawn-range: 6

paper-world-defaults.yml

Paper añade dos palancas decisivas: el algoritmo alternativo de redstone y la desactivación del evento de movimiento de tolvas, que por sí solo elimina la mayor parte del coste de los sistemas de clasificación. Consulta la documentación oficial de Paper antes de tocar valores que no reconozcas.

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

En Fabric, el equivalente es instalar Lithium para la lógica del servidor y, si el mundo es grande, herramientas de pregeneración. La ganancia en mundos con muchas entidades es directa y no altera mecánicas de juego.

Java, memoria y rutina de mantenimiento

Ajustar la máquina virtual

Las pausas del recolector de basura se ven como micro tirones periódicos con TPS que rebota entre 20 y 14. Asignar memoria fija (Xms igual a Xmx) y usar G1GC con parámetros afinados suaviza esas pausas. Dar 32 GB a un mundo que necesita 8 alarga cada ciclo de recolección en lugar de acortarlo.

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:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Usa la versión de Java que exige tu build: las versiones recientes del juego requieren Java 21, y arrancar con una runtime antigua provoca errores de arranque o rendimiento degradado. El panel de administración permite cambiarla sin tocar la línea de comandos.

Pregenerar y limitar el mundo

Definir un borde de mundo y pregenerar el terreno dentro de él elimina de golpe el pico de generación en vivo. Es la operación que más TPS recupera en comunidades que exploran mucho, y solo hay que hacerla una vez.

/worldborder set 8000
# con el plugin Chunky
/chunky radius 4000
/chunky start

Rutina semanal

• Revisar el recuento de entidades por dimensión y limpiar ítems huérfanos.
• Comprobar el MSPT en hora punta, no en horario vacío.
• Verificar que las copias de seguridad automáticas terminan sin solapar el guardado del mundo.
• Actualizar plugins y mods de uno en uno, midiendo después de cada uno.
• Programar un reinicio diario en horario de baja actividad para liberar memoria fragmentada.

Si tras todo esto el hilo principal sigue saturado con pocos jugadores, el límite es la frecuencia del procesador o la contención de recursos. Puedes revisar las fichas técnicas de Todos nuestros servidores de juegos para entender qué influye en la simulación, y encontrarás más guías de administración en el Blog de Nexus Games.

Conclusión

Empieza siempre por medir con spark antes de tocar configuración: el 80 % de las caídas se explican por entidades acumuladas o por chunks simulados de más, y ambas se corrigen en diez minutos bajando simulation-distance, ajustando spawn-limits y limpiando granjas antiguas. El error más caro es subir la memoria asignada esperando ganar ticks: la simulación depende de un núcleo rápido, no de gigabytes libres.

FAQ

¿El TPS bajo es lo mismo que tener ping alto?

No. El ping mide el tiempo de ida y vuelta entre el cliente y la máquina por la red, mientras que el TPS mide la velocidad de la simulación del mundo. Puedes tener 15 ms de ping y sufrir tirones brutales si el mundo va a 12 TPS, y al revés, tener la simulación perfecta a 20 y notar retraso porque tu conexión doméstica es inestable. Diagnostícalos por separado: la consola te da el TPS, la tecla F3 te da el ping.

¿Reiniciar automáticamente cada noche ayuda al rendimiento?

Sí, y es una práctica estándar en comunidades activas. Un reinicio programado libera memoria fragmentada, descarga chunks que quedaron en caché, reinicia contadores de plugins y corta fugas de memoria menores antes de que se acumulen. Programa uno diario en la franja de menor actividad, con aviso previo en el chat y un guardado forzado antes del apagado. No sustituye a la optimización real: si el TPS cae a las dos horas de arrancar, tienes un problema estructural que el reinicio solo enmascara.

¿Cambiar de Vanilla a Paper rompe las granjas de redstone?

Algunas mecánicas cambian, pero la mayoría de granjas convencionales siguen funcionando. Los puntos sensibles son las granjas que dependen de comportamientos no documentados, como ciertos empujes de pistón o el orden exacto de actualización de redstone. Antes de migrar, prueba el mundo en una copia, revisa las granjas críticas y, si algo falla, restaura el comportamiento clásico poniendo redstone-implementation en VANILLA y revisando las opciones de corrección de bugs en la configuración por mundo.