← Blog

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

Por Benjamin D. · PDG

· Lectura 7 min

Ilustración del artículo: Rendimiento de un servidor de juego: entender el TPS, la RAM y el tick rate
Índice

Los tirones casi nunca son mala suerte: el TPS servidor de juego baja porque el hilo principal de simulación no termina su trabajo dentro del tick. Medir ese retraso en milisegundos, identificar si el freno viene de la CPU, de la memoria o de un mod, y ajustar tres o cuatro valores de configuración resuelve la gran mayoría de los casos reales.



Qué significa el TPS servidor de juego y cuándo empieza a doler

Un tick es una vuelta completa del bucle de simulación: mover entidades, calcular física, ejecutar redstone o scripts, resolver colisiones, guardar chunks. Minecraft trabaja a 20 ticks por segundo, lo que deja exactamente 50 ms de presupuesto por tick. Si el cálculo tarda 70 ms, el ritmo cae a unos 14 ticks por segundo y el mundo entero se ralentiza.

Esa caída no se reparte: afecta a todo el mundo simulado a la vez. Los relojes van lentos, los cultivos crecen menos, los mobs avanzan a saltos y los golpes se registran con retraso. El jugador lo describe como lag, pero no tiene nada que ver con su conexión.

  • 20 TPS con MSPT bajo: margen sano, puedes subir carga.
  • 20 TPS con MSPT cerca de 45 ms: estás al límite, un evento cualquiera te tumba.
  • 18 a 19 TPS: tirones perceptibles en combate y en granjas.
  • Por debajo de 15 TPS: hitboxes desincronizadas y pérdida de objetos.

El dato que importa no es el TPS sino el MSPT, los milisegundos por tick. El TPS se queda clavado en 20 hasta que el problema ya es grave, mientras el MSPT sube de forma progresiva y avisa antes. Vigila el MSPT y verás venir el problema con días de antelación.

JuegoBucle de simulaciónSíntoma típico de saturación
Minecraft (Vanilla, Paper, Forge)20 ticks/s, 50 ms por tickRelojes lentos, mobs a saltos, hoppers atascados
FiveM y RedMHilo principal por frame, recursos en colaAvisos de hitch en consola, vehículos que rebotan
ARK Survival Evolved y AscendedSimulación cercana a 30 fps de servidorDinos que se teletransportan, taming fallido
RustTick de red configurable (30 por defecto)Golpes que no registran, puertas lentas
ValheimSimulación por zonas activasEnemigos congelados, barcos que saltan
PalworldBucle único con pals y basesPals inmóviles en bases grandes

Cuando la configuración ya está afinada y el hilo principal sigue saturado, el límite es la máquina: hace falta más rendimiento por núcleo, no más núcleos. En la ficha de hosting Minecraft tienes el detalle técnico del hardware que usamos para ese escenario.



Cómo medir el tick rate y el retraso real sin adivinar

Antes de tocar un solo valor, necesitas una medición. Un administrador que cambia la distancia de visión sin haber leído el MSPT está disparando a ciegas y no sabrá qué ajuste funcionó.

Minecraft y derivados de Paper

Paper expone el estado del bucle directamente por consola, y el perfilador spark indica qué clase o qué plugin consume el tick. Ejecútalo durante una sesión con jugadores conectados, nunca en un mundo vacío.

/tps
/mspt
/spark tps
/spark health
/spark profiler start --timeout 120
/spark profiler stop

El informe te da un porcentaje por método. Si un plugin de protección de terreno aparece con un peso alto en cada tick, ya tienes el culpable sin necesidad de desactivar nada a ciegas. Para los flags de arranque y el perfilado, la documentación del proyecto es la referencia: Source.

FiveM y RedM: hitches y consumo por recurso

Aquí no existe un TPS canónico: lo que se vigila es el tiempo que cada recurso roba al hilo principal. La consola avisa con mensajes de hitch warning cuando un frame se pasa del umbral.

resmon 1
profiler record 500
profiler view
status

Supervivencia: ARK, Rust, Valheim y Palworld

Estos motores no publican un contador de ticks tan claro, así que el diagnóstico pasa por el sistema operativo y por los logs. Conéctate por SSH a la máquina y observa el consumo por hilo mientras la partida está poblada.

htop
mpstat -P ALL 1 10
iostat -x 2 5
journalctl -u nombre-del-servicio -n 200 --no-pager

La pista más útil es esta: si un solo hilo está clavado al 100 % mientras el resto de la CPU está tranquila, el problema es de frecuencia y de simulación, no de falta de núcleos. Añadir vCPU en ese escenario no cambia absolutamente nada.



RAM, recolector de basura y la trampa de asignar más memoria

Asignar memoria de más es uno de los errores más repetidos en administración de servidores Java. Un heap enorme obliga al recolector de basura a recorrer más objetos en cada pasada, y esas pausas se traducen en microcortes de 200 o 400 ms que el jugador siente como un pinchazo seco.

La regla práctica: fija -Xms y -Xmx al mismo valor para evitar redimensionados, y quédate en la memoria que el mundo realmente necesita. Un servidor vanilla con pocos jugadores vive cómodo con 4 GB; uno con modpack pesado pide 8 a 12 GB; un mundo con cientos de miles de chunks generados y mods de dimensiones sube más.

java -Xms8G -Xmx8G \
  -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 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar paper.jar nogui

En juegos nativos (ARK, Rust, DayZ, Palworld) la memoria funciona distinto: no hay recolector, pero sí un consumo que crece con el número de entidades y estructuras. Si el proceso empieza a tocar el swap, el rendimiento se cae en vertical. Comprueba free -h y mantén el swap como red de seguridad, nunca como memoria de trabajo.

Señal clara de fuga: el MSPT sube de forma lineal a lo largo de las horas y se arregla solo al reiniciar. Eso es memoria o entidades acumuladas, no falta de potencia.


El cuello de botella mono-núcleo que casi nadie revisa

Minecraft, ARK, Rust y Valheim concentran la lógica del mundo en un hilo dominante. El resto de núcleos atiende red, compresión, guardado o generación de chunks, pero la simulación pesada corre en uno solo. Por eso un procesador con muchos núcleos lentos rinde peor que uno con pocos núcleos rápidos.

Lo que marca la diferencia es la frecuencia sostenida, el IPC y la caché. Un Ryzen 9 7950X3D resuelve más trabajo dentro de los mismos 50 ms gracias a su caché ampliada, que reduce los accesos a memoria en mundos con muchas entidades. La RAM DDR5 ECC aporta ancho de banda y estabilidad en sesiones largas.

  • CPU compartida con vecinos ruidosos: aparece steal time en htop y los tirones llegan sin motivo aparente.
  • Disco mecánico o SAN lenta: el autoguardado y la carga de chunks bloquean el tick; con SSD NVMe ese coste desaparece casi por completo.
  • Saturación de red: con 1 Gbit/s incluido la banda rara vez es el freno, salvo ataque; el Anti-DDoS activo por defecto absorbe el tráfico volumétrico antes de que toque el bucle.

Un detalle práctico sobre la pregeneración: generar terreno en caliente es de las operaciones más caras que existe. Si tu comunidad va a explorar mucho, pregenera el mundo antes de abrir y fija un borde razonable. El Blog de Nexus Games recoge otras rutinas de mantenimiento en esta línea.



Ajustes que quitan los tirones cuando entran más jugadores

El patrón es siempre el mismo: con diez conectados todo va fino, con cuarenta el mundo se arrastra. La causa es que cada jugador arrastra su propio conjunto de chunks cargados, sus mobs y sus entidades. Reducir ese volumen por jugador es lo que devuelve el margen.

Minecraft: distancia de visión y entidades

# server.properties
view-distance=7
simulation-distance=5
network-compression-threshold=256
max-tick-time=60000
sync-chunk-writes=false
# spigot.yml
entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8
merge-radius:
  item: 4.0
  exp: 6.0
mob-spawn-range: 6
# config/paper-world-defaults.yml
chunks:
  max-auto-save-chunks-per-tick: 8
entities:
  spawning:
    per-player-mob-spawns: true
collisions:
  max-entity-collisions: 2
hopper:
  disable-move-event: true

Bajar simulation-distance de 10 a 5 suele recortar el MSPT a la mitad en servidores poblados, y el jugador apenas lo nota porque sigue viendo lejos gracias a view-distance. Es el ajuste con la mayor relación entre beneficio e impacto en la experiencia.

FiveM: OneSync y recursos que se comen el tick

Con muchos slots, OneSync deja de ser opcional: reparte la sincronización de entidades de otra forma y evita el colapso del hilo principal. La activación de OneSync Infinity y los slots por encima de 32 pasan por Element Club, el programa de Cfx.re, mientras la licencia del servidor sigue siendo gratuita.

# server.cfg
set onesync on
set sv_maxclients 48
sv_enforceGameBuild 3095
set sv_scriptHookAllowed 0
set onesync_distanceCullVehicles true

Después, revis

Sigue leyendo