El servidor de Minecraft va con lag: encontrar las causas y solucionarlo

"El servidor va con lag" es el mensaje más frecuente en el sistema de tickets de cualquier operador de servidores de juego y, a la vez, el más inútil. Detrás de esa única frase se esconden al menos tres problemas técnicos completamente distintos, que no tienen nada que ver entre sí y que se solucionan con medios completamente distintos. Quien adivina en lugar de medir se pasa semanas ajustando view-distance y flags de Java, mientras que la causa real es una cadena de hoppers rota en el sótano de un jugador.

Este artículo recorre el camino en el orden en el que funciona: primero la distinción, después la medición, después la causa y después la contramedida. Y al final, la pregunta que la mayoría de las guías se saltan: cómo reconoces que el problema está realmente resuelto.

Dos síntomas que se perciben igual

Hay dos tipos de tirones radicalmente distintos, más un tercer caso que no tiene nada que ver con el servidor.

El lag del servidor significa que el servidor ya no consigue completar sus 20 pasos de cálculo por segundo. El mundo en sí funciona más despacio. Los mobs se quedan quietos o dan tirones, los hornos tardan más, los bloques picados vuelven a aparecer, los soportes de armadura flotan con retraso.

El lag de red significa que el servidor calcula sin problemas, pero los paquetes entre el jugador y el servidor tardan demasiado o se pierden. Al jugador lo tira hacia atrás mientras corre (rubberbanding), los golpes no impactan, el chat llega con retraso, pero los mobs del entorno se mueven con total fluidez.

El lag del cliente es el tercer caso: pocos fotogramas por segundo en el equipo del jugador, casi siempre por shaders, por una distancia de visión alta en el cliente o por poca RAM asignada. Eso es invisible desde el servidor y tampoco se puede arreglar allí.

La regla que casi siempre acierta: si afecta a todos a la vez, es el servidor. Si afecta solo a algunos, es la conexión. Un caso especial rompe esa regla: un servidor completamente sobrecargado también confirma los paquetes de red demasiado tarde y genera entonces pings elevados de forma añadida. Por eso se miden siempre las dos cosas.

La primera prueba dura 60 segundos

Conéctate por SSH al servidor y abre la consola del servidor. Si todavía no tienes el servicio corriendo de forma limpia en segundo plano, te ayudará el artículo sobre iniciar un servidor de Minecraft automáticamente.

En Paper, Purpur y Folia a partir de 1.21, el profiler Spark ya viene incluido en el servidor y no hace falta instalar nada. Dentro del juego o en la consola:

spark tps
spark health --memory --network

La salida de spark tps muestra cuatro ventanas temporales (5 segundos, 1, 5 y 15 minutos) y las duraciones de tick como mínimo, mediana, percentil 95 y máximo.

En Vanilla puro, sin plugins, existe /tick query. El comando devuelve la tasa objetivo y el tiempo medio de tick. Además, F3 más 2 muestra a los operadores un gráfico de ticks.

La consola suele delatar el problema por sí sola. Estas son las líneas que los lectores buscan normalmente de forma literal:

[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2123ms or 42 ticks behind
[Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2340ms behind

Ese mensaje significa simplemente esto: el servidor ha necesitado bastante más de los 50 milisegundos permitidos para un paso de cálculo y tiene que saltarse ticks. Un aviso aislado tras un reinicio o una generación de mundo es normal. Uno cada pocos minutos sí es un problema real.

En paralelo conviene revisar la parte del sistema. mpstat no forma parte del equipamiento básico en ninguno de los sistemas revisados: viene del paquete sysstat y hay que instalarlo una vez:

apt-get install -y sysstat procps
uptime
free -h
mpstat 1 3

En AlmaLinux, Rocky Linux y Oracle Linux la primera línea es dnf -y install sysstat procps-ng iproute; allí, el paquete que contiene free, uptime, top y vmstat no se llama procps, sino procps-ng.

En la salida de mpstat interesa sobre todo la columna %steal. Valores por encima del 5 por ciento de forma sostenida significan que la máquina virtual está esperando tiempo de CPU que ocupa otro huésped. Eso ya no es un problema de Minecraft, sino un problema de capacidad del hardware subyacente.

Una salvedad sobre estos tres comandos: en un servidor propio o en un VPS muestran exactamente lo que quieres saber. En cambio, si tu servidor corre en un container, por ejemplo en un panel de juego como Pterodactyl, free, uptime, vmstat y mpstat informan de los valores del sistema anfitrión y no de los de tu instancia. Verás entonces carga ajena y memoria ajena. En ese caso, fíate de lo que muestra el panel y de spark health.

Leer correctamente TPS y MSPT

Un servidor de Minecraft calcula 20 ticks por segundo, así que cada tick dispone de un presupuesto de 50 milisegundos. MSPT (milisegundos por tick) es el valor más revelador, porque muestra los problemas antes incluso de que los TPS lleguen a caer. Un servidor con 20,0 TPS y 46 ms de MSPT funciona al límite absoluto y se viene abajo en cuanto el siguiente jugador entra en una zona nueva.

• MSPT por debajo de 30 ms: sano, hay margen.
• MSPT de 30 a 45 ms: justo, pero jugable. Es el momento de actuar.
• MSPT por encima de 50 ms: los TPS caen de forma inevitable y los jugadores lo notan.

Más importante que la media es la distribución. Una mediana de 18 ms con un máximo de 900 ms significa picos: eventos caros y puntuales, como el guardado automático, la generación de chunks o la tarea de un plugin que se ejecuta cada minuto. Una mediana de 60 ms, en cambio, significa carga permanente, es decir, demasiado contenido en tick para la potencia de cálculo disponible. Las contramedidas son completamente distintas.

Un punto que los asesores de hardware suelen pasar por alto: el tick principal de Minecraft corre en un único hilo. La carga de chunks y la red están externalizadas, pero la simulación del mundo propiamente dicha no lo está. Un servidor con 32 núcleos y poca potencia por núcleo es más lento para Minecraft que uno con 8 núcleos rápidos. Los núcleos adicionales solo ayudan cuando se ejecutan varias instancias de servidor sobre ellos.

Spark: de la sospecha a la prueba

Timings, la herramienta estándar durante años, está puesto en modo inactivo en Paper desde la serie 1.21 y ya no entrega datos aprovechables. Quien hoy sigue publicando enlaces de Timings no está midiendo nada. El sucesor se llama Spark y viene integrado en Paper; para Fabric, Forge y NeoForge existe como mod, y para Velocity y BungeeCord como variante propia.

El procedimiento decisivo: perfila mientras el problema está ocurriendo. Un perfil del servidor vacío a las tres de la madrugada no vale nada.

spark profiler start --timeout 300
spark profiler stop

Para los picos que solo aparecen de vez en cuando, se filtran de forma selectiva los ticks malos:

spark profiler start --only-ticks-over 60 --timeout 600

Así solo se registran los ticks que han durado más de 60 milisegundos. Son exactamente los que notan los jugadores. El resto se ignora y no mete ruido en la imagen.

Al leer el diagrama de llamas, los principiantes cometen casi siempre el mismo error: miran la ramificación más profunda. Lo correcto es fijarse en la anchura de las barras situadas justo debajo del tick del servidor. Una entrada con un 3 por ciento es irrelevante, aunque baje cien niveles. Regla práctica: un único plugin con más del 15 por ciento de la duración del tick es un candidato. Las entradas muy anchas alrededor de las entidades de bloque apuntan a redstone y hoppers; las entradas anchas alrededor de la carga de chunks apuntan a la generación de mundo.

Un aviso sobre confidencialidad: el informe subido es accesible públicamente a través de su enlace y contiene información del sistema, rutas, parámetros de arranque y la lista completa de plugins. Comparte el enlace solo con personas a las que confiarías esa información. Con --save-to-file el perfil se queda en local.

Los culpables habituales

Redstone y granjas

Los hoppers son, con diferencia, los bloques más caros del juego, porque cada uno comprueba en cada tick si hay algo encima. Un sistema de clasificación con 400 hoppers cuesta más tiempo de cálculo que cien mobs. A eso se suman los relojes de observers, que siguen funcionando aunque no haya nadie cerca, siempre que el chunk esté simulado. Si Spark pasa una cantidad llamativa de tiempo en entidades de bloque, busca exactamente ese tipo de instalaciones.

Entidades

En Paper, /paper entity list lista las entidades por mundo y por tipo, junto con las coordenadas de chunk. Es el camino más rápido hasta la zona problemática. Hallazgos típicos: varios miles de pilas de ítems en una granja de mobs, un establo de cría con 300 vacas, una zona olvidada llena de flechas disparadas.

Contramedidas razonables en spigot.yml: bajar el entity-activation-range para animales y monstruos (por ejemplo los animales de 32 a 16 y los monstruos de 32 a 24) y subir ligeramente el merge-radius para ítems y esferas de experiencia, de modo que existan menos objetos sueltos. En paper-world-defaults.yml, entity-per-chunk-save-limit limita cuántos objetos de un mismo tipo llegan a guardarse por chunk.

Carga de chunks

Un jugador con élitros o sobre un caballo rápido obliga al servidor a generar terreno nuevo de forma permanente. La generación de mundo es la operación individual más cara que existe. Lo mismo ocurre la primera vez que se entra al Nether o después de ampliar el worldborder. La solución no es un valor de configuración, sino la pregeneración, y es lo bastante importante como para tener su propio apartado más abajo.

Plugins

Si Spark señala un plugin, el asunto está claro. Si no lo hace, solo queda la búsqueda por bisección: desactivar la mitad de los plugins, medir y, según el resultado, seguir partiendo por la mitad el grupo cargado. Con 32 plugins son cinco reinicios en lugar de 32. Antes, un backup obligatorio, porque los plugins que escriben datos del mundo pueden dejar contenidos que, sin ellos, ya no funcionan.

Pregenerar los chunks antes de que los jugadores pasen por allí

Es la medida individual más eficaz de todo este artículo y la que más se pasa por alto. El motivo está en cómo trabaja Minecraft: cargar del disco un chunk ya generado no cuesta casi nada. Generar un chunk nuevo, en cambio, significa mapa de alturas, biomas, distribución de minerales, cuevas, estructuras y cálculo de luz, y buena parte de eso corre en el hilo principal. Justo donde también tienen que producirse los 20 ticks por segundo.

Por eso los tirones aparecen normalmente cuando alguien sale volando con élitros o construye una vía de tren hacia la nada: el servidor genera mundo mientras al mismo tiempo tiene que calcular la partida. Quien genera el mundo una sola vez por adelantado hasta el borde del mundo convierte trabajo de cálculo caro en lecturas baratas de disco.

Chunky, la herramienta indicada

Chunky es el pregenerador habitual hoy en día y funciona como plugin en Paper, Spigot y Purpur, y como mod en Fabric y Forge. El procedimiento es el mismo en todas las plataformas:

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start

El radio se indica en bloques y debería encajar con el borde del mundo. Chunky informa por sí solo del progreso y del tiempo restante estimado; con /chunky pause y /chunky continue puedes detener y reanudar el proceso en cualquier momento, incluso a través de un reinicio.

El Nether y el End son mundos propios y hay que pregenerarlos por separado. En Paper y Spigot se llaman así por defecto:

/chunky world world_nether
/chunky radius 1000
/chunky start

Para el Nether basta con un radio menor, porque allí un bloque equivale a ocho bloques del mundo superior. Un radio de 1000 en el Nether cubre por tanto 8000 bloques del mundo superior.

Con qué tienes que contar

• Tiempo. Un radio de 5000 bloques son unos 78 millones de bloques de superficie. Según el hardware, el modpack y el generador de mundo, eso tarda desde una hora hasta varios días. Los modpacks con generadores de mundo propios son bastante más lentos que Vanilla.
• Espacio de almacenamiento. Un mundo pregenerado ocupa varios gigabytes enseguida. Comprueba antes cuánto queda libre; si no, el disco se llena durante el proceso, y eso golpea al servidor más fuerte que cualquier tirón. Cómo comprobarlo y cómo limpiarlo lo tienes en Disco lleno: encontrar y liberar espacio.
• Momento. Pregenera con el servidor vacío, no en pleno funcionamiento. Durante el proceso la tasa de ticks será mala, como cabe esperar, y eso no es un fallo. El sentido de todo esto es precisamente sacar esa carga del tiempo de juego.
• Fijar el borde del mundo. Sin borde, tarde o temprano alguien saldrá de la zona pregenerada y todo empezará de nuevo. Pon el borde en el mismo radio que hayas pregenerado.

Limpiar a posteriori

Si el mundo ya ha crecido y contiene zonas a las que ya no va nadie, Chunky elimina los chunks que quedan fuera del borde del mundo:

/chunky trim

Eso reduce el mundo de forma notable y, con él, también los backups. Haz antes un backup sin falta, porque los chunks borrados se vuelven a generar la próxima vez que alguien entre, y todo lo que los jugadores hubieran construido allí se pierde.

Cuando Chunky no es una opción

En servidores más antiguos todavía se encuentra a menudo WorldBorder con /wb fill. Cumple el mismo objetivo, pero el proyecto apenas se mantiene desde hace años, y para las versiones de servidor actuales Chunky es la opción más fiable. En ambos casos, comprueba antes de instalar si la versión ofrecida encaja realmente con la versión de tu servidor.

view-distance y simulation-distance

Estos dos valores de server.properties se confunden constantemente.

• view-distance determina hasta qué distancia se envían los chunks al cliente. Cuesta ancho de banda y algo de memoria.
• simulation-distance determina hasta qué distancia el servidor calcula entidades, redstone y actualizaciones de bloques. Cuesta tiempo de CPU en el tick principal.

Los chunks situados entre el límite de simulación y el de visión se muestran, pero están congelados en el lado del servidor. Los costes crecen de forma cuadrática: con view-distance=10 son 21 por 21, es decir, 441 chunks por jugador.

Valores de partida contrastados para una red survival con 10 a 30 jugadores:

view-distance=8
simulation-distance=5

Si encuentras guías que todavía usan no-tick-view-distance: esa opción de Paper está obsoleta. Mojang introdujo simulation-distance con la 1.18 y resolvió oficialmente el mismo problema. Quien hoy fija el valor antiguo no consigue nada.

El precio de los valores bajos se menciona pocas veces: con simulation-distance por debajo de 4, las granjas AFK dejan de funcionar, los spawns de mobs se comportan de otra manera, los hornos del chunk vecino no siguen trabajando y los relojes de redstone se paran. Quien tiene una comunidad muy centrada en las granjas está ahorrando en el sitio equivocado y cambia un problema técnico por un problema con los jugadores. Ve de uno en uno y mide después de cada paso.

Limpiar sin destruir el mundo

Cualquier intervención sobre los datos del mundo empieza con un backup y con el servidor parado. Sin compromisos, sin excepciones:

tar -czf backup-mundo.tar.gz world world_nether world_the_end

Después merece la pena mirar el tamaño de los datos de región:

du -sh world/region

Los mundos que han crecido durante años contienen a menudo cientos de megabytes de terreno que un único jugador sobrevoló una vez. Esos chunks no cuestan tiempo de tick, pero sí espacio en disco, y alargan cada guardado. Si el espacio escasea, ayuda además el artículo Liberar espacio en un disco lleno bajo Linux.

Los picos regulares del orden de segundos, que aparecen exactamente cada cinco minutos, son casi siempre el guardado automático. En bukkit.yml, ticks-per.autosave controla el intervalo; en paper-world-defaults.yml, max-auto-save-chunks-per-tick limita cuánto se escribe por tick. Un valor más pequeño reparte la carga en lugar de concentrarla.

Para servidores privados pequeños existe, desde la serie 1.21, la opción pause-when-empty-seconds en server.properties. Si allí hay un valor mayor que cero, el servidor deja de ticar el mundo pasado ese tiempo sin jugadores. En un servidor root compartido eso ahorra un tiempo de cálculo apreciable.

Cuando la JVM frena

Si el tiempo de tick se mantiene bajo de media, pero salta de forma irregular a varios cientos de milisegundos, la culpa suele ser de la recolección de basura del entorno de ejecución de Java. Se puede comprobar directamente:

spark gcmonitor
spark heapsummary

Dos errores muy extendidos: más heap no es automáticamente mejor, porque los heaps grandes generan pausas más largas durante la recolección. Y el heap nunca debe elegirse tan grande como para empujar al sistema operativo a usar swap. Un servidor de Minecraft que hace swap es irremediablemente lento. Compruébalo con vmstat 1 5: unos valores permanentes en las columnas si y so son la sentencia de muerte. Tienes el trasfondo en el artículo Configurar swap y evitar el Out of Memory.

Este mensaje es un síntoma, no una causa:

java.lang.OutOfMemoryError: Java heap space

Aumentar el heap solo retrasa la caída si un plugin tiene una fuga de memoria o si existen millones de entidades.

En cuanto a la versión de Java, las distribuciones se diferencian bastante, y ahí es exactamente donde fracasan muchas instalaciones. A partir de Minecraft 1.20.5 se requiere Java 21. Debian 12 solo entrega OpenJDK 17 en el repositorio estándar, y no OpenJDK 21; Debian 13 entrega 21 y 25, pero no 17. Ubuntu 22.04 y 24.04 tienen 17 y 21 en el repositorio. Quien tenga que quedarse en Debian 12 instala Temurin desde el repositorio de Adoptium. Los pasos están en Instalar Java 21 en Debian y, para versiones de servidor más antiguas, en Instalar Java 17 en Debian.

No recurras al cómodo paquete colectivo default-jre-headless. Según la release apunta a una versión completamente distinta: Debian 13 y Ubuntu 24.04 entregan con él Java 21, Debian 12 entrega Java 17, y Debian 11 y Ubuntu 22.04 entregan Java 11. La instalación termina sin errores en todos los casos, pero en los dos últimos el servidor no arranca igualmente. Por eso, indica la versión de forma expresa, es decir, openjdk-21-jre-headless.

java -version
java -XX:+PrintFlagsFinal -version 2>/dev/null | grep -w MaxHeapSize

El 2>/dev/null suprime el banner de versión que la JVM escribe en la salida de error y que, si no, aparecería en medio de la salida. Y grep -w MaxHeapSize devuelve exactamente una línea, mientras que la búsqueda difusa encuentra además SoftMaxHeapSize.

Cuando algo sale mal y cómo volver atrás

El servidor se cae con un error del watchdog. En el log aparece entonces, en esencia, que un único tick ha durado 60 segundos y que el servidor se considera caído. Eso no es un fallo de funcionamiento, sino una medida de protección frente a un proceso colgado de forma permanente. El stacktrace adjunto vale oro: muestra exactamente en qué se había quedado atascado el servidor. El valor max-tick-time en server.properties controla ese umbral. Desactivarlo no arregla nada, solo convierte la caída en un servidor congelado de forma permanente.

Después de un cambio de configuración va peor. Precisamente por eso vale la regla más importante de esta búsqueda de fallos: un solo cambio por medición, y anota el valor de partida. Quien toca a la vez view-distance, los rangos de entidades y los flags de Java no sabrá después qué es lo que ha hecho efecto.

El servidor ya no arranca después de la caída. Casi siempre está dañado el level.dat. En la carpeta del mundo hay un level.dat_old que puedes copiar encima, después de guardar una copia del estado roto. Con archivos de región dañados solo ayuda el backup.

Todo está optimizado y sigue habiendo tirones. Entonces revisa la capa de abajo: %steal en mpstat, el uso de swap en vmstat y la latencia del disco. Si el tiempo de tick sigue alto aunque Spark no muestre ningún culpable individual por encima del 10 por ciento, sencillamente hay demasiado contenido para muy poca potencia por núcleo. Entonces ayuda repartir en varias instancias o poner más potencia de cálculo, no el siguiente ajuste de configuración.

Solo los jugadores tienen pings altos y el servidor está tranquilo. Entonces la causa está en la red. Una ubicación con rutas cortas hasta los jugadores marca aquí la mayor diferencia. Para servidores en Frankfurt am Main (Alemania), las latencias típicas desde Europa Central están en la franja baja de dos cifras. Si las caídas aparecen de repente y de forma agrupada, detrás puede haber también un ataque, mira Proteger el servidor frente a ataques DDoS. En el lado del cliente aparecen entonces mensajes de este tipo:

Internal Exception: io.netty.handler.timeout.ReadTimeoutException
Timed out
Connection reset

Cómo reconoces que está realmente resuelto

Una solución solo se da por confirmada cuando aguanta exactamente bajo la carga con la que apareció el problema. De noche, con dos jugadores, hasta un servidor roto funciona fino. Comprueba en hora punta:

• spark tps muestra 20,0 en la ventana de 15 minutos y no solo en la de 5 segundos.
• El percentil 95 del tiempo de tick queda por debajo de 40 ms y el máximo por debajo de 100 ms.
• 24 horas de log sin una sola línea "Can't keep up!".
• Un perfil nuevo de Spark ya no muestra ninguna partida individual por encima del 15 por ciento.
• spark gcmonitor no informa de pausas por encima de 200 ms.
• Los jugadores que habían avisado confirman la mejora en el mismo sitio y en la misma situación de juego.

Anota los valores de antes y de después, idealmente con la fecha y con el cambio realizado en cada caso. En la próxima caída, dentro de tres meses, esa lista valdrá más que cualquier guía, porque muestra qué ha funcionado ya alguna vez en tu servidor concreto. Si vas a montar el servidor de cero, encontrarás las bases adecuadas en Instalar un servidor de Minecraft en Debian y en la Lista de comprobación para un servidor root nuevo.