Rendimiento de un servidor de juego: entender el TPS, la RAM y el tick rate
Por Benjamin D. · PDG
· Lectura 7 min

Í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.
| Juego | Bucle de simulación | Síntoma típico de saturación |
|---|---|---|
| Minecraft (Vanilla, Paper, Forge) | 20 ticks/s, 50 ms por tick | Relojes lentos, mobs a saltos, hoppers atascados |
| FiveM y RedM | Hilo principal por frame, recursos en cola | Avisos de hitch en consola, vehículos que rebotan |
| ARK Survival Evolved y Ascended | Simulación cercana a 30 fps de servidor | Dinos que se teletransportan, taming fallido |
| Rust | Tick de red configurable (30 por defecto) | Golpes que no registran, puertas lentas |
| Valheim | Simulación por zonas activas | Enemigos congelados, barcos que saltan |
| Palworld | Bucle único con pals y bases | Pals 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
htopy 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


