Rendimiento de un servidor Minecraft: TPS, RAM y CPU explicados

El TPS servidor Minecraft es el primer indicador que hay que revisar cuando un mundo empieza a ir a trompicones, con mobs que se teletransportan y cofres que tardan segundos en abrirse. TPS significa "ticks per second" (ticks por segundo) y mide cuántas veces el motor del juego actualiza el mundo cada segundo. Entender este valor es la base para diagnosticar cualquier caída de rendimiento.

Qué es el TPS servidor Minecraft y por qué controla la fluidez

Minecraft, tanto en su versión Java como en las variantes basadas en ese motor (Spigot, Paper, Fabric, Forge), funciona a base de "ticks": cada tick representa una actualización completa del mundo (física de bloques, movimiento de entidades, redstone, generación de terreno, IA de mobs). El objetivo de referencia es de 20 ticks por segundo, es decir, un tick cada 50 milisegundos. Cuando el TPS baja de 20, significa que el motor no consigue procesar todo ese trabajo a tiempo, y el resultado es lag perceptible: saltos de posición, retraso en los golpes, cofres o puertas que no responden al instante.

Un TPS servidor Minecraft estable en 20 no garantiza cero lag para el jugador (eso depende también de la latencia de red), pero un TPS que cae de forma constante por debajo de 15 o 10 es la señal más fiable de que algo en el mundo, en los plugins o en el hardware está saturando el motor. Si administras tu propia instancia y quieres partir con una base sólida en cuanto a CPU y almacenamiento NVMe, puedes consultar la página de alojamiento servidor Minecraft para ver qué recursos dedicados están disponibles antes de escalar un modpack o una comunidad grande.

Factores técnicos que hunden el TPS: núcleo único, RAM y motor del servidor

Antes de tocar cualquier configuración, conviene entender por qué el rendimiento de Minecraft no escala igual que otros juegos de red.

El motor principal trabaja en un solo núcleo

El bucle de ticks de Minecraft (el "main thread") es fundamentalmente mono-núcleo: la lógica de mundo, entidades y redstone se procesa en un único hilo, aunque existan varios núcleos de CPU disponibles. Esto significa que la frecuencia por núcleo (GHz reales) pesa más que el número total de núcleos. Un procesador con pocos núcleos pero alta frecuencia por núcleo, como los Ryzen usados en infraestructuras orientadas a juegos, sostiene el TPS mejor que un procesador con muchos núcleos a baja frecuencia, precisamente porque Minecraft no reparte esa carga principal entre ellos.

Algunos forks como Paper o Purpur descargan parte del trabajo (generación de chunks, algunas tareas de IA) a hilos secundarios, pero el núcleo duro de la simulación sigue siendo lineal. Por eso, cuando el TPS cae en un servidor con CPU libre en otros núcleos, el cuello de botella casi siempre está en ese hilo principal.

La RAM según el motor: no todos consumen igual

La memoria RAM no acelera directamente el TPS, pero su ausencia lo destruye vía "garbage collection" (recolección de basura de Java). Cada motor tiene un comportamiento distinto:

• Vanilla / Spigot: consumo moderado, pero sin optimizaciones de carga de chunks, por lo que grandes mundos exploran mucha RAM en caché de región.
• Paper / Purpull: introduce ajustes de "view-distance" y "entity activation range" que reducen el consumo, ideal cuando hay muchos jugadores conectados.
• Forge / Fabric con mods: el consumo depende directamente del número y peso de los mods; un modpack con generación de mundo compleja o entidades personalizadas puede duplicar la necesidad de RAM frente a un servidor vanilla equivalente.

Cuando la RAM asignada es insuficiente, la JVM lanza recolecciones de basura ("GC pauses") cada vez más largas y frecuentes, lo que se traduce en microcongelaciones que hunden el TPS de forma intermitente, no constante, lo cual las hace más difíciles de detectar a simple vista.

Otros factores que se suman

• Distancia de renderizado (view-distance) y de simulación (simulation-distance) demasiado altas para el número de jugadores.
• Circuitos de redstone complejos o granjas automáticas con muchas entidades acumuladas.
• Chunks cargados sin descargar (chunk leaks) por plugins mal configurados.
• Discos mecánicos o SATA lentos que ralentizan la escritura de regiones y las copias de seguridad.

Cómo diagnosticar caídas de TPS paso a paso

Diagnosticar no es adivinar: es aislar la causa con las herramientas que ya trae el propio motor y el sistema.

Paso 1: consultar el TPS en tiempo real

En Paper, Purpur o Spigot, la consola o un jugador con permisos puede lanzar:

/tps

El resultado muestra el promedio de los últimos 1, 5 y 15 minutos. Si el valor de 1 minuto es notablemente peor que el de 15, la caída es reciente y puntual; si los tres valores están bajos, el problema es estructural.

Paso 2: generar un informe de timings o un perfil con spark

El plugin spark (compatible con Paper, Spigot y Forge) permite identificar qué proceso concreto consume el tiempo de tick:

/spark profiler --timeout 60
/spark profiler stop

El informe generado (accesible vía enlace web) desglosa el consumo por plugin, por mod y por tipo de entidad. En versiones antiguas de Spigot, el comando equivalente es:

/timings report

Puedes consultar la documentación oficial de PaperMC sobre spark para interpretar cada sección del informe.

Paso 3: revisar el consumo real de CPU y RAM en la máquina

Si administras el servidor desde un VPS Linux o desde el panel Pterodactyl, conviene cruzar los datos del juego con los del sistema operativo:

htop
free -h
df -h

htop muestra si el proceso Java satura un solo núcleo (coincide con el diagnóstico de cuello de botella mono-núcleo), free -h confirma si queda RAM libre o si el sistema empieza a usar swap (síntoma grave de falta de memoria), y df -h descarta que el disco esté lleno, lo que también ralentiza el guardado de chunks.

Paso 4: aislar plugins y mods sospechosos

Desactiva temporalmente los plugins o mods añadidos recientemente y observa si el TPS servidor Minecraft se recupera. Un método simple:

plugins/
mv plugins/sospechoso.jar plugins/sospechoso.jar.disabled
systemctl restart minecraft-server

Si el TPS sube de inmediato tras reiniciar sin ese plugin, ya tienes la causa localizada sin necesidad de leer líneas de log durante horas.

Ajustes y prácticas para mantener un TPS servidor Minecraft estable

Una vez identificado el origen, hay ajustes concretos que reducen la carga sobre el hilo principal.

Reducir distancias en server.properties

view-distance=8
simulation-distance=6
max-players=20

Bajar estos valores reduce directamente cuántos chunks y entidades procesa el servidor por tick, sobre todo con muchos jugadores dispersos en el mapa.

Usar flags de JVM adaptadas a Minecraft

Los flags conocidos como "Aikar's flags" ajustan el recolector de basura G1GC para minimizar las pausas largas:

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -jar paper.jar nogui

Asignar -Xms y -Xmx con el mismo valor evita que la JVM redimensione el heap en caliente, lo que también genera microcortes.

Migrar a un motor optimizado

Cambiar de Spigot a Paper o Purpur (compatibles con la mayoría de plugins Bukkit) aporta optimizaciones ya integradas: activación de entidades por rango, límites configurables de IA de mobs y mejor gestión de chunks en segundo plano.

Sauvegardas y mantenimiento regular

Un mundo con años de exploración acumula regiones huérfanas y datos redundantes que ralentizan la carga de chunks. Programar copias de seguridad automáticas antes de cualquier limpieza o actualización de versión evita perder progreso si algo sale mal durante la optimización. Si gestionas varios proyectos, revisar todos nuestros servidores de juegos ayuda a comparar recursos dedicados entre distintos títulos y motores.

Escalar recursos cuando el hardware es el límite real

Si tras optimizar plugins, distancias y flags de JVM el TPS sigue cayendo con la comunidad activa, el límite ya no es de configuración sino de hardware: frecuencia de CPU insuficiente para el hilo principal o RAM por debajo de lo que exige el motor y los mods instalados. En ese punto, migrar a un VPS Pterodactyl con más recursos dedicados es la vía técnica lógica antes de seguir ajustando parámetros que ya están al límite.

Mantener un buen rendimiento pasa por entender que el TPS depende de un hilo principal mono-núcleo, de la RAM adecuada según el motor elegido y de un mantenimiento regular del mundo. Diagnosticar con herramientas como spark o /tps antes de tocar cualquier ajuste evita perder tiempo corrigiendo un síntoma en vez de la causa real.

FAQ

¿Qué valor de TPS se considera normal en Minecraft?

El valor de referencia es 20 TPS constante. Caídas puntuales a 18-19 durante picos de actividad son normales; un promedio sostenido por debajo de 15 indica un problema real que conviene diagnosticar con /tps y spark.

¿Añadir más RAM siempre soluciona una caída de TPS?

No siempre. Más RAM reduce las pausas de garbage collection si el problema es de memoria, pero si el cuello de botella está en el hilo principal por frecuencia de CPU insuficiente, añadir RAM no cambia el resultado. Hay que diagnosticar antes de escalar recursos.

¿Los plugins de optimización sustituyen la necesidad de un buen hardware?

No del todo. Plugins como los incluidos en Paper reducen la carga innecesaria (entidades, IA, chunks), pero si el mundo o la comunidad crecen, el hilo principal seguirá necesitando una CPU con buena frecuencia por núcleo para mantener el TPS estable.