Lag en servidores de Minecraft: encuentra la causa antes de arreglarlo

Antes de cambiar un solo ajuste, averigua cuál de estos tres lags tienes: el bucle de ticks del servidor quedándose atrás, la red entre los jugadores y el servidor, o el propio ordenador de un jugador que no consigue dibujar el juego. Ejecuta /spark tps en tu hora más concurrida. Si las duraciones de tick se quedan por debajo de 50 ms, el servidor aguanta y el lag que notan tus jugadores viene de otro sitio.

La mayoría de las "guías de optimización" se saltan ese paso y te dan una lista de ajustes. Algunos de esos ajustes ayudan, unos pocos empeoran el juego y ninguno arregla un problema que no has encontrado. Esta guía empieza por el diagnóstico.

Tres tipos de lag (tick del servidor, red, cliente)

Un breve apunte técnico sobre las cifras, porque explica por qué los TPS mienten. El servidor aspira a 20 ticks por segundo, así que cada tick tiene un presupuesto de 50 ms. Los TPS nunca pueden pasar de 20, de modo que un servidor que necesita 10 ms por tick y otro que necesita 48 ms marcan los dos 20,0 TPS. El primero podría soportar varias veces su carga actual, el segundo está a una granja de tolvas de empezar a ir con lag. Los MSPT (milisegundos por tick) muestran ese margen, así que vigila los MSPT, no los TPS.

Mide antes de cambiar nada

1. Elige la hora adecuada. El lag que ocurre en la hora pico no se puede medir a las cinco de la mañana. Las cuatro horas más concurridas de toda nuestra lista son de 14:00 UTC a 18:00 UTC en tu zona horaria, y la página pública de estadísticas de tu ficha muestra tus propias horas más concurridas.
2. Ejecuta /spark tps. Muestra los TPS de los últimos 5 segundos a 15 minutos y las duraciones de tick como mínimo, mediana, percentil 95 y máximo. Una mediana muy por debajo de 50 ms con un percentil 95 por encima significa picos, no una sobrecarga constante. El /mspt de Paper da la versión corta.
3. Ejecuta /spark health. Añade el uso de CPU, memoria y disco, para que veas de un vistazo si a la propia máquina le falta algo.
4. Lee la consola. El aviso de vanilla Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (la consola del servidor siempre lo escribe en inglés) significa que el servidor se quedó atrás y avanzó de golpe para ponerse al día. Uno al día es ruido. Uno por minuto es un problema.
5. Apunta los valores de referencia: hora, jugadores en línea, mediana y percentil 95 de los MSPT, y dónde estaban los jugadores (una zona nueva, una granja grande, un evento). Los compararás después de cada cambio.

En un servidor sin spark, el /tick query de vanilla (Java Edition 1.20.3 y posteriores, nivel de permiso 3) informa del tiempo medio por tick y de sus percentiles.

Pico 16:00 UTC

0003060912151821

Horas en UTC

Más gente a las 16:00 UTC, con unos 17.845 jugadores, y menos a las 01:00 UTC. La hora con más gente reúne 2,6 veces los jugadores de la más tranquila.

Medido el 19 oct 2026, 23:05 UTCCómo medimos

Cómo leer un perfil de spark

Cuando las cifras dicen que el servidor va lento, el profiler dice por qué. La documentación de PaperMC sugiere:

/spark profiler start --timeout 600

Eso muestrea todos los hilos durante diez minutos y te da un enlace al informe. Dos variantes ayudan con problemas concretos:

• /spark profiler start --only-ticks-over 100 registra solo los ticks de más de 100 ms, lo que separa los picos de lag breves del ruido de fondo normal.
• /spark tickmonitor --threshold-tick 100 imprime una línea cada vez que un tick tarda más de 100 ms, para que puedas relacionar los picos con lo que pasaba en el juego.

El perfil tiene que ejecutarse mientras ocurre el lag. Un perfil de un servidor tranquilo a las 05:00 no te dice nada del lag de las 18:00.

En el visor, abre el hilo del servidor y sigue hacia abajo el porcentaje más grande. Buscas la rama por la que se va el tiempo:

• El tick de entidades, a menudo con la IA de los mobs o la búsqueda de rutas de los aldeanos debajo, apunta a los mobs (siguiente sección).
• Las entidades de bloque, con las tolvas arriba en la lista, apuntan a cadenas de tolvas y sistemas de almacenamiento.
• El trabajo de chunks (generar, cargar, guardar) apunta a jugadores que exploran terreno nuevo.
• El nombre de un plugin en el árbol de llamadas, o arriba en el desglose por plugin del visor, apunta a ese plugin. Anota qué estaba haciendo (un manejador de eventos, una tarea programada, una llamada a la base de datos) antes de culparlo, porque el mismo plugin puede ir bien con otro ajuste.

Spark también registra la recolección de basura. Las pausas frecuentes de cientos de milisegundos apuntan a presión de memoria, que /spark gc muestra a lo largo del tiempo. Haz también un perfil una vez cuando el servidor va bien, para saber cómo es lo normal en tu configuración.

Los sospechosos habituales (entidades, generación de chunks, redstone, plugins, recolección de basura)

Entidades

Las granjas de mobs, las salas de comercio con aldeanos, los montones de objetos tirados, los sistemas de vagonetas y las decoraciones con soportes para armadura hacen tick. En Paper, /paper entity list muestra las entidades que hacen tick por tipo, y un filtro como /paper entity list minecraft:villager lo acota para que encuentres dónde se acumulan. /paper mobcaps muestra lo llenos que están los límites de mobs, y /paper chunkinfo cuántos chunks están cargados y haciendo tick. Los arreglos son límites, no prohibiciones: un tope de entidades por chunk, normas de granjas con las que tus jugadores estén de acuerdo y una charla con quien construyó la sala de 400 aldeanos.

Generación de chunks

Generar un chunk nuevo es una de las cosas más costosas que hace un servidor, y los jugadores con élitros pueden exigir decenas por minuto. Pregenera el mundo una vez, con un plugin como Chunky (/chunky radius 5000, luego /chunky start), durante las horas tranquilas, y pon un borde del mundo que coincida con /worldborder set 10000. El borde toma un diámetro y el radio de Chunky es la mitad, así que esos dos números describen el mismo cuadrado. Después, explorar solo carga chunks del disco, que es mucho más barato.

Redstone y tolvas

Los relojes de redstone rápidos y las cadenas largas de tolvas se acumulan. Paper ofrece dos palancas en config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT cambia a una implementación más rápida del polvo de redstone. hopper.disable-move-event: true abarata las tolvas, pero rompe los plugins que dependen de ese evento, como algunos plugins de protección y de filtros de tolvas, así que prueba primero. hopper.cooldown-when-full ya viene activado por defecto.

Plugins

Un plugin pesado aparece por su nombre en el perfil. Los patrones habituales son marcadores, hologramas o listas de jugadores que se reconstruyen en cada tick, peticiones a bases de datos o a la web hechas en el hilo principal, renderizadores de mapas que recorren un mundo grande y comprobaciones de anticheat bajo carga. El arreglo suele ser primero la configuración (intervalos de actualización, límites de renderizado), luego una actualización y por último un reemplazo.

Recolección de basura

Si spark muestra pausas de recolección largas o frecuentes, revisa la memoria antes que nada: ¿es -Xmx demasiado pequeño para el mundo y los plugins, y tiene -Xms el mismo valor? Las flags recomendadas por PaperMC son un buen punto de partida. Más memoria solo ayuda cuando el problema es la recolección, y en un hosting compartido, asignarla toda deja sin recursos al sistema operativo.

Arreglos que funcionan

Cuando conoces la causa, estos son los cambios que suelen compensar, más o menos en el orden en que los probaríamos:

El cambio de simulation-distance es mayor de lo que parece. Alrededor de cada jugador, el servidor hace tick de más o menos un cuadrado de chunks, así que pasar de 10 a 6 lo reduce de unos 21 por 21 chunks a 13 por 13, de unos 441 chunks a unos 169, mientras los jugadores siguen viendo tan lejos como permita view-distance.

Algunos consejos populares no ayudan. Los plugins que borran todos los objetos tirados cada pocos minutos tratan un síntoma y molestan a los jugadores. Los plugins de "optimización" que prometen más TPS sin decir qué cambian merecen un perfil antes y otro después. Y reiniciar cada dos horas esconde los problemas en lugar de encontrarlos.

El lag de red visto desde fuera

Hay un detalle que sorprende a muchos dueños. El ping de estado que usan las listas de servidores lo responden los hilos de red del servidor, no el bucle de ticks, así que un servidor puede ir con mucho lag en el juego y aun así responder a nuestro pinger en unos pocos milisegundos. No podemos ver el lag de tick desde fuera, y por eso existe spark. Detrás de Velocity, el pinger solo habla con el proxy.

Lo que sí ve nuestro pinger es la red. La página pública de estadísticas de tu ficha (/server/your-server/stats) muestra tres cosas que merece la pena leer:

• El tiempo de respuesta, lo que tardó el servidor en responder a nuestro pinger, con su mediana, su rango habitual y una gráfica. El nivel lo marca sobre todo la distancia a nuestro pinger, en Europa occidental, así que un servidor en Estados Unidos no mostrará allí 10 ms salvo que una red de protección responda desde un nodo cercano. Fíjate en su forma a lo largo del tiempo, no en su valor.
• Los picos por encima del rango habitual. Si las respuestas suben mucho por encima del rango habitual solo en tus horas concurridas, la máquina o su enlace de red se satura a esas horas. Si el rango es amplio a todas horas, sospecha de la ruta o de la red del hosting.
• El registro de caídas. Los cortes breves son reinicios o fallos. Los largos merecen una mirada a la página de estado de tu hosting y a tus informes de fallos.

Desde el lado del jugador, pide a los afectados un traceroute hacia tu dirección (tracert en Windows, traceroute en macOS y Linux) y su región. Si todos los de un país tienen lag y nadie más, es la ruta, y mudarte o añadir una red de protección con un nodo cercano puede ayudar más que cualquier ajuste. Los jugadores que no consiguen conectar en absoluto tienen otros problemas, que cubre nuestra guía de errores de conexión.

Cuándo reiniciar y cuándo no

Los reinicios no son gratis. Se expulsa a todos los que están conectados, y un jugador al que echan en plena pelea un domingo por la tarde se acuerda. Nuestros datos de caídas muestran cómo los programan los dueños en la práctica.

En los 30 días hasta el 16 de octubre de 2026, 90 fichas de nuestra lista fueron jugables al menos el 90 % del tiempo. 58 de ellas tuvieron al menos una caída, que contamos como tres o más pings seguidos sin respuesta jugable, y entre todas sumaron 515. Medidas desde el primer ping fallido hasta el último, la mitad de las caídas terminaron en menos de cinco minutos, y el 10 % más largo superó las dos horas. 375 de las 515 (73 %) duraron 15 minutos o menos, lo que dura un reinicio o un fallo con reinicio.

¿Cuándo empezaron esas caídas breves? Una hora destaca: las 04:00 UTC, con 39 de las 375, la forma típica de los reinicios nocturnos programados. Fuera de esa hora se reparten de forma bastante uniforme a lo largo del día. 64 de las 375 (17 %) empezaron entre las 14:00 y las 18:00 UTC, las cuatro horas más concurridas de nuestra lista, que es más o menos la proporción que cabría esperar si las horas de reinicio se eligieran al azar.

19 %Caídas breves que empezaron en las cuatro horas más concurridas de toda la lista, últimos 30 días

Medido el 19 oct 2026, 21:52 UTCCómo medimos

En directo, para los últimos 30 días: 472 caídas en 83 fichas con un uptime del 90 % o más, con una mediana de 5 minutos minutos y 70 % de ellas de 15 minutos o menos. La hora de inicio más común de las breves es 04:00 UTC en tu zona horaria, y la hora más tranquila de toda la lista es 01:00 UTC.

Qué sacar de todo esto:

1. Reinicia en tu propia hora tranquila, no a una hora en punto. El mapa de calor de tu página de estadísticas la muestra, y cuándo están más concurridos los servidores enseña cómo cambia según la región. Si tus jugadores están repartidos por varias zonas horarias, elige el punto más bajo de tu curva, no la medianoche.
2. Avísalo con una cuenta atrás en el chat, y que sea corta.
3. Reinicia por un motivo. Actualizaciones, una fuga de memoria que estás siguiendo, un cambio de configuración que lo necesita. Un reinicio diario que no arregla nada sigue costando una expulsión diaria.
4. Encuentra la fuga en lugar de esconderla. Si la memoria sube hasta que reinicias, /spark heapsummary muestra qué la está llenando.

Los reinicios no arreglan el lag de tick. Una granja que cuesta 30 ms por tick sigue costando 30 ms por tick cinco minutos después de reiniciar. Nuestro informe de uptime tiene todas las cifras de caídas de la lista.

Cuándo mejorar el hardware

Mejora el hardware cuando el perfil lo diga. Las señales:

• Los MSPT en la hora pico se quedan por encima de unos 40 ms después de ocuparte de los sospechosos de arriba.
• El perfil muestra el tiempo repartido en trabajo normal de vanilla (entidades, chunks, actualizaciones de bloques) sin ningún culpable claro.
• En un VPS, top muestra el CPU steal (el valor st) subiendo en las horas concurridas, lo que significa que tus vecinos usan núcleos que pagas tú.

Entonces compra primero velocidad por núcleo, porque el bucle de ticks corre en un solo núcleo. Más RAM solo arregla problemas de memoria. Más allá de eso, la respuesta es repartir la carga: varios servidores detrás de un proxy Velocity, o Folia para un mundo muy grande, dos opciones que cubre nuestra guía de software de servidor. Elegir hosting recoge las preguntas que conviene hacer antes de pagar la máquina nueva.