Cómo mantener un TPS estable en tu servidor de Minecraft

El TPS de un servidor Minecraft mide cuántos ticks completa el mundo cada segundo: 20 es el valor sano y cualquier cifra inferior significa que todo va a cámara lenta. Las caídas rara vez vienen de la memoria; suelen nacer de chunks cargados de más, entidades acumuladas y automatizaciones mal diseñadas. Aquí tienes cómo medirlo y qué tocar.

Qué mide el TPS y por qué 20 es el techo

El motor del juego procesa el mundo en ticks. Cada tick actualiza mobs, crecimiento de cultivos, redstone, física de fluidos, tolvas y jugadores. El objetivo son 20 ticks por segundo, es decir 50 milisegundos de presupuesto por tick. Si el trabajo cabe en esos 50 ms, el TPS se mantiene en 20 y nadie nota nada.

Cuando un tick tarda más de 50 ms, el siguiente empieza tarde y el TPS baja. A 15 TPS los mobs se mueven a saltos y las tolvas transportan más lento. A 10 TPS el día dura el doble y los golpes se registran con retraso. Por debajo de 5 TPS el mundo está prácticamente congelado.

TPS y MSPT no son lo mismo

El MSPT (milisegundos por tick) es la métrica realmente útil. El TPS se queda clavado en 20 mientras haya margen, así que un servidor con 45 ms de MSPT muestra 20 TPS perfectos pero está al borde del colapso. Vigila el MSPT: por debajo de 30 ms tienes holgura, entre 30 y 50 ms estás en zona de riesgo.

Otro punto que confunde a mucha gente: el tick principal es mono-hilo. Añadir núcleos no acelera la lógica del mundo, solo ayuda a tareas paralelas como la generación de chunks, la compresión de red o el guardado. Lo que manda es la frecuencia por núcleo y el rendimiento IPC del procesador.

Diagnóstico: localizar el origen real de las caídas

Antes de tocar un solo archivo, mide. Cambiar valores a ciegas suele empeorar la experiencia de juego sin recuperar ticks. Si tu mundo corre sobre un CPU compartido entre decenas de instancias, ningún ajuste compensará la falta de frecuencia: ahí un hosting Minecraft con Ryzen 9 7950X3D, DDR5 ECC y SSD NVMe cambia el punto de partida.

Comandos básicos de medición

/tps
/mspt
/spark tps
/spark health --memory
/spark profiler start --timeout 300
/spark profiler stop

El perfilador de spark es la herramienta estándar en Paper y derivados. Deja correr el muestreo cinco minutos en hora punta y genera un informe web donde ves qué porcentaje del tick consume cada tarea: entidades, tolvas, un plugin concreto o la generación de terreno. Con eso dejas de adivinar.

Lectura del informe

• EntityTickList / ServerLevel.tickNonPassenger: exceso de entidades vivas.
• HopperBlockEntity.tick: demasiadas tolvas activas buscando contenedores.
• ChunkMap / ChunkHolder: chunks generándose o cargándose sin parar.
• RedstoneWireTurbo o NeighborUpdater: circuitos de redstone en bucle.
• Un paquete de plugin en la pila: tarea síncrona pesada, normalmente consultas a base de datos.

Tabla de síntomas frecuentes

Síntoma	Causa habitual	Dónde actuar
Tirón cada pocos minutos	Autoguardado del mundo	paper-world-defaults.yml, chunks por tick
Bajada al explorar	Generación de terreno nuevo	Pregeneración con Chunky, distancia de vista
Caída constante con gente conectada	Entidades y mobs acumulados	spawn-limits, entity-activation-range
Congelación al entrar un jugador	Carga de datos desde disco o base de datos	Almacenamiento NVMe, consultas asíncronas
Lag solo en una zona	Granja o circuito concreto	Perfilado por chunk con spark

Chunks cargados y distancia de simulación

Cada chunk cargado con ticks activos cuesta CPU aunque no haya nadie cerca. La cuenta crece rápido: portales del Nether abiertos, chunk loaders con carros de minas, comandos /forceload olvidados y plugins que mantienen zonas activas para granjas o eventos. Un mundo con miles de chunks activos nunca sostendrá 20 TPS estables.

Separar vista de simulación

La distancia de vista define lo que el jugador ve; la de simulación, lo que realmente recibe ticks. Bajar la simulación a 4 o 5 y mantener la vista en 8 o 10 conserva un horizonte decente y recorta mucho trabajo. Esta separación es una de las palancas más rentables en servidores con muchos jugadores.

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

Pregenerar antes de abrir

Generar terreno en caliente es de las tareas más caras que existen. Pregenerar el mapa hasta el radio del borde del mundo elimina esos picos y, de paso, reduce la fragmentación de archivos de región. Combínalo con un worldborder definido para que el mundo no crezca sin control con cada exploración.

/worldborder set 8000
/chunky radius 4000
/chunky start

Entidades y mobs: el peso que casi nadie audita

Cada entidad viva ejecuta IA, colisiones y física en el hilo principal. Los aldeanos son especialmente caros por su lógica de trabajo y rutas; los animales criados sin control y los ítems tirados por el suelo también suman. Un solo chunk con doscientas entidades puede llevarse un tercio del presupuesto de tick.

Ajustes en bukkit.yml y spigot.yml

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

# spigot.yml
entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8
  water: 8
merge-radius:
  item: 3.5
  exp: 4.0
mob-spawn-range: 6

Reglas de juego que ayudan

• /gamerule maxEntityCramming 8 limita amontonamientos en granjas.
• /gamerule randomTickSpeed 3 mantiene el valor por defecto; subirlo dispara el coste de cultivos y fuego.
• /gamerule doFireTick false evita propagaciones caras y griefing accidental.
• Limita mascotas y monturas por jugador con un plugin de límites por chunk.

Audita también los marcos de ítems y los soportes de armadura en spawns decorados. Paper permite dejar de tickear soportes que no se mueven y limitar cuántas entidades se guardan por chunk, lo que evita que una zona corrupta arrastre al mundo entero cada vez que se carga.

Redstone, tolvas y automatizaciones que rompen el ritmo

Los circuitos de redstone generan actualizaciones de bloques en cascada. Un reloj de observadores olvidado bajo tierra puede consumir más que treinta jugadores conectados. Localiza estos puntos con el mapa de calor por chunk de spark y habla con los constructores: casi siempre existe un diseño equivalente con una décima parte del coste.

Tolvas: el enemigo silencioso

Una tolva comprueba el contenedor superior varias veces por segundo aunque esté vacía. Cientos de tolvas en un almacén comunitario se traducen en un gasto fijo permanente. Reemplaza cadenas largas por cofres dobles con embudo único, y activa el enfriamiento cuando la tolva está llena para que deje de sondear.

# paper-world-defaults.yml (extracto)
hopper:
  cooldown-when-full: true
  disable-move-event: false
misc:
  redstone-implementation: ALTERNATE_CURRENT
entities:
  armor-stands:
    tick: false
  spawning:
    despawn-ranges:
      monster:
        hard: 96
        soft: 32

Normas de comunidad que evitan trabajo

• Prohibir relojes de redstone permanentes fuera de zonas designadas.
• Limitar el número de tolvas por parcela protegida.
• Obligar a apagar granjas con una palanca cuando no se usan.
• Revisar mensualmente las granjas de hierro y oro más grandes del mapa.

Motor, flags de JVM y ajustes que estabilizan el TPS servidor Minecraft

El software que ejecuta el mundo condiciona el techo de rendimiento. Vanilla es la referencia de comportamiento pero no optimiza nada; Paper reescribe partes críticas del tick y expone decenas de parámetros; Purpur añade más control fino sobre entidades y mecánicas. En modding, Fabric con Lithium y Ferrite Core rinde bastante mejor que Forge puro con las mismas mecánicas.

Motor	Fuerte en	A tener en cuenta
Vanilla	Fidelidad total de mecánicas	Sin parámetros de optimización
Paper	Plugins Bukkit y ajustes finos	Algunas granjas técnicas cambian
Purpur	Control detallado por entidad	Muchos valores que auditar
Fabric + Lithium	Modpacks con buena optimización	Ecosistema de plugins limitado

Memoria: ni poca ni de más

Asignar toda la RAM disponible no sube el TPS; alarga las pausas del recolector de basura. Fija -Xms y -Xmx al mismo valor y usa G1GC con parámetros ajustados. Un mundo survival con plugins suele funcionar bien con 6 a 8 GB; un modpack grande pide más, pero el salto siempre debe justificarse con datos del perfilador.

java -Xms8G -Xmx8G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Verifica siempre los parámetros recomendados en la documentación oficial de Paper antes de copiar una línea de arranque de un foro. Los valores cambian entre versiones de Java y una bandera obsoleta puede impedir el arranque o degradar el recolector sin avisar.

Plugins y almacenamiento

Un plugin mal escrito que consulte SQLite en el hilo principal congela el mundo en cada operación. Migra a MySQL o MariaDB con acceso asíncrono cuando el plugin lo permita, y desactiva módulos que no usas. El almacenamiento NVMe reduce los picos de guardado, sobre todo con mapas grandes y copias de seguridad automáticas.

Reparte también el trabajo: si tu comunidad gestiona varios mundos o varios juegos, separar instancias evita que un modpack pesado arrastre al resto. Puedes revisar el catálogo en Todos nuestros servidores de juegos y otras guías técnicas en el Blog de Nexus Games.

Conclusión

Empieza siempre por medir con spark durante la hora punta: el 80 % de los casos se resuelve con tres acciones concretas, bajar la distancia de simulación, recortar entidades acumuladas y desactivar la granja de tolvas que nadie usaba. La memoria extra no arregla un tick saturado. Y si el procesador está compartido con demasiadas instancias, ningún archivo de configuración devolverá esos 20 ticks por segundo.

FAQ

¿Cuánta RAM hace falta para que no baje el TPS?

La memoria no determina el TPS, solo evita cuelgues por saturación. Un survival con plugins funciona con holgura entre 6 y 8 GB, y un modpack grande puede pedir 10 o 12 GB. Asignar 32 GB a un mundo pequeño alarga las pausas del recolector de basura y empeora la fluidez. Ajusta la memoria al uso real que muestre el perfilador y dedica el presupuesto restante a frecuencia de CPU.

¿Un TPS bajo aumenta el ping de los jugadores?

No directamente. El ping mide el tiempo de ida y vuelta por la red, mientras que el TPS mide la velocidad del mundo. Sin embargo, la sensación es parecida: con TPS bajo los golpes se registran tarde y los bloques reaparecen, aunque el ping siga en valores normales. Si el ping es alto y el TPS correcto, revisa la ruta de red; si ocurre lo contrario, el problema está en el tick.

¿Cómo se pregenera un mundo sin dejar el servidor inutilizable?

Usa un plugin como Chunky y limita la velocidad de generación con el parámetro correspondiente, por ejemplo veinte chunks por segundo. Lánzalo de madrugada, con el mundo cerrado o con pocos jugadores, y define antes un worldborder para saber dónde parar. Al terminar, guarda una copia de seguridad completa: la generación crea muchos archivos de región nuevos y conviene tener un punto de restauración limpio.