Cómo solucionar el lag en un servidor de Minecraft

¿Lag del servidor, de la red o del cliente?

La prueba más rápida es preguntar si todos tienen lag en el mismo momento. Un servidor que se queda atrás congela a todos los jugadores a la vez; una mala conexión o un PC lento solo afectan a su dueño. El resto de esta guía trata del lag del servidor.

Primero mide: TPS, MSPT y spark

Un servidor de Minecraft funciona a 20 ticks por segundo, así que cada tick tiene 50 ms para completarse. Dos cifras describen cómo lo lleva:

• TPS (ticks por segundo): 20 significa que el servidor va al día; por debajo de 20 el mundo se ralentiza.
• MSPT (milisegundos por tick): cuánto tarda cada tick. Por debajo de 50 ms sobra tiempo; por encima de 50 ms el servidor se queda atrás.

Paper tiene /tps y /mspt, pero su propia documentación remite a spark, que viene integrado en Paper desde la 1.21 y está disponible como mod para Fabric, Forge y NeoForge:

/spark tps
/spark health
/spark ping

/spark tps muestra el TPS de los últimos segundos y minutos y, lo que es más útil, la duración de los ticks como mínimo, mediana, percentil 95 y máximo. /spark ping muestra el ping de los jugadores, lo que resuelve la duda de "servidor o red". /spark health añade CPU, memoria y disco.

Encuentra la causa con un perfil de spark

Las cifras dicen que el servidor tiene lag; un perfil dice por qué. Inicia uno mientras el lag está ocurriendo y déjalo correr unos minutos:

/spark profiler start --timeout 300

Cuando termina, spark publica un enlace a su visor web. En él:

1. Abre el Server thread, el hilo principal que ejecuta el mundo. Ahí es donde vive el lag.
2. Despliega las entradas con los porcentajes más altos: ahí es donde se va el tiempo de tick.
3. Cambia a la vista Sources para ver el tiempo repartido por plugin o mod. Un plugin o mod que se lleva una gran parte del hilo principal suele ser la respuesta.

Hay dos herramientas más para el lag que va y viene: /spark tickmonitor informa de cada tick que se alarga, y /spark profiler start --only-ticks-over 100 registra solo los ticks lentos, para que un pico poco frecuente no quede diluido en la media.

Las soluciones que importan, por orden

1. Distancia de visión y de simulación

En server.properties, simulation-distance fija hasta qué distancia de los jugadores se simula realmente el mundo (mobs, cultivos, redstone) y view-distance hasta dónde se envían chunks a los jugadores. Ambas valen 10 por defecto. Bajar simulation-distance suele ser la mayor mejora por sí sola: prueba entre 6 y 8, y deja view-distance un poco más alta para que el mundo siga pareciendo abierto. Son puntos de partida, no valores oficiales; mide antes y después.

2. Pregenera el mundo

Generar chunks nuevos es una de las tareas más costosas para un servidor, y los jugadores que exploran en distintas direcciones le obligan a hacerlo constantemente. El plugin (o mod) Chunky genera el mapa por adelantado:

chunky radius 5000
chunky start
chunky pause
chunky continue

Ejecútalo cuando no haya nadie jugando (una pregeneración en curso hace que el servidor muestre "Can't keep up" por diseño) y ponlo en pausa cuando entren jugadores.

3. Entidades y granjas

Las granjas de mobs, las salas de aldeanos y los montones de ítems son el desgaste constante más habitual. En Paper y Spigot, entity-activation-range en spigot.yml controla lo cerca que debe estar un jugador para que una entidad reciba ticks completos, y merge-radius fusiona los ítems soltados y los orbes de experiencia. Limita las granjas de mobs con un plugin o una norma, y elimina los montones de ítems olvidados.

4. Tolvas y redstone

Las cadenas grandes de tolvas son costosas. En spigot.yml, ticks-per.hopper-transfer fija cada cuánto mueven ítems, y hopper.disable-move-event de Paper las acelera mucho, pero rompe los plugins de protección que dependen de ese evento. Para la redstone, misc.redstone-implementation: ALTERNATE_CURRENT de Paper puede reducir mucho el lag del polvo de redstone, pero cambia su comportamiento, así que prueba antes tus mecanismos.

5. El plugin o mod de tu perfil

Si el perfil de spark apunta a un plugin o mod concreto, esa es la solución: actualízalo, rebaja su configuración o sustitúyelo. Ninguna cantidad de RAM hace más rápido un plugin mal escrito.

"El TPS está en 20 pero sigue habiendo lag"

Este es el caso más confuso, y casi siempre se trata de un bloqueo de tick: la mayoría de los ticks son rápidos, pero de vez en cuando uno tarda cientos de milisegundos. La media se mantiene en 20, pero todos notan el parón.

• Revisa el tiempo de tick máximo en /spark tps, o ejecuta /spark tickmonitor. Picos de varios cientos de milisegundos lo confirman.
• La causa habitual es un plugin que espera en el hilo principal: descargar skins o cabezas de jugadores de internet, enviar datos a un webhook, buscar actualizaciones o comprobar una licencia, o guardar un archivo o una base de datos de forma síncrona. El servidor no hace nada mientras espera.
• Perfila la espera, no solo el cálculo. Un perfil normal muestra el trabajo de CPU; un hilo que espera parece inactivo. Usa /spark profiler start --thread * para captar dónde se va el tiempo, esperas incluidas, y busca llamadas de red o de archivos en el Server thread.

La solución está en el plugin: llamadas asíncronas u otro plugin distinto. Más RAM, una CPU más rápida o una conexión mejor no ayudarán, porque al servidor no le falta nada; está esperando.

Cuando la respuesta sí es RAM o CPU

Minecraft simula el mundo en un único hilo principal. Eso tiene dos consecuencias:

• Lo que más importa es la velocidad de la CPU por núcleo. Si spark muestra el Server thread ocupado con el trabajo normal del mundo (entidades, chunks, ticks de bloques) y el MSPT es alto, una CPU más rápida ayuda donde más núcleos no lo harían.
• La RAM solo ayuda cuando te falta. Señales: el servidor se reinicia al llegar a su límite de memoria, o las pausas de recolección de basura dominan el perfil. Por encima de lo que necesitan el mundo y los mods, más RAM no mejora la velocidad de tick, y un heap sobredimensionado y sin ajustar puede alargar las pausas de recolección de basura.

Cuánta RAM necesita un servidor y los parámetros de arranque que mantienen cortas las recolecciones de basura se explican en cuánta RAM necesita un servidor de Minecraft. La elección entre Paper, Purpur y el resto está en el mejor software para servidores de Minecraft.

El lag y tu servidor de HytHost

Todos los planes de Minecraft de HytHost funcionan con el mismo hardware: CPU Ryzen 7 e Intel i9 con boost de hasta 5.0 GHz, memoria DDR4 y almacenamiento NVMe, es decir, la velocidad por hilo de la que depende Minecraft. spark ya forma parte de Paper, así que puedes perfilar desde la consola desde el primer momento.

Si tu perfil muestra que al servidor le falta memoria de verdad para su mundo y sus mods, sube de plan desde el panel; el mundo se queda donde está. Si muestra un plugin o una granja, arregla eso primero: es gratis y funciona en cualquier plan. Consulta hosting de Minecraft, o los planes más grandes en hosting de Minecraft premium desde €11.65/mes.