Entender y mejorar el TPS de un servidor de Minecraft

El TPS de un servidor Minecraft mide cuántos ticks procesa el juego cada segundo: 20 es el máximo y cualquier cifra por debajo se traduce en mobs congelados, golpes que no registran y bloques que reaparecen tras romperlos. Las caídas vienen casi siempre de cuatro focos concretos: chunks cargados de más, exceso de entidades, redstone mal diseñada y plugins pesados.

TPS servidor Minecraft: qué mide y por qué baja

Un tick es una iteración completa del bucle lógico del juego: mobs, física de bloques, crecimiento de cultivos, redstone, IA, guardado de chunks. El servidor dispone de 50 milisegundos para terminar ese trabajo. Si lo hace en 20 ms, espera los 30 restantes y mantiene 20 TPS estables. Si tarda 70 ms, el reloj se retrasa y el TPS cae.

De ahí una regla práctica: el TPS no es la métrica útil, lo es el MSPT (milisegundos por tick). Un servidor puede marcar 20.0 TPS con 48 ms de MSPT y estar al borde del colapso, porque cualquier pico de actividad lo tumbará. El MSPT te dice cuánto margen real te queda.

TPS medio	MSPT	Diagnóstico
20.0	menos de 30 ms	Margen amplio, aguanta eventos y granjas
19.5 a 20.0	30 a 45 ms	Correcto, pero sin colchón para picos
18.0 a 19.5	45 a 55 ms	Saturación puntual, ya se nota en combate
menos de 18.0	más de 55 ms	Lag permanente, hay que intervenir

Conviene separar dos causas que se confunden. Un TPS bajo es un problema de cómputo del lado del servidor (CPU monohilo, sobre todo). Un ping alto es un problema de red, y no afecta al TPS. Cuando el límite es el hardware y no la configuración, un hosting Minecraft sobre CPU de alta frecuencia como el Ryzen 9 7950X3D, con RAM DDR5 ECC y SSD NVMe, cambia el techo de la ecuación.

Diagnóstico: leer los comandos y perfilar el tick

Comandos base en Paper y derivados

En Paper, Purpur o Pufferfish tienes dos comandos inmediatos desde consola o en juego con permisos de operador. El primero da la media de TPS en tres ventanas temporales, el segundo desglosa el tiempo de tick.

/tps
# [Server thread/INFO]: TPS from last 1m, 5m, 15m: 19.98, 19.72, 18.40

/mspt
# Server tick times (avg/min/max) from last 5s, 10s, 1m:
# ◴ 5s: 41.2/28.9/78.4  10s: 43.0/28.1/91.2  1m: 46.8/27.4/188.6

Lee las tres ventanas juntas. Un 1m sano con un 15m malo apunta a un evento puntual ya terminado (un render de mapa, un chunk nuevo, un jugador volando por terreno sin generar). Un 15m estable y bajo indica una carga estructural: demasiadas entidades o un plugin que trabaja en cada tick.

Perfilado con Spark

Spark es la herramienta estándar para saber qué consume el tick, no solo cuánto. Lánzalo durante unos minutos de actividad real, con jugadores conectados, y revisa el informe web que genera.

/spark profiler start --timeout 180
/spark health
/spark tpsbar
/spark heapsummary

En el árbol de llamadas busca las ramas más gruesas: ServerLevel.tickBlockEntities suele ser hoppers y redstone, ServerLevel.tickNonPassenger apunta a mobs, y cualquier paquete com.tuplugin... con porcentaje alto identifica al culpable sin margen de duda. La documentación oficial de PaperMC detalla la interpretación de estos informes.

Watchdog y crashes por tick largo

Si el log muestra --- DO NOT REPORT THIS TO PAPER --- seguido de un volcado de hilo, el watchdog ha detectado un tick bloqueado. No es un fallo del software: algo ha tardado más que max-tick-time. El volcado indica exactamente en qué método se quedó colgado el hilo principal.

Distancia de chunks y carga del mundo

El ajuste con mayor impacto por minuto invertido es la distancia de visión y de simulación. Cada unidad de view-distance añade un anillo de chunks alrededor de cada jugador, y el coste crece de forma cuadrática. Pasar de 10 a 8 elimina cientos de chunks activos en un servidor con veinte conectados.

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

simulation-distance es el que manda sobre el TPS: define hasta dónde se simulan mobs, crecimiento y redstone. view-distance solo decide hasta dónde se envían chunks al cliente, así que pesa más en ancho de banda que en CPU. Bajar simulación a 4 o 5 y dejar visión en 8 mantiene la sensación de mundo abierto sin simular medio mapa.

Pregenerar el mundo

Generar terreno nuevo en caliente es una de las operaciones más caras que existe, sobre todo con generadores personalizados. Fija un borde de mundo y pregenera dentro de él con Chunky antes de abrir al público.

/worldborder set 6000
/chunky world world
/chunky radius 3000
/chunky start

Con el terreno ya escrito en disco, los jugadores que exploran solo provocan lecturas desde NVMe en lugar de generación completa. Ejecuta el pregenerado con el servidor cerrado o en horas valle, porque mientras dura consume todo el margen disponible.

Mobs, entidades y granjas bajo control

Cada entidad activa cuesta tiempo de tick: pathfinding, colisiones, comprobaciones de despawn. Un servidor con granjas de mobs y cientos de aldeanos gasta más en IA que en todo lo demás junto. Los límites se reparten entre dos archivos.

# bukkit.yml
spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  water-ambient: 2
  ambient: 1
ticks-per:
  monster-spawns: 4
  animal-spawns: 400

# spigot.yml
entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 32
  misc: 8
  water: 8
  villagers: 16
entity-tracking-range:
  players: 48
  animals: 48
  monsters: 48
merge-radius:
  item: 3.5
  exp: 4.0

El entity-activation-range congela la IA de las entidades fuera del radio indicado alrededor de un jugador. Reducirlo es la palanca más eficaz contra el lag de granjas, y apenas se percibe en juego porque nadie mira mobs a treinta bloques de distancia.

Aldeanos y cramming

Los aldeanos son las entidades más caras del juego por su lógica de trabajo, rutas y reputación. Limita su número por poblado con reglas de juego y con los ajustes de Paper, y aplica un límite de amontonamiento para que ninguna granja acumule cientos de mobs en un bloque.

/gamerule maxEntityCramming 8
/gamerule doMobSpawning true

# paper-world-defaults.yml
entity-per-chunk-save-limit:
  experience_orb: 30
  arrow: 16
  item: 200

Antes de tocar valores a ciegas, usa /spark profiler para confirmar que las entidades son realmente el foco. En muchos servidores el culpable está en otro sitio y estos recortes solo empeoran la experiencia de juego.

Redstone, hoppers y bloques con lógica

Los tile entities (cofres, hoppers, hornos, faros, spawners) se procesan cada tick estén o no cerca de un jugador. Una base con doscientos hoppers encadenados genera una carga constante que no desaparece al desconectarse todo el mundo. En el informe de Spark aparece como tickBlockEntities dominando el gráfico.

# paper-world-defaults.yml
hopper:
  cooldown-when-full: true
  disable-move-event: true
  ignore-occluding-blocks: true
redstone-implementation: ALTERNATE_CURRENT
tick-rates:
  mob-spawner: 2
  container-update: 3

disable-move-event evita disparar el evento de Bukkit en cada movimiento de ítem entre hoppers, algo que multiplica el coste cuando hay plugins escuchando. ALTERNATE_CURRENT sustituye el algoritmo de propagación de redstone por uno mucho más eficiente, con comportamiento equivalente en la inmensa mayoría de circuitos.

Reglas para la comunidad

• Prohibir relojes de redstone permanentes sin interruptor, son el caso número uno de tick desperdiciado.
• Sustituir cadenas largas de hoppers por water streams con un único hopper de recogida.
• Limitar el número de spawners y granjas de hierro por parcela o por facción.
• Revisar periódicamente con un plugin de laggchunks qué chunks concentran más entidades y tile entities.

Plugins, software base y ajustes de la JVM

Auditar los plugins

Un solo plugin mal escrito puede consumir más tick que todo el mundo junto, especialmente si hace consultas a base de datos de forma síncrona o escanea inventarios en cada evento. El informe de Spark los señala por paquete. Desactiva los sospechosos uno a uno y vuelve a medir con la misma carga de jugadores.

• Renderizadores de mapa web: programa los renders completos fuera de horario punta.
• Protecciones de terreno: prefieren las que cachean regiones a las que consultan disco en cada bloque.
• Plugins duplicados: dos sistemas de economía o de chat suman coste sin aportar nada.
• Plugins abandonados para versiones antiguas: suelen usar reflexión costosa para seguir funcionando.

Software base y versión de Java

Vanilla y CraftBukkit no incluyen las optimizaciones de tick que sí traen Paper y sus forks. Migrar de Spigot a Paper suele recuperar varios milisegundos de MSPT sin cambiar una sola línea de configuración. Ejecuta siempre sobre la versión de Java que recomienda el software base, normalmente Java 21 en las versiones recientes.

java -version
# openjdk version "21.0.3" 2024-04-16 LTS

# arranque con flags G1GC (ajusta Xms/Xmx a tu instancia)
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Asigna -Xms y -Xmx con el mismo valor para evitar redimensionados del heap, y nunca entregues a la JVM toda la memoria de la máquina: el sistema y el mapeo de archivos de región también la necesitan. Dar memoria de más alarga las pausas del recolector en lugar de acortarlas.

Reinicios y mantenimiento

Un reinicio programado cada doce o veinticuatro horas limpia fugas de memoria de plugins y libera chunks que quedaron marcados como cargados. Combínalo con copias de seguridad automáticas y con una revisión del log tras cada actualización. Desde el NexusPanel puedes gestionar consola en vivo, WebFTP y reinicios sin tocar la línea de comandos; el resto del catálogo está en Todos nuestros servidores de juegos.

Documenta cada cambio que hagas en un archivo aparte con la fecha del ajuste y el MSPT antes y después. Sin ese registro acabarás con veinte parámetros modificados y ninguna idea de cuál funcionó. Encontrarás más guías de administración en el Blog de Nexus Games.

Conclusión

Ataca en este orden: baja simulation-distance, recorta entity-activation-range y perfila con Spark antes de tocar nada más. El error que más tiempo cuesta es copiar una configuración ajena entera sin medir: acabas con un mundo empobrecido y el mismo MSPT. Si tras limpiar entidades, redstone y plugins el tick sigue por encima de 50 ms con pocos jugadores, el límite ya no está en la configuración sino en la frecuencia del procesador.

FAQ

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

No. El TPS mide el trabajo de cómputo del lado del servidor y depende de la CPU, las entidades y los plugins. El ping mide el tiempo de ida y vuelta de los paquetes por la red y depende de la distancia geográfica y de la calidad de la conexión. Puedes tener 20 TPS perfectos con 200 ms de ping, o 5 ms de ping con un TPS hundido. Diagnostica cada uno por separado: /mspt para el primero, la barra de latencia de la lista de jugadores para el segundo.

¿Cuánta RAM necesita un servidor de Minecraft para no perder TPS?

Depende del contenido. Una partida vanilla o con pocos plugins para una decena de jugadores funciona con 2 a 4 GB. Un servidor survival con plugins, protecciones y economía suele pedir 6 a 8 GB. Un modpack pesado tipo All the Mods arranca cómodo a partir de 8 a 12 GB. Ten en cuenta que añadir memoria no sube el TPS si el cuello de botella es la CPU: Minecraft ejecuta la lógica del mundo en un único hilo principal, así que la frecuencia del procesador pesa más que la cantidad de RAM.

¿Cómo saber qué chunk concreto está provocando el lag?

Instala un plugin de análisis de chunks o usa el comando /spark tickmonitor junto con /paper entity list, que devuelve el recuento de entidades por tipo y sus coordenadas. Busca chunks con cientos de ítems en el suelo, granjas de mobs activas o concentraciones de hoppers. Una vez localizado, teletranspórtate a esas coordenadas y revisa la construcción. Suele tratarse de una granja sin sistema de apagado o de una zona donde los ítems se acumulan porque el hopper de recogida está lleno.