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

Los TPS de un servidor Minecraft (Ticks Per Second) miden cuántas veces el mundo se actualiza cada segundo, y el valor de referencia estable es 20. Cuando ese número cae, los mobs se mueven a saltos, los cultivos tardan en crecer y los circuitos de redstone fallan o se retrasan. La causa casi nunca es única: chunks cargados de más, exceso de entidades, mobs mal gestionados, redstone mal diseñada o plugins que bloquean el hilo principal suelen combinarse.

Qué son los TPS de un servidor Minecraft y por qué se miden en 20

Cada tick representa un ciclo completo de simulación: movimiento de entidades, física de bloques, redstone, IA de mobs y sincronización con los clientes conectados. Minecraft está diseñado para ejecutar 20 ticks por segundo, es decir, un tick cada 50 milisegundos. Si el hilo principal tarda más de ese margen en procesar todo lo que ocurre en el mundo, el juego reduce automáticamente la frecuencia de actualización para no desincronizarse.

Ese ajuste automático es precisamente lo que se traduce en "lag de servidor": no es la conexión de red la que falla, sino el tiempo de cálculo del propio proceso Java. El indicador clave no es solo el TPS final, sino el MSPT (milisegundos por tick), que muestra cuánto margen queda antes de caer por debajo de 20.

Si administras una comunidad y necesitas hardware capaz de absorber picos de entidades sin perder ticks, un hosting Minecraft con CPU de frecuencias altas marca una diferencia real frente a un entorno con recursos compartidos entre varios procesos.

Qué provoca la caída de TPS: las causas más frecuentes

La mayoría de los problemas de rendimiento se concentran en cinco frentes. Identificarlos por separado es el primer paso antes de tocar cualquier archivo de configuración.

Chunks cargados y distancia de renderizado

Cada chunk activo obliga al servidor a calcular física, mobs y bloques dentro de su radio. Un view-distance alto combinado con muchos jugadores dispersos multiplica la carga de forma exponencial, no lineal, porque cada jugador genera su propio radio de chunks cargados.

Exceso de entidades y mobs

Granjas de mobs sin límites, criaderos de animales sin control de reproducción o pilas de ítems tirados en el suelo generan miles de entidades que el servidor debe procesar en cada tick. El "entity cramming" (demasiadas entidades apiladas en un mismo bloque) es una de las causas más comunes en supervivencia.

Redstone mal diseñada

Los relojes de redstone que se ejecutan sin pausa, los circuitos con bucles innecesarios o las granjas automáticas de gran escala generan actualizaciones constantes de bloques. Un solo reloj mal apagado puede consumir varios milisegundos por tick de forma permanente.

Plugins y mods mal configurados

Un plugin que ejecuta tareas pesadas de forma sincrónica (consultas a base de datos, escaneo de inventarios, generación de estructuras) bloquea el hilo principal mientras espera respuesta. Esto se nota especialmente en servidores con muchos plugins de economía o protección de terrenos.

Hardware compartido y almacenamiento lento

Un disco mecánico o un procesador compartido entre varios procesos introduce latencia en cada guardado de mundo y en cada cálculo intensivo. La generación de nuevos chunks es una operación de disco y CPU simultánea, y cualquier cuello de botella ahí se refleja directamente en el TPS.

Cómo diagnosticar la caída de TPS paso a paso

Antes de cambiar cualquier valor, hay que confirmar qué está consumiendo el tiempo de tick. El comando básico en Paper y Spigot es:

/tps

Este comando devuelve tres valores promediados en 1, 5 y 15 minutos. Un TPS por debajo de 18 de forma sostenida indica un problema real, no un pico puntual. Para saber exactamente qué proceso consume ese tiempo, la herramienta de referencia es spark, un profiler ligero que se instala como plugin o mod:

/spark profiler start
/spark profiler stop

El reporte generado muestra qué plugin, entidad o hilo de redstone acapara más milisegundos por tick. En Forge y NeoForge, el equivalente es:

/forge tps
/forge entity list

Este segundo comando lista las entidades por tipo y por chunk, útil para localizar granjas descontroladas o zonas con acumulación de ítems.

Ajustes concretos para recuperar 20 TPS estables

Una vez identificado el cuello de botella, los ajustes se aplican en tres capas: el archivo del servidor, la configuración de Paper/Spigot y los parámetros de la máquina virtual Java.

Reducir la carga de chunks

En server.properties, bajar view-distance y simulation-distance reduce directamente el número de chunks activos por jugador:

view-distance=8
simulation-distance=6

Limitar entidades y mobs

En spigot.yml, los límites por chunk evitan que una granja se descontrole:

spawn-limits:
  monsters: 50
  animals: 10
  ambient: 5
entity-activation-range:
  monsters: 24
  animals: 16
  misc: 8

Controlar redstone y tick-rate

Paper permite ajustar la frecuencia de actualización de hoppers y redstone en paper-world-defaults.yml, reduciendo la carga sin desactivar mecánicas:

hopper:
  disable-move-event: false
tick-rates:
  hopper-transfer: 8
  hopper-check: 8

Ajustar la JVM

Las flags de Aikar, ampliamente usadas en la comunidad, optimizan la recolección de basura de Java para reducir microcortes durante los guardados de mundo. Se aplican en el comando de arranque del proceso:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:MaxGCPauseMillis=130 -jar paper.jar nogui

Ninguno de estos cambios sustituye a un diagnóstico previo: aplicar límites de entidades sin haber confirmado que ahí está el problema puede ocultar una granja legítima sin resolver el cuello de botella real.

Mantenimiento continuo para evitar que los TPS vuelvan a caer

Un servidor optimizado en un momento dado puede degradarse con el tiempo a medida que la comunidad construye granjas nuevas o instala plugins adicionales. Revisar el rendimiento debe ser una tarea periódica, no puntual.

Programar reinicios automáticos cada cierto número de horas limpia la memoria acumulada y reduce la fragmentación del heap de Java. Combinarlo con sauvegardas automáticas evita pérdidas de progreso durante esos reinicios.

Si administras la máquina por línea de comandos, conectarte por SSH a un VPS Linux permite automatizar estas tareas con cron y scripts, además de monitorizar el uso de CPU y memoria en tiempo real con herramientas como htop.

Revisar los reportes de spark tras cada actualización de plugins o mods detecta regresiones antes de que afecten a toda la comunidad. Consulta también la documentación oficial de PaperMC para conocer los parámetros disponibles en cada versión.

Conclusión

Antes de tocar límites de entidades o flags de Java, diagnostica con spark o /tps qué consume realmente el tick. La mayoría de las caídas de rendimiento vienen de granjas sin control o de un view-distance excesivo, no de plugins puntuales. Ajusta primero lo que confirmes con datos, no lo que sospeches.

FAQ

¿Por qué mi servidor muestra 20 TPS pero se siente lento igualmente?

El TPS es un promedio y puede ocultar picos puntuales de MSPT que el jugador percibe como microcortes. También puede tratarse de latencia de red entre el cliente y la máquina, un problema distinto al de la simulación del mundo. Revisa el MSPT máximo, no solo el promedio, y descarta la latencia de conexión antes de tocar la configuración del mundo.

¿Los plugins de optimización sustituyen una buena configuración manual?

No. Plugins como ClearLagg o similares ayudan a limpiar entidades e ítems acumulados, pero no corrigen un view-distance excesivo, una granja mal diseñada o flags de Java mal ajustadas. Funcionan mejor como complemento de una configuración ya revisada, no como sustituto de un diagnóstico previo con herramientas como spark.

¿El número de jugadores conectados afecta tanto como las entidades?

Los jugadores en sí consumen poco tiempo de tick comparados con las entidades que generan a su alrededor: cada uno carga su propio radio de chunks y puede activar granjas, redstone o mobs cercanos. El impacto real depende más de qué hacen los jugadores (construir granjas, activar circuitos) que de su cantidad total conectada.