Entender el TPS en un servidor Minecraft y evitar las caídas de rendimiento

El TPS del servidor Minecraft es la métrica que decide si tu mundo se mueve con fluidez o si los jugadores notan tirones, teletransportes raros y mobs que se congelan. Cuando el TPS cae por debajo de 20, algo en el servidor está consumiendo más tiempo de procesamiento del que dispone cada tick, y hay que encontrar la causa antes de que la comunidad empiece a desconectarse.

Qué es el TPS en un servidor Minecraft y cómo afecta la fluidez del juego

TPS significa "Ticks Por Segundo" (Ticks Per Second). Un tick es la unidad mínima de tiempo que usa Minecraft para actualizar el mundo: mover entidades, procesar redstone, generar chunks, calcular físicas de bloques, gestionar cultivos, etc. El valor de referencia es 20 TPS, lo que equivale a un tick cada 50 milisegundos.

Cuando el servidor tarda más de 50 ms en procesar un tick, no puede alcanzar los 20 TPS y empieza a "retrasarse". El motor intenta compensar, pero el resultado visible para el jugador es:

• Movimiento entrecortado de mobs y jugadores.
• Retraso entre pulsar un botón (romper bloque, atacar) y ver el efecto.
• Cultivos, hornos o granjas automáticas que dejan de progresar a la velocidad esperada.
• Desconexiones por timeout cuando el TPS cae de forma prolongada por debajo de 10.

Existe otra métrica complementaria, el MSPT (milisegundos por tick), que indica cuánto tiempo real consume cada tick. Un TPS de 20 con un MSPT alto y cercano a 50 ms significa que el servidor está al límite, aunque el indicador de TPS todavía no lo refleje como caída.

Si administras una comunidad y buscas una base con CPU Ryzen de alta frecuencia y almacenamiento NVMe para reducir el tiempo de procesamiento por tick desde el origen, puedes revisar el alojamiento servidor Minecraft de Fly-Serv antes de seguir optimizando la configuración.

Cómo diagnosticar caídas de TPS en tu servidor Minecraft

Antes de tocar nada hay que identificar el origen exacto. Un diagnóstico mal hecho lleva a desactivar mods o plugins que no tienen ninguna relación con el problema.

Comandos básicos para medir el TPS

En servidores Paper, Spigot o Purpur, el comando nativo muestra el promedio de TPS en los últimos 1, 5 y 15 minutos:

/tps

Un resultado como 20.0, 19.8, 18.4 indica que el servidor está teniendo dificultades sostenidas, no un pico puntual. En Forge o NeoForge, el comando equivalente es:

/forge tps

Usar un profiler para localizar el consumo real

El comando /tps dice que hay un problema, pero no dice cuál. Para eso se usa un profiler como spark, que genera un informe detallado del uso de CPU por plugin, entidad o mod:

/spark profiler start
/spark profiler stop
/spark tps

El informe muestra un árbol de llamadas ordenado por consumo, permitiendo ver si el cuello de botella está en un plugin de economía, en el pathfinding de mobs, en la generación de chunks o en un mod concreto. En servidores basados en Bukkit/Spigot también puede usarse el sistema de timings integrado:

/timings on
/timings paste

Causas más comunes de caída de TPS

Síntoma	Causa probable
TPS bajo en zonas concretas del mapa	Acumulación de entidades (granjas, mobs, ítems tirados)
TPS bajo al explorar zonas nuevas	Generación de chunks en tiempo real
TPS bajo constante desde el arranque	Configuración de memoria insuficiente o mal asignada
TPS bajo tras instalar un plugin/mod	Bug o tarea programada mal optimizada
TPS bajo con pocos jugadores conectados	Circuitos de redstone complejos o granjas automáticas sobrecargadas

Revisar el uso de RAM del proceso también ayuda: si el servidor pasa mucho tiempo en recolección de basura (garbage collection) porque la memoria asignada es escasa, el TPS cae de forma intermitente aunque la CPU no esté saturada.

Cómo corregir y optimizar el TPS de tu servidor Minecraft

Una vez localizada la causa, la corrección depende del tipo de problema.

Reducir la carga de entidades y chunks

Los parámetros del archivo server.properties tienen un impacto directo en el número de chunks cargados y en la carga por tick:

view-distance=8
simulation-distance=6
entity-broadcast-range-percentage=75

Bajar la distancia de simulación reduce cuántos chunks procesan físicas y mobs activamente, sin afectar tanto a la parte visual como bajar la distancia de vista.

Ajustar las banderas de la JVM

La forma en que Java gestiona la memoria influye directamente en el TPS. Un conjunto de banderas ampliamente usado para reducir las pausas de garbage collection es el siguiente:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
-jar server.jar nogui

Es importante fijar -Xms y -Xmx al mismo valor para evitar que la JVM redimensione el heap en caliente, lo cual genera microcortes de TPS.

Pregenerar el mundo

Gran parte de las caídas de TPS en servidores de exploración vienen de la generación de terreno en tiempo real. Pregenerar los chunks con un plugin como Chunky elimina ese coste durante el juego normal:

/chunky radius 5000
/chunky start

Auditar plugins y mods

Un plugin mal codificado con tareas programadas cada tick (runTaskTimer con intervalo muy corto) puede consumir más CPU que decenas de jugadores activos. El informe de spark identifica exactamente qué clase y qué método consume el tiempo de tick, lo que permite decidir si hay que actualizar, reconfigurar o retirar el plugin.

Buenas prácticas de administración para mantener un TPS estable

Diagnosticar es reactivo; mantener el TPS estable en el tiempo requiere rutina de administración.

Reinicios programados

La memoria fragmentada y las entidades acumuladas tras horas de actividad tienden a degradar el TPS de forma gradual. Programar un reinicio nocturno mediante una tarea cron reduce ese desgaste:

0 5 * * * systemctl restart minecraft-server.service

Copias de seguridad antes de cada cambio

Antes de tocar banderas de JVM, actualizar un mod o modificar el archivo de configuración, conviene generar una copia de seguridad reciente. Un panel Pterodactyl permite programar sauvegardas automáticas y restaurar en pocos clics si un cambio empeora el rendimiento en lugar de mejorarlo.

Monitoreo continuo

Revisar el TPS solo cuando ya hay quejas de jugadores llega tarde. Herramientas como spark permiten dejar un perfil corriendo en segundo plano durante horas de mayor actividad, y en una instancia VPS también es posible revisar el consumo de CPU y RAM del proceso Java directamente por SSH:

top -p $(pgrep -f server.jar)

Seguridad básica que también protege el rendimiento

• Contraseñas RCON robustas y puerto de administración cerrado al exterior.
• Whitelist activa en servidores privados de comunidad para evitar bots que generan entidades o spam de conexiones.
• Actualizaciones regulares del core (Paper/Purpur) para incorporar optimizaciones de rendimiento ya corregidas aguas arriba.

Para profundizar en la mecánica interna de los ticks, la documentación técnica del wiki oficial de Minecraft detalla cómo se procesa cada fase del ciclo de juego.

Si administras varios títulos además de Minecraft, revisar Todos nuestros servidores de juegos o gestionar tu propia instancia desde un VPS Pterodactyl también ayuda a mantener un flujo de trabajo homogéneo entre proyectos.

Conclusión

Mantener el TPS cerca de 20 es un trabajo continuo de diagnóstico y ajuste: identificar la causa real con un profiler, corregir la configuración del mundo y de la JVM, y establecer una rutina de mantenimiento evita que las caídas de rendimiento se conviertan en un problema recurrente para tu comunidad.

FAQ

¿Por qué el TPS baja aunque tenga pocos jugadores conectados?

Suele deberse a granjas automáticas, acumulación de entidades o circuitos de redstone complejos que generan carga por tick independientemente del número de jugadores. Usa un profiler como spark para identificar qué proceso concreto consume el tiempo de tick.

¿Qué diferencia hay entre TPS y MSPT?

El TPS mide cuántos ticks se completan por segundo (máximo 20), mientras que el MSPT mide cuánto tarda en procesarse cada tick individual. Un MSPT cercano a 50 ms indica que el servidor está al límite aunque el TPS todavía marque 20.

¿Ayuda pregenerar el mundo a mejorar el TPS?

Sí, pregenerar chunks con un plugin como Chunky elimina el coste de generación de terreno en tiempo real, que es una de las causas más frecuentes de caídas de TPS durante la exploración.