Rendimiento de un servidor de juego : entender el TPS, la CPU y la RAM

Par Benjamin D. · PDG

13 de septiembre de 2026 · Mis à jour le 13 de septiembre de 2026 · Lecture 11 min

Índice

El rendimiento servidor juego no se mide en gigahercios ni en gigabytes: se mide en TPS, en milisegundos por tick y en la estabilidad de esas cifras cuando veinte jugadores cargan chunks a la vez. En esta guía repasamos los factores técnicos que gobiernan ese comportamiento —CPU mono-núcleo, memoria, almacenamiento NVMe— y cómo diagnosticar una caída con herramientas reales antes de tocar la configuración a ciegas.

Qué es el TPS y por qué define el rendimiento servidor juego

Casi todos los motores de juego multijugador funcionan igual: un bucle que se repite X veces por segundo. En cada vuelta —cada tick— el motor calcula el movimiento de las entidades, la física, la IA de los mobs, el crecimiento de cultivos, los eventos de los scripts y envía el estado resultante a los clientes conectados.

En Minecraft Java ese bucle apunta a 20 ticks por segundo, lo que deja exactamente 50 milisegundos de presupuesto por tick. Si el trabajo de un tick tarda 38 ms, todo va bien. Si tarda 70 ms, el motor no puede inventar tiempo: baja la frecuencia a ~14 TPS y el mundo entero se ralentiza. Los mobs se mueven a cámara lenta, los hornos tardan más, los comandos responden con retraso. Eso es lag de servidor, y no tiene nada que ver con tu conexión.

Juego	Métrica de bucle	Dónde se observa
Minecraft (Java)	20 TPS objetivo / MSPT	`/tps`, `/spark tps`, consola del panel
Rust	`server.tickrate` + FPS del servidor	Consola F1 con `server.fps`
ARK (Evolved / Ascended)	FPS del servidor (bucle Unreal)	`stat unit` en cliente, logs del servidor
Palworld / Valheim	Tick fijo del motor	Síntomas: desync de criaturas, rubberbanding
FiveM / RedM	ms por recurso	`resmon` y `profiler` del servidor

TPS y latencia no son lo mismo

Es la confusión más habitual en un ticket de soporte. La latencia (ping) es el tiempo que tarda un paquete en ir y volver entre el cliente y la máquina: depende de la red, de la ruta y de la distancia geográfica. El TPS es la capacidad de la máquina para terminar el trabajo de simulación a tiempo. Puedes tener 12 ms de ping y un mundo a 8 TPS, o 120 ms de ping con 20 TPS clavados. Diagnosticar el problema equivocado hace perder días.

MSPT: la métrica que de verdad importa

El TPS es un indicador saturado: por encima de 20 no sube. Un servidor con 20,0 TPS y 48 ms de MSPT está al borde del colapso, mientras que otro con 20,0 TPS y 12 ms tiene margen para el triple de jugadores. Vigila siempre el MSPT (milisegundos por tick), no solo el TPS.

Si administras un mundo Java con mods o plugins y quieres que la infraestructura no sea el cuello de botella, revisa las características técnicas de nuestro alojamiento servidor Minecraft: CPU Ryzen de alta frecuencia, NVMe y anti-DDoS activo por defecto. El resto de este artículo sirve igual para cualquier motor de Todos nuestros servidores de juegos.

CPU mono-núcleo, RAM y NVMe: el hardware detrás del tick

Por qué la frecuencia manda sobre el número de núcleos

El bucle principal de simulación de Minecraft, ARK, Rust, Valheim o Project Zomboid se ejecuta mayoritariamente en un solo hilo. Da igual que la máquina tenga 64 núcleos: el tick lo calcula uno, y el tiempo que tarda depende de la potencia por núcleo (IPC × frecuencia). Por eso un procesador Ryzen de alta frecuencia rinde mucho mejor en simulación que un CPU de servidor con muchos núcleos lentos, aunque este último gane en cualquier prueba sintética multihilo.

Los núcleos adicionales sí sirven, pero para otras tareas: generación de chunks en segundo plano, compresión de copias de seguridad, red, el proceso del panel, otros servicios del sistema. Lo que nunca hacen es acelerar el tick en sí. Si tu vecino de máquina satura los núcleos compartidos, tu tick sufre: la diferencia entre CPU compartida y CPU con recursos garantizados se nota exactamente aquí.

RAM: más no es mejor, es peor si sobra

En servidores Java, asignar memoria de más es contraproducente. Cuanto mayor es el heap, más trabajo tiene el recolector de basura (GC) y más largas son sus pausas; una pausa de GC de 300 ms se traduce en un pico de MSPT visible para todos los jugadores. La práctica sensata es fijar -Xms y -Xmx al mismo valor y usar flags de G1GC afinadas:

java -Xms6G -Xmx6G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
  -jar server.jar nogui

En motores nativos (Unreal, Unity) la memoria no se recolecta igual, pero la regla práctica se mantiene: la RAM debe cubrir el mundo cargado más un margen. Cuando falta, el sistema empieza a usar swap y el tiempo de tick se dispara de forma brutal. En Linux lo detectas al instante:

free -h
vmstat 1 5

Si la columna si/so de vmstat se mueve, estás haciendo swap y ningún ajuste de juego lo va a arreglar.

Almacenamiento NVMe: los picos que nadie mira

Los mundos persistentes escriben constantemente. Minecraft guarda regiones .mca, Rust serializa el mapa completo cada pocos minutos, ARK escribe un .ark de varios cientos de megabytes, Project Zomboid guarda por celda. Cuando esa escritura ocurre sobre un disco lento, el hilo principal se bloquea esperando I/O y aparece un pico de MSPT periódico y regular. El síntoma clásico: "cada 5 minutos el servidor se congela dos segundos".

Con NVMe esos picos se reducen a algo casi imperceptible. Para comprobar si el disco es el culpable en una máquina propia:

iostat -x 1 10
# mira %util y await del dispositivo
sudo apt install sysstat -y

Un await alto coincidiendo con el autoguardado confirma el diagnóstico. Ajusta la frecuencia de guardado (server.saveinterval en Rust, AutoSavePeriodMinutes en ARK) y programa las copias fuera de las horas punta.

Diagnosticar una caída de rendimiento servidor juego paso a paso

La regla de oro: no toques nada hasta tener un dato. Los administradores que suben la RAM "por si acaso" suelen empeorar el problema.

Reproduce y fecha la caída. ¿Ocurre con 5 jugadores o con 40? ¿A una hora concreta? ¿Al entrar en una zona determinada? Anota la hora exacta: la necesitarás para cruzar logs.
Mira la consola en vivo del panel. Warnings del tipo Can't keep up! Did the system time change, or is the server overloaded? indican ticks perdidos y dan la cifra de retraso.
Perfila el proceso, no el sistema. En Java, spark es la herramienta estándar:

/spark tps
/spark healthreport
/spark profiler start --timeout 120
# al terminar, spark devuelve un enlace con el árbol de llamadas

El informe te dice qué plugin, qué mod o qué sistema del motor consume el tick. En servidores con Timings (Paper antiguo) sirve /timings on seguido de /timings paste. En FiveM, resmon 1 muestra el gasto por recurso en milisegundos.

Cuenta entidades. En la mayoría de caídas la culpa es la acumulación de entidades: granjas de mobs, ítems tirados, carts, dinosaurios salvajes, barriles en Rust, Pals en base. Comandos útiles en Java: /spark heapsummary o plugins de conteo por chunk.
Aísla por eliminación. Arranca sin mods/plugins desde el gestor de archivos del panel y reintroduce por mitades. Es lento, pero es el único método que da certeza.
Comprueba la capa de sistema. Si gestionas tú la máquina:

htop                     # ¿un solo hilo al 100%? es normal, es el tick
uptime                   # load average sostenido por encima de núcleos = saturación
journalctl -u minecraft -n 200 --no-pager
systemctl status pterodactyl-wings

Descarta la red. Si el TPS está en 20 pero los jugadores notan rubberbanding, el problema es latencia o pérdida de paquetes, no CPU. Pide a un jugador un mtr o un tracert hacia la IP del servidor.

Tabla rápida de síntomas

Síntoma	Causa probable	Primera acción
TPS bajo constante	CPU saturada por simulación	Perfilar con spark, reducir simulation-distance
Picos regulares cada X minutos	Autoguardado / copia de seguridad / I/O	Revisar intervalo de guardado y disco
Congelaciones de 200-500 ms aleatorias	Pausas de GC	Ajustar heap y flags de G1GC
TPS 20 pero rubberbanding	Red / latencia / pérdida de paquetes	mtr desde el cliente, revisar ruta
Degradación progresiva desde el arranque	Fuga de memoria o entidades acumuladas	Heap dump, conteo de entidades, reinicio programado
Caída solo al entrar jugadores nuevos	Generación de chunks en tiempo real	Pregenerar el mundo

Correcciones que sí cambian el tiempo de tick

Distancia de simulación y de vista

Es el ajuste con mayor impacto y el peor entendido. La distancia de vista determina cuántos chunks se envían al cliente; la de simulación, cuántos se calculan cada tick. Bajar la simulación de 10 a 6 puede recortar el MSPT a la mitad sin que los jugadores noten diferencia visual.

# server.properties
view-distance=8
simulation-distance=5
max-tick-time=60000
sync-chunk-writes=false

Control de entidades

En Paper, los límites por chunk y el mob spawn range evitan la explosión de entidades. En ARK conviene vigilar el límite de estructuras por plataforma y el decaimiento de bases abandonadas; en Rust, purgar entidades huérfanas antes de un wipe; en Palworld, limitar el número de Pals por base. Cada motor tiene su válvula, y todas se editan desde el gestor de archivos del panel:

# spigot.yml
entity-tracking-range:
  players: 48
  animals: 32
  monsters: 32
merge-radius:
  item: 3.5
  exp: 4.0

Pregenerar el mundo

La generación de terreno en caliente es una de las operaciones más caras que existe. Pregenerar el área jugable —con una herramienta tipo Chunky en Java, o simplemente recorriendo el mapa en motores nativos— elimina los picos cuando alguien explora. Hazlo con el servidor vacío y bórralo del calendario de mantenimiento después.

chunky radius 3000
chunky start
chunky progress

Mods y plugins: el coste oculto

Un modpack pesado no es lento por tener 200 mods, sino por tener tres mods que abusan del tick. Los sospechosos habituales: sistemas de chunk-loading permanente, mods de generación dinámica, plugins de protección que escanean bloque a bloque, addons de economía con consultas SQL síncronas. Mueve las bases de datos de SQLite a MySQL cuando el servidor crece, y comprueba que los plugins estén al día con la versión del juego. La documentación oficial de Pterodactyl detalla cómo gestionar variables de arranque y límites de recursos por instancia.

Reinicios programados y copias de seguridad

Un reinicio diario de madrugada limpia fugas de memoria, entidades fantasma y estados corruptos. Programarlo desde el panel cuesta un minuto y ahorra tickets. Combínalo con copias automáticas y verifica de vez en cuando que se pueden restaurar: una copia que nunca se ha probado no es una copia.

Higiene de administración

El rendimiento servidor juego también se degrada por motivos no técnicos: un usuario abusando de una granja, un exploit de duplicación, un bot spammeando conexiones. Contraseñas RCON largas y únicas, whitelist en comunidades privadas, sub-usuarios del panel con permisos mínimos y actualizaciones al día cubren el 90% de los incidentes. La protección anti-DDoS volumétrica ya está aplicada a nivel de infraestructura, así que tu trabajo se centra en la capa de aplicación. En el Blog de Fly-Serv publicamos guías específicas por juego, y en Fly-Serv puedes consultar las características técnicas de cada máquina.

Conclusión

El tick es la unidad de medida real de un mundo multijugador. Entender que la simulación depende de un hilo, que la memoria mal dimensionada genera pausas y que el almacenamiento provoca picos periódicos permite atacar la causa y no el síntoma. Perfila primero, ajusta después, y documenta cada cambio: así sabrás siempre qué modificación devolvió los 20 TPS.

FAQ

¿Por qué mi servidor va lento si la CPU solo está al 25%?

Porque el porcentaje que ves es la media de todos los núcleos. La simulación corre en un hilo: si ese hilo está al 100% y los demás inactivos, un procesador de 8 núcleos mostrará alrededor del 12-25% de uso global mientras el tick ya está saturado. Mira el uso por hilo con htop (tecla H) y vigila el MSPT, no el porcentaje agregado.

¿Cuánta RAM debo asignar a un mundo Minecraft con mods?

Lo justo para el mundo cargado más un 25-30% de margen, con -Xms y -Xmx iguales. Como referencia práctica: 4 GB para vanilla o plugins ligeros, 6-8 GB para modpacks medianos, 10-12 GB para modpacks grandes. Asignar 16 GB a un servidor que usa 5 solo alarga las pausas del recolector de basura y empeora el tiempo de tick.

¿Cómo sé si el problema es el tick o la conexión de mis jugadores?

Ejecuta /spark tps o mira el gráfico de la consola. Si el TPS está estable en 20 y el MSPT por debajo de 30 ms mientras los jugadores reportan tirones, el cuello de botella está en la red: pide un mtr o tracert hacia la IP para localizar el salto con pérdida. Si el TPS cae, el problema es de simulación y toca perfilar.