Comprendre le tick rate et les performances d'un serveur de jeu
Par Benjamin D. · PDG
· Mis à jour le 18 de septiembre de 2026 · Lecture 11 min
Índice
El tick rate servidor es la métrica que decide si una partida se siente fluida o pastosa: indica cuántas veces por segundo el mundo simulado se actualiza y se envía a los clientes. Un ping bajo no compensa un tick irregular. Aquí desglosamos TPS, MSPT, consumo de RAM y la dependencia del CPU mono-núcleo para saber qué mirar cuando el juego empieza a ir a saltos.
Qué es el tick rate servidor y cómo se mide
Un juego multijugador con autoridad en el lado del servidor funciona como un bucle: cada iteración (un tick) procesa entradas de los jugadores, física, IA de criaturas, crecimiento de cultivos, temporizadores de bloques, redstone, decaimiento de estructuras, y luego difunde el nuevo estado a todos los clientes conectados. El tick rate servidor es la frecuencia objetivo de ese bucle.
Minecraft vanilla y sus forks (Paper, Fabric, Forge) apuntan a 20 ticks por segundo, es decir 50 ms disponibles por tick. Si el trabajo de un tick se completa en 12 ms, el bucle duerme el resto y mantiene 20 TPS estables. Si tarda 70 ms, ya no hay forma de mantener el ritmo: los TPS caen a ~14 y el tiempo de juego se dilata. Las criaturas se mueven a tirones, los hoppers tardan, los comandos responden tarde.
Aquí aparece la distinción clave que confunde a mucha gente:
- TPS: ticks realmente ejecutados por segundo. Es un techo, nunca supera el objetivo.
- MSPT: milisegundos que consume cada tick. Es la métrica útil, porque avisa antes de que los TPS caigan.
- Ping / latencia: tiempo de ida y vuelta en la red. Independiente del tick.
Un servidor a 20 TPS con 45 MSPT está al borde del colapso aunque el panel muestre «20/20». Un servidor a 20 TPS con 10 MSPT tiene margen para crecer. Vigila siempre MSPT, no solo TPS.
Si gestionas una comunidad de Minecraft y quieres partir de una base con CPU Ryzen de alta frecuencia, NVMe y anti-DDoS incluido, nuestra página de alojamiento servidor Minecraft detalla la infraestructura que usamos para ese tipo de carga.
Cada juego tiene su propio bucle
| Juego | Objetivo habitual del bucle | Síntoma típico de saturación |
|---|---|---|
| Minecraft (Paper/Forge) | 20 TPS (50 ms) | Criaturas a tirones, retardo al romper bloques |
| Rust | Ajustable vía server.tickrate | Disparos que no registran, «rubber banding» |
| ARK (Evolved / Ascended) | Bucle Unreal, ~30 fps de servidor | Dinos deslizándose, retardo en estructuras |
| FiveM / RedM | Ticks por recurso (ms por frame) | Scripts que congelan al jugador |
| Valheim | Bucle variable según zonas activas | Retardo al cargar zonas nuevas |
| Project Zomboid | Bucle propio con streaming de celdas | Zombis teletransportándose |
El principio es siempre el mismo: si el trabajo por iteración supera el presupuesto de tiempo, el juego se degrada. Cambia el nombre de la métrica, no el problema. Puedes ver los juegos que cubrimos en todos nuestros servidores de juegos.
Por qué el CPU mono-núcleo manda sobre el número de núcleos
Aquí está el malentendido más caro en administración de servidores de juego: mucha gente asume que 16 núcleos equivalen a un servidor 16 veces más rápido. Falso para la mayoría de los juegos de supervivencia y sandbox.
El bucle de simulación principal es, en la práctica, secuencial. La física de una entidad puede depender del bloque que otra entidad acaba de mover; el orden importa. Por eso el hilo principal (main thread) hace casi todo el trabajo crítico y solo delega tareas auxiliares:
- Generación y compresión de chunks (parcialmente paralelizable).
- E/S de disco: guardado de regiones, escritura de logs.
- Red: serialización de paquetes por cliente.
- Recolección de basura de la JVM, en juegos Java.
Consecuencia directa: la frecuencia por núcleo (IPC × GHz) pesa mucho más que el recuento de núcleos. Un Ryzen moderno a alta frecuencia procesa el mismo tick en menos milisegundos que un CPU de servidor con muchos núcleos lentos. Ese es el motivo técnico por el que un tick rate servidor estable depende sobre todo del rendimiento mono-hilo.
Cómo verificar que estás limitado por un solo hilo
En el panel Pterodactyl, el gráfico de CPU se expresa en porcentaje donde 100 % equivale a un núcleo completo. Si ves 98–105 % sostenido mientras hay núcleos libres, estás saturando el hilo principal: añadir núcleos no cambiará nada. Si ves 400 % con picos, el trabajo se está repartiendo y el cuello de botella está en otro lado.
En un sistema Linux con acceso por consola, la vista por hilo lo confirma:
top -H -p $(pgrep -f minecraft_server)
# Pulsa 1 para ver los núcleos por separado
# Un hilo clavado al 100 % = límite mono-núcleoLo que sí escala con más núcleos
Bifurcaciones como Paper paralelizan parte de la generación de terreno, y proyectos derivados introducen simulación por regiones que reparte el mundo entre varios hilos. En FiveM, cada recurso tiene su propio presupuesto de tiempo por frame, así que un script mal escrito bloquea al resto. La regla práctica: la frecuencia resuelve el tick, los núcleos resuelven la carga paralela (backups, chunks, compresión, múltiples instancias).
RAM, recolección de basura y lo que realmente provoca los micro-tirones
La RAM no acelera un tick. Sirve para evitar que el sistema tenga que liberar memoria en el peor momento. En juegos basados en Java, esto se traduce en una realidad concreta: los freeze de medio segundo que aparecen cada pocos minutos casi nunca son de red, son pausas del recolector de basura.
Ni poca ni demasiada memoria
Asignar 2 GB a un mundo modded con 200 mods produce Out of Memory y congelaciones continuas. Asignar 32 GB a un servidor de 10 jugadores también es contraproducente: cuanto mayor es el heap, más largas pueden ser ciertas fases de recolección si los parámetros no están afinados. Referencias prácticas:
- Vanilla / Paper, 10–20 jugadores: 4 GB.
- Paper con 40 plugins, 40 jugadores: 6–8 GB.
- Forge/Fabric con modpack grande: 8–12 GB.
- Servidores no-Java (Rust, ARK, Palworld): la memoria la consume el mundo persistente y las entidades; vigila el crecimiento del guardado.
Argumentos de JVM para acortar las pausas
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:InitiatingHeapOccupancyPercent=15 \
-jar server.jar noguiDos detalles que marcan diferencia: fija -Xms igual a -Xmx para que el heap no se redimensione en caliente, y no superes los 31 GB si quieres conservar los punteros comprimidos. En el panel puedes editar estos parámetros en la variable de arranque sin tocar el resto de la configuración.
El disco también entra en el tick
Cada guardado automático de región, cada escritura del mundo de Rust o del .db de Valheim bloquea brevemente el hilo que la ejecuta. Con almacenamiento mecánico esas escrituras se miden en decenas de milisegundos y se comen el presupuesto del tick. Con NVMe pasan a ser irrelevantes en la mayoría de los casos. Es la razón por la que el almacenamiento aparece en cualquier análisis serio de fluidez, no solo en los tiempos de carga.
Diagnóstico y ajustes que estabilizan el tick
No optimices a ciegas. Mide primero, actúa después.
1. Perfila el tick
En Minecraft, el estándar actual es spark. Desde la consola del panel:
/tps
/mspt
/spark profiler start --timeout 120
/spark profiler stop
/spark healthEl informe indica qué porcentaje del tick consume cada plugin, cada tipo de entidad y cada mod. Casi siempre aparecen los mismos culpables: acumulaciones de entidades en granjas, un plugin que consulta la base de datos de forma síncrona, o un mod que recorre inventarios en cada tick. La documentación oficial de PaperMC detalla la interpretación de esos informes.
En FiveM, el equivalente es el monitor de recursos:
resmon 1
profiler record 500
profiler viewCualquier recurso por encima de 1 ms por frame merece revisión; por encima de 5 ms es una causa directa de tirones en la ciudad. Tenemos más material práctico sobre este tipo de servidores en Servidor FiveM.
2. Reduce el trabajo por tick
La palanca más eficaz nunca es «más hardware», es «menos trabajo inútil». En server.properties:
view-distance=7
simulation-distance=5
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256La distancia de simulación es la que cuesta CPU: define cuántos chunks se actualizan activamente. Bajarla de 10 a 5 puede reducir el MSPT a la mitad en mundos poblados, y el jugador apenas lo nota si mantienes una distancia de visión razonable.
En spigot.yml y los ficheros de Paper, los rangos de activación de entidades y el agrupamiento de criaturas son igual de determinantes:
entity-activation-range:
animals: 16
monsters: 24
misc: 8
merge-radius:
item: 3.5
exp: 4.0
mob-spawn-range: 63. Ajusta el objetivo del bucle cuando el juego lo permite
En Rust puedes modificar la frecuencia del servidor por consola:
server.tickrate 30
server.maxplayers 100
decay.upkeep trueSubir el tick mejora la sensación de los combates a distancia, pero multiplica el consumo de CPU y de ancho de banda. Con un mundo grande y muchas bases, un valor moderado y estable rinde más que un valor alto que el hardware no sostiene. El mismo criterio aplica a cualquier ajuste agresivo: mide el MSPT antes y después. Más contexto en Servidor Rust.
4. Controla lo que crece con el tiempo
Un servidor fluido el primer día puede ir a tirones al mes. Causas habituales:
- Acumulación de entidades: ítems en el suelo, criaturas atrapadas, dinos salvajes. Programa limpiezas periódicas.
- Mundo inflado: exploración sin límite genera cientos de miles de chunks. Recorta las regiones sin uso.
- Estructuras masivas: bases enormes en ARK o Rust cuestan cálculo de estabilidad y decaimiento.
- Plugins abandonados: código que ya no está adaptado a la versión actual suele consumir tick de forma silenciosa.
5. Separa lo que no debe compartir hilo
Las copias de seguridad, la compresión y la generación masiva de terreno compiten con la simulación. Ejecuta las copias en horas de baja actividad y apóyate en las automáticas del panel para no lanzar archivados manuales en plena hora punta. Si mantienes varias instancias, evita que dos mundos pesados arranquen su guardado en el mismo minuto.
Y mide siempre desde el lado correcto: si el MSPT es bajo pero los jugadores reportan retardo, el problema está en la red o en el cliente, no en el bucle. Un traceroute y una prueba de pérdida de paquetes descartan esa mitad del diagnóstico en dos minutos. Publicamos guías adicionales de administración en el Blog de Fly-Serv.
Resumen operativo
| Síntoma | Métrica a revisar | Acción |
|---|---|---|
| TPS estables, jugadores con retardo | Ping, pérdida de paquetes | Red del cliente o ruta, no el tick |
| TPS por debajo de 20 de forma constante | MSPT, perfil de spark | Reducir simulación, entidades, plugins costosos |
| Congelaciones periódicas de 0,5–2 s | Pausas de GC, E/S de disco | Afinar heap y argumentos de JVM |
| CPU clavado al 100 % de un núcleo | Uso por hilo | Límite mono-hilo: frecuencia, no más núcleos |
| Tirones al explorar zonas nuevas | Generación de chunks, disco | Pregenerar terreno, almacenamiento NVMe |
Entender estas cinco líneas evita el 90 % de las decisiones equivocadas en administración de servidores de juego.
Conclusión
La fluidez en multijugador no depende de una cifra mágica sino de un equilibrio: un bucle de simulación que termina su trabajo dentro del tiempo disponible, memoria suficiente sin pausas largas, almacenamiento rápido y un CPU con frecuencia alta por núcleo. Mide MSPT, perfila antes de tocar la configuración, y reduce el trabajo inútil por tick. El resto son ajustes finos.
FAQ
¿Por qué mi servidor marca 20 TPS pero los jugadores notan tirones?Porque los TPS son un techo y ocultan los picos. Revisa el MSPT: si oscila entre 15 y 48 ms, algunos ticks se acercan al límite de 50 ms y el jugador lo percibe como micro-tirones. Perfila con /spark profiler start durante dos minutos e identifica qué plugin, mod o tipo de entidad consume esos picos. Si el MSPT es bajo y estable, el problema está en la red del cliente o en su propio rendimiento gráfico.
No directamente. La RAM evita errores de memoria y reduce la frecuencia de recolección de basura, pero no acelera el bucle de simulación, que depende del rendimiento mono-núcleo del CPU. Asigna lo necesario según el número de mods y jugadores, fija -Xms igual a -Xmx y afina los argumentos de G1GC. Si ya tienes memoria sobrada y el tick sigue bajo, el cuello de botella es CPU o cantidad de entidades activas.
Solo si el hardware lo sostiene. Subir la frecuencia del bucle mejora el registro de disparos y el movimiento, pero multiplica la carga de CPU y el tráfico de red. Aplica el cambio, deja el servidor funcionando en hora punta y compara el tiempo por tick antes y después. Si el bucle empieza a perder ritmo, vuelve a un valor inferior: un tick moderado y constante se siente mejor que uno alto e irregular.