Área de clienteTicks, TPS y hilo principal en Minecraft: entender el lag del servidor
Ticks, TPS e hilo principal: estas tres nociones explican por qué un servidor de Minecraft va con lag. Un servidor sano calcula 20 ticks por segundo, es decir, un tick cada 50 milisegundos. Esta guía explica cómo Minecraft divide el tiempo, por qué casi todo pasa por un solo hilo, en qué momento caen los TPS y cómo encontrar la causa con Spark.
Si la consola muestra «Can't keep up!» una y otra vez, este es el mensaje en cuestión:
[Server thread/WARN] [minecraft/MinecraftServer]: Can't keep up! Is the server overloaded? Running 4681ms or 93 ticks behind¿Qué son exactamente los ticks?
Minecraft funciona con un bucle que se repite sin parar. Cada vuelta del bucle se llama tick. En cada tick, el servidor vuelve a calcular todo lo que pasa en el mundo:
las acciones de los jugadores (movimientos, clics, bloques colocados o rotos);
la posición de todas las entidades, que luego se envía a cada jugador;
la aparición de las criaturas, su IA y sus movimientos;
la redstone y todas las demás mecánicas del juego.
Un servidor que funciona bien apunta a 20 ticks por segundo, un tick cada 50 milisegundos. Este ritmo es el que hace que el juego sea fluido. La página «Tick» del Minecraft Wiki da la definición técnica completa.
El hilo principal, por qué un solo núcleo hace todo el trabajo
Es lo que más sorprende. La gran mayoría de los cálculos del juego pasan por un solo hilo de ejecución, el hilo principal. En cada momento, un solo núcleo del procesador hace la mayor parte del trabajo.
Pensemos en un zombi que ataca a un jugador. El servidor comprueba su posición, calcula la distancia, busca un camino, revisa la línea de visión y aplica el daño. Todo ocurre en orden, en el mismo hilo, y el tick no puede avanzar hasta terminar.
Por eso, en un servidor de Minecraft, un procesador rápido núcleo a núcleo importa mucho más que el número total de núcleos, sobre todo con muchas entidades o mucha redstone.
Las versiones recientes llevan parte del trabajo a otros hilos: generación e iluminación de chunks, red. Pero las entidades, la IA y la redstone siguen en el hilo principal.
Cuando todo va bien, el servidor respira
En condiciones normales, cada tick se calcula en menos de 50 ms. Si el servidor termina antes, espera al siguiente tick para mantener el ritmo.
Por ejemplo, un tick de 15 ms deja 35 ms de margen. Los jugadores no notan ningún retraso, las criaturas reaccionan al momento, la redstone responde sin esperar y el servidor se mantiene en 20 TPS. Este tiempo por tick se llama MSPT, milisegundos por tick.
Cuando hay lag, el tick supera los 50 ms
El problema empieza en cuanto un tick tarda más de 50 ms. Los ticks no se ejecutan en paralelo: el siguiente se retrasa y, si se repite, el retraso se acumula.
Para los jugadores, las señales no engañan: las criaturas se teletransportan, los bloques rotos reaparecen antes de desaparecer, la redstone responde a cámara lenta y cada acción llega con retraso.
El mensaje «Can't keep up!» aparece cuando el servidor acumula más de 2000 ms de retraso. Si un solo tick se bloquea demasiado tiempo, el watchdog considera que el servidor se ha colgado y lo detiene. Este límite lo fija max-tick-time en server.properties: 60000 ms por defecto, es decir, un minuto.
Un servidor puede «funcionar» y aun así ser injugable. Los jugadores notan el lag mucho antes de un cierre real.
Por qué los ticks se vuelven demasiado largos
La causa número uno es un hilo principal sobrecargado: demasiado que calcular en muy poco tiempo. Como todo se repite 20 veces por segundo, la menor fuente de carga se multiplica rápido. Los culpables habituales:
demasiadas entidades activas: 500 zombis en una zona son 500 veces los cálculos de IA, rutas y colisiones en cada tick;
granjas de criaturas mal diseñadas, que amontonan cientos de entidades en poco espacio;
redstone intensiva: un circuito complejo que funciona en bucle puede acaparar él solo el hilo principal;
chunks cargados de forma permanente, por tolvas, cargadores de chunks o jugadores AFK en zonas densas;
colisiones en masa: 50 gallinas en 2 por 2 bloques parecen inofensivas, pero son una pesadilla de cálculos para el servidor.
¿El lag solo aparece cuando hay jugadores en un lugar concreto? Busca primero allí una granja, un gran circuito de redstone o un montón de entidades.
Los TPS, la salud del servidor en un número
Los TPS, o ticks por segundo, miden cuántos ticks consigue producir el servidor cada segundo. Con 20 TPS todo va bien. En cuanto el servidor se retrasa, los TPS bajan y el juego se ralentiza.
Una fórmula sencilla para ver el efecto:
(1000 - retraso en ms) / 50 = TPSSi el servidor acumula 250 ms de retraso en un segundo, baja a (1000 - 250) / 50 = 15 TPS. Otra forma de verlo: un tick de 66 ms solo deja sitio a 15 ticks por segundo. En el juego, 15 TPS ya se notan mucho. Por debajo de 10, es casi injugable.
Medir los TPS y el MSPT
| Comando | Servidor | Resultado |
|---|---|---|
/tick query | Java 1.20.3 y posteriores, todos | Ritmo objetivo y tiempo medio por tick |
/tps | Paper, Spigot, Purpur | TPS en 1, 5 y 15 minutos |
/mspt | Paper, Purpur | Tiempo por tick, medio y máximo |
/neoforge tps | NeoForge | TPS y tiempo por tick, por dimensión |
/forge tps | Forge | TPS y tiempo por tick, por dimensión |
/spark tps | Con Spark | TPS, MSPT y carga del procesador |
En la consola de OuiPanel, escribe estos comandos sin la barra. La guía +150 comandos de Minecraft detalla /tick, que también sirve para congelar o acelerar el juego.
Encontrar la causa con Spark
Saber que el servidor va con lag es una cosa, saber por qué es otra. La herramienta más eficaz es Spark: perfila el hilo principal y muestra con precisión qué consume tiempo en cada tick, sea un plugin, una entidad o una mecánica del juego.
En Paper y Purpur, Spark viene incluido desde la 1.21: la consola muestra «[spark] Starting background profiler» al arrancar.
En Spigot, instálalo desde la página Plugins de OuiPanel.
En Forge, NeoForge o Fabric, instala el mod spark desde el Mods Manager.
spark profiler start
# Déjalo funcionar unos minutos mientras los jugadores juegan
spark profiler stopEstas líneas se escriben en la consola de OuiPanel. Al detenerlo, Spark da un enlace a su informe. Unos minutos de perfil suelen bastar para encontrar al culpable, en lugar de ir a ciegas.
La tarjeta Estadísticas en vivo, a la derecha de la consola, muestra la memoria y el procesador usados. No da los TPS: para eso, usa los comandos de arriba.
Para reducir la carga una vez encontrada la causa, consulta las guías Cómo optimizar un servidor de Minecraft para Paper y Spigot, y Mods NeoForge Minecraft para un servidor con mods.
¿Necesitas ayuda?
Abre un ticket desde Tickets › Abrir un ticket, o desde el recuadro Contactar con el soporte al pie de la ficha de tu servidor en el área de cliente. También puedes preguntar en el Discord de OuiHeberg.
Descubre nuestros planes de alojamiento Minecraft desde 1,99€/mes con instalación automática de mods.
Hosting Minecraft →