Por qué va lento tu servidor de Minecraft y cómo arreglarlo

Si tu servidor de Minecraft va a tirones, tarda en cargar bloques o expulsa jugadores por timeout, no empieces aumentando la RAM. Primero averigua qué está retrasando cada tick. La mayoría de los problemas de rendimiento se pueden localizar midiendo MSPT, capturando un perfil con spark y comprobando las causas en un orden lógico.

Esta guía está orientada a servidores Java, especialmente Paper, Purpur y derivados. Los nombres exactos de algunos ajustes pueden variar según la versión, pero el método de diagnóstico es el mismo: medir, formular una hipótesis, cambiar una variable y volver a medir.

TPS y MSPT: qué significan realmente

Minecraft intenta ejecutar 20 ticks por segundo. Cada tick actualiza entidades, cultivos, redstone, chunks, inteligencia artificial, plugins y otros elementos del mundo. Para mantener 20 TPS, el servidor dispone de un máximo de 50 milisegundos por tick.

Los TPS muestran el resultado final, mientras que los MSPT enseñan cuánto margen queda. Por eso MSPT es la métrica más útil. Un servidor puede indicar 20 TPS tanto a 8 MSPT como a 48 MSPT, pero el segundo está al límite: cualquier granja que se active o cualquier grupo de jugadores que explore puede hacer que caiga.

Como referencia práctica, un valor estable muy por debajo de 50 MSPT es saludable. Los picos ocasionales pueden coincidir con guardados o generación de terreno. Lo preocupante es mantener valores cercanos o superiores a 50 ms, o sufrir picos repetidos que coincidan con el problema observado por los jugadores.

Cómo medir el rendimiento con spark

spark es una herramienta de diagnóstico para servidores Minecraft. Paper suele incluirla en versiones actuales; en otras plataformas puede instalarse como plugin o mod compatible. Comprueba primero que el comando está disponible:

/spark help

Empieza con un informe general:

/spark healthreport

Este informe permite revisar TPS, MSPT, uso de CPU, memoria y datos del entorno. La memoria libre, por sí sola, no identifica la causa del lag. Presta especial atención a los MSPT y a si el procesador está dedicando demasiado tiempo al hilo principal.

Después inicia el perfilador mientras el problema está ocurriendo:

/spark profiler start --timeout 60

Durante ese minuto reproduce la situación real: mantén conectados a los jugadores, activa la granja sospechosa o desplázate por la zona donde aparecen los tirones. Si necesitas detener la captura antes:

/spark profiler stop

spark devolverá un enlace al informe. Ábrelo y busca qué tareas consumen más tiempo en el hilo principal. Expande las ramas más costosas hasta encontrar nombres reconocibles: tipos de entidad, ticks de chunks, redstone, generación de terreno o clases pertenecientes a un plugin.

Una captura realizada con el servidor vacío no explica un problema que solo aparece con veinte granjas activas. Del mismo modo, un perfil de varios minutos mezclando exploración, reinicios y pruebas distintas resulta más difícil de interpretar. Haz capturas cortas y representativas, y anota qué sucedía durante cada una.

Causas reales del lag, ordenadas por frecuencia

1. Entidades acumuladas

Animales, aldeanos, monstruos, objetos tirados, vagonetas y marcos se actualizan periódicamente. Un número excesivo en pocos chunks puede consumir una parte importante del tick, especialmente si las entidades tienen inteligencia artificial, colisiones o búsqueda de caminos.

Busca almacenes de aldeanos, corrales densos, zonas con objetos que no se recogen y granjas cuyo sistema de eliminación se haya atascado. En el perfil de spark pueden aparecer funciones relacionadas con entidades concretas o con su comportamiento. No elimines todas las entidades como primera medida: identifica el tipo y la ubicación para corregir el mecanismo que las acumula.

2. Granjas mal dimensionadas o atascadas

Una granja puede combinar generación de criaturas, corrientes de agua, tolvas, vagonetas, objetos y redstone. Aunque cada componente parezca pequeño, el conjunto puede ser caro si permanece activo constantemente.

Comprueba si la granja sigue produciendo cuando el almacenamiento está lleno, si los objetos se acumulan o si demasiadas tolvas revisan inventarios en cada tick. Instala interruptores de apagado y sistemas que detengan la producción cuando no quede espacio. Prueba la misma captura con la granja encendida y apagada, sin modificar nada más.

3. Demasiados chunks cargados

Cada jugador mantiene chunks activos a su alrededor. También pueden permanecer cargados por portales, cargadores de chunks, plugins o mods. Cuantos más chunks se simulen, más bloques, entidades y tareas tendrá que actualizar el servidor.

El problema suele crecer cuando los jugadores están muy separados, porque sus áreas cargadas apenas se solapan. Revisa también mundos secundarios que nadie utiliza y cargadores permanentes. Limitar chunks activos innecesarios suele ser más efectivo que reducir funciones al azar.

4. Redstone excesiva

Relojes rápidos, observadores, pistones, polvo de redstone y actualizaciones de bloques pueden generar cadenas de trabajo continuas. Los diseños que funcionan bien en una partida pequeña no siempre escalan en un servidor con muchas construcciones activas.

Localiza relojes sin interruptor y mecanismos que continúan funcionando aunque no haya jugadores utilizándolos. Apágalos temporalmente y repite la medición. Si los MSPT bajan, rediseña el circuito para que se active bajo demanda o trabaje en lotes.

5. Plugins pesados o mal configurados

Un plugin puede ejecutar tareas demasiado frecuentes, recorrer grandes cantidades de bloques, consultar una base de datos en el hilo principal o reaccionar a cada movimiento de los jugadores. spark suele mostrar el nombre del plugin o de sus clases dentro de las ramas costosas.

No concluyas que un plugin es culpable solo porque aparece en el informe: casi todos aparecerán si realizan algún trabajo. Examina su porcentaje de tiempo, las llamadas concretas y si el coste coincide con los picos. Actualízalo, revisa su configuración y prueba a desactivarlo en una copia del servidor. Evita retirarlo directamente del entorno de producción si almacena datos o modifica mundos.

6. Distancia de simulación demasiado alta

La distancia de visión controla cuántos chunks se envían al jugador; la distancia de simulación determina hasta dónde se actualizan activamente entidades y bloques. Esta segunda suele tener un impacto directo mayor sobre los MSPT.

En server.properties puedes probar un valor inferior:

simulation-distance=6
view-distance=8

No son valores universales. Úsalos como punto de prueba, reinicia cuando corresponda y compara los MSPT en una situación equivalente. Si reduces ambas distancias a la vez, no sabrás cuál produjo la mejora.

7. Disco lento o saturado

La carga y el guardado de chunks dependen del almacenamiento. Un disco lento, lleno o ocupado por copias de seguridad puede provocar pausas al explorar, guardar mundos o iniciar el servidor. Esto resulta especialmente visible cuando se generan chunks nuevos.

Comprueba el espacio libre, la latencia del disco y si las pausas coinciden con copias o tareas externas. Pregenerar el mundo puede evitar generación durante las horas de juego, aunque requiere espacio y tiempo de procesamiento. El hosting SSD ayuda, pero también debes evitar que varias tareas intensivas compitan por el mismo almacenamiento.

Por qué añadir RAM no suele arreglar el lag

La RAM es necesaria para cargar el servidor, sus mundos y sus plugins, pero no acelera automáticamente el procesamiento de ticks. Si el hilo principal tarda 80 ms por una granja, una acumulación de aldeanos o un plugin, duplicar la memoria no reduce ese trabajo.

Asignar más memoria sí puede ayudar cuando la existente es insuficiente, hay paginación o el recolector de basura trabaja continuamente por falta de espacio. Esa situación debe confirmarse con métricas. También es posible asignar demasiada memoria: no aporta rendimiento por sí misma y puede hacer que ciertas pausas de recolección sean más difíciles de gestionar.

No ajustes simultáneamente RAM, parámetros de Java, distancias y plugins. Si el resultado mejora o empeora, no podrás saber por qué. Mantén una asignación razonable para la carga real y céntrate en aquello que spark muestra como costoso.

Procedimiento para aislar la causa paso a paso

1. Define el síntoma. Anota cuándo ocurre, qué ven los jugadores, cuántos están conectados, en qué mundo se encuentran y si están explorando o usando granjas.
2. Guarda una línea base. Ejecuta el informe de salud y registra TPS, MSPT medios y picos. Hazlo antes de cambiar configuraciones.
3. Captura el problema con spark. Perfila durante unos 60 segundos mientras reproduces exactamente la situación problemática.
4. Elige la rama más costosa. Formula una hipótesis concreta: por ejemplo, “los aldeanos de la zona comercial consumen el tiempo”, no simplemente “hay muchas entidades”.
5. Cambia una sola variable. Apaga una granja, retira temporalmente un plugin en una copia, reduce solo la distancia de simulación o descarga un grupo de chunks.
6. Repite la misma prueba. Mantén un número parecido de jugadores y las mismas acciones. Captura otro perfil con una duración equivalente.
7. Compara los MSPT. Si el coste desaparece o cae claramente, has encontrado una relación útil. Si no cambia, revierte la modificación y prueba la siguiente hipótesis.
8. Aplica una corrección permanente. Rediseña la granja, limita entidades, configura el plugin, reduce chunks activos o corrige el cuello de botella del disco.
9. Verifica bajo carga real. Una mejora con el servidor vacío no es suficiente. Confirma el resultado cuando estén presentes las condiciones habituales.
10. Documenta el resultado. Guarda perfiles, valores anteriores y cambios. Esto evita repetir pruebas y facilita detectar regresiones futuras.

Si el servidor sigue limitado después de optimizar su carga, compara la capacidad del procesador, el almacenamiento y la plataforma. Puedes revisar un servidor de juegos adecuado o valorar infraestructura gestionada. Overclock Host ofrece servidores de juegos desde 2,50 €/mes, hosting SSD, red propia con ASN propio, protección DDoS y soporte 24/7. Para revisar un caso concreto, utiliza el formulario de contacto.

Preguntas frecuentes

¿20 TPS significa que el servidor funciona perfectamente?

No necesariamente. Puede mantener 20 TPS trabajando a 48 MSPT y estar a punto de saturarse. Revisa los MSPT para conocer el margen real y observa sus picos durante la carga habitual.

¿Cuántos MSPT son malos?

Por encima de 50 MSPT el servidor no puede sostener 20 ticks por segundo. Valores cercanos a ese límite también merecen atención, porque dejan muy poco margen ante exploración, granjas o más jugadores.

¿Debo usar timings o spark?

spark ofrece perfiles detallados y una presentación útil para localizar tareas costosas. Si tu plataforma también dispone de timings, puede aportar contexto adicional, pero evita activar varias mediciones pesadas durante periodos prolongados sin necesidad.

¿Reiniciar el servidor arregla el lag?

Puede aliviar temporalmente acumulaciones, fugas o tareas atascadas, pero no corrige la causa. Si el problema reaparece, captura un perfil antes de reiniciar para conservar la evidencia.

¿Cuánta RAM necesita mi servidor de Minecraft?

Depende de la versión, los jugadores, los mundos y los plugins o mods. No existe una cifra válida para todos. Mide el uso real y comprueba si hay presión de memoria; si los MSPT proceden de entidades o plugins, añadir RAM no resolverá ese cuello de botella.