Cómo diagnosticar y corregir las caídas de TPS en un servidor de Minecraft

Medir los TPS de un servidor Minecraft es lo primero que hay que hacer cuando el mundo empieza a ir a trompicones: 20 ticks por segundo es el máximo teórico, y por debajo de 18 los jugadores ya notan que los mobs se congelan, la redstone se arrastra y los golpes no registran. La buena noticia es que casi siempre hay una causa concreta y localizable.

TPS servidor Minecraft: qué mide realmente el tick rate

Un tick es un ciclo completo de simulación: movimiento de entidades, física de bloques, crecimiento de cultivos, redstone, IA de mobs, guardado de chunks. El juego intenta ejecutar 20 por segundo, es decir, uno cada 50 milisegundos. Si el ciclo tarda más, no se acelera después: simplemente se ejecutan menos ticks y el tiempo del mundo se dilata.

Del tick rate al MSPT

Los TPS son un indicador de resultado, el MSPT (milisegundos por tick) es el indicador de causa. Un mundo con 20 TPS y 45 MSPT está al borde del colapso aunque el número se vea perfecto: basta un jugador más o una explosión de creeper para pasar del límite. Vigilar el MSPT permite anticipar la caída en lugar de reaccionar tarde.

Cuándo lo nota un jugador

• 20 TPS / menos de 35 MSPT: simulación sana, hay margen.
• 19 a 18 TPS: relojes de redstone desincronizados, hornos lentos.
• 17 a 15 TPS: mobs a saltos, golpes que no registran, cofres que tardan en abrirse.
• Menos de 15 TPS: el reloj del día se retrasa de forma visible y las granjas automáticas pierden rendimiento.

Un tick desbordado casi nunca es culpa de un solo bloque: suele ser la suma de entidades, chunks activos y código de terceros compitiendo por el mismo hilo principal. Antes de tocar la configuración conviene saber si la máquina tiene margen de CPU, porque un hosting Minecraft con núcleos de alta frecuencia parte de una base muy distinta a la de un procesador compartido y saturado.

Herramientas de diagnóstico: consola, spark y perfiles de rendimiento

Comandos rápidos desde la consola

En cualquier build derivado de Paper o Spigot tienes datos inmediatos sin instalar nada. Ejecútalos en caliente, mientras el problema está ocurriendo, no cinco minutos después.

/tps
/mspt
/paper entity list
/paper dumpitem
list

El comando /paper entity list devuelve el recuento de entidades por tipo y por chunk. Es la forma más rápida de descubrir que alguien tiene 900 pollos en una parcela o que una granja de hierro lleva días acumulando zombis sin procesar.

Perfilar con spark sin detener el mundo

spark es la herramienta estándar para saber qué función concreta se come el tick. Se instala como plugin o mod y genera un informe navegable en el navegador. Un perfil de cinco minutos durante la hora punta vale más que veinte hipótesis.

/spark tps
/spark health
/spark profiler start --timeout 300
/spark profiler stop
/spark heapsummary

Cómo leer el informe

En el árbol de llamadas, busca las ramas que superan el 10 % del tiempo total. Si el peso está en ServerLevel.tickEntities, el problema son entidades. Si aparece ChunkMap o ChunkGenerator, es generación o carga de terreno. Si ves el nombre de un plugin en la pila, ya tienes al responsable. La documentación de spark detalla cada comando y sus opciones.

Síntoma	Causa frecuente	Primera acción
Caída al conectarse un jugador nuevo	Generación de chunks en tiempo real	Pregenerar el mundo y bajar la distancia de visión
Micro-cortes cada pocos minutos	Guardado automático o pausa del recolector de basura	Ajustar el autosave y los argumentos de la JVM
MSPT alto de forma constante	Exceso de entidades vivas	Revisar límites de aparición y rangos de activación
Lag solo en una zona del mapa	Granja masiva o batería de tolvas	Desactivar el evento de movimiento de tolvas y auditar la base
Retardo al abrir menús o al teletransportarse	Consulta a base de datos en el hilo principal	Perfilar el plugin implicado y aislarlo

Chunks, mobs y granjas: dónde se pierde el tiempo de simulación

Chunks cargados permanentemente

Cada chunk dentro de la distancia de simulación consume tiempo en cada tick, tenga jugadores dentro o no. Los portales del Nether, los chunks anclados por plugins y los mundos secundarios abiertos sin nadie dentro multiplican esa carga silenciosamente. Reducir simulation-distance es el ajuste con mejor relación esfuerzo/resultado de toda la lista.

view-distance=8
simulation-distance=6
sync-chunk-writes=false
max-tick-time=60000

La distancia de visión se puede mantener alta porque afecta sobre todo al envío de datos, mientras que la de simulación es la que ejecuta física, IA y aparición de criaturas. Separarlas permite un horizonte visual amplio sin pagarlo en cada ciclo.

Mobs y límites de aparición

El sistema de aparición trabaja por jugador conectado en las versiones modernas, así que veinte jugadores dispersos generan mucha más presión que veinte agrupados. Bajar los límites de monstruos y espaciar los ciclos de aparición apenas se nota en la partida y libera varios milisegundos por tick.

Entidades sueltas y tolvas

Ítems tirados, marcos con contenido, armor stands decorativos y minecarts con tolva son los sospechosos habituales de un mundo con años de vida. Las tolvas son especialmente caras porque comprueban su contenido y el bloque superior continuamente. Una sala de clasificación con doscientas tolvas puede costar más que todos los mobs del mapa juntos.

Complementos pesados y tareas mal programadas

Aislar al culpable

Si spark señala un plugin, confírmalo antes de acusar. Arranca en un mundo de pruebas con la mitad de los complementos, mide, y repite dividiendo hasta quedarte con uno. Es lento pero infalible, y evita desinstalar cosas útiles por corazonada.

• Protección de terreno: comprobaciones por bloque colocado o roto en regiones enormes.
• Registro de acciones: escritura sin lotes en la base de datos durante el tick.
• Economía y menús: consultas SQL síncronas al abrir una interfaz.
• Limpiadores automáticos: barridos masivos que provocan justo el pico que dicen evitar.
• Plugins abandonados: compilados para una versión antigua y con APIs sustituidas.

Señales de código mal escrito

Un complemento que ejecuta tareas cada tick sin necesidad, que itera sobre todos los jugadores en un evento de movimiento o que abre conexiones nuevas sin pool de conexiones va a doler siempre. Cuando exista una alternativa mantenida y con soporte asíncrono, cambiar de plugin resuelve más que cualquier ajuste de configuración.

Ajustes concretos en spigot.yml, bukkit.yml y Paper

Rangos de activación en 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
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8

Límites de aparición en bukkit.yml

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

Opciones por mundo en Paper

En las versiones actuales, estas claves viven en config/paper-world-defaults.yml. Cada una recorta trabajo que el mundo hace sin que nadie lo perciba en la partida.

entities:
  spawning:
    per-player-mob-spawns: true
  armor-stands:
    tick: false
chunks:
  max-auto-save-chunks-per-tick: 8
hopper:
  disable-move-event: true
  ignore-occluding-blocks: true
misc:
  update-pathfinding-on-block-update: false

La referencia completa de cada clave está en la documentación de PaperMC. Cambia un bloque de opciones cada vez y vuelve a medir: modificar quince valores a la vez impide saber cuál ayudó.

Memoria y recolector de basura

Asignar demasiada memoria es tan dañino como asignar poca: las pausas del recolector se alargan y aparecen congelaciones periódicas. Fija -Xms y -Xmx al mismo valor y usa un juego de argumentos G1 afinado para Java.

java -Xms6G -Xmx6G \
  -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 \
  -jar paper.jar --nogui