Guía de hosting de Minecraft
Cómo reducir el lag de tu servidor de Minecraft
El lag tiene tres causas distintas que, vistas desde la silla de un jugador, parecen todas iguales. Esta página las repasa en el orden que encuentra el problema más rápido, y cada cifra está calculada a partir de los ajustes que ofrece de verdad nuestro propio panel.
La respuesta corta
Primero, mide
Un TPS por debajo de 20 o un tick por encima de 50 ms significa que lo lento es el servidor. El panel o Spark te dicen qué parte.
Después, los cuatro arreglos gratis
Pregenera los chunks, baja la distancia de visión, aligera las entidades y calma la redstone. En ese orden.
Sigue lento y sobra memoria
A un núcleo le falta tiempo. Eso se arregla con el plan, no con ajustes.
Todo lo que viene después desarrolla estas tres líneas, con las cifras que hay detrás de cada paso.
Entender el TPS
El TPS son los ticks por segundo, y es el latido del servidor. Todo lo que hace el mundo, el movimiento de los mobs, las actualizaciones de bloques, la redstone, el crecimiento, ocurre una vez por tick, y el objetivo son 20 ticks por segundo. Así que cada tick tiene 50 milisegundos para terminar. Si se pasa, el siguiente tick empieza tarde, el TPS baja y todo el mundo se ralentiza a la vez: por eso el lag hace que los hornos vayan más lentos en lugar de que la imagen dé tirones. Escribe /tps en la consola para verlo. Paper da tres medias, de uno, cinco y quince minutos, y la de un minuto es la que responde a la pregunta «¿va mal ahora mismo?».
| TPS | Lo que dura un tick | Cómo se nota |
|---|---|---|
| 20 TPS | 50 ms | Normal. No hay nada que arreglar. |
| 18 TPS | 55,6 ms | Apenas se nota. El ritmo de la redstone empieza a desviarse. |
| 15 TPS | 66,7 ms | Los mobs van a tirones, las tolvas se quedan atrás y las granjas producen menos. |
| 10 TPS | 100 ms | Media velocidad. Hornos, crecimiento y luz del día tardan el doble. |
| 5 TPS | 200 ms | Injugable. Los bloques reaparecen después de romperlos. |
¿Cuáles son tus propias cifras?
Todo lo que sigue solo ayuda cuando sabes qué cifra se dispara en tu servidor. No hace falta buscarla a mano: el optimizador de rendimiento con IA de tu panel mide tu propio servidor en unos siete segundos, desde el tiempo por tick y el TPS hasta las entidades por tipo, los chunks, la memoria y tus plugins, y nombra al culpable en una frase, con la cifra que lo demuestra.
Tres tipos de lag
Tres problemas distintos se llaman lag, y solo uno de ellos te toca arreglar a ti. Distinguirlos primero te ahorra optimizar un servidor que nunca fue la parte lenta.
| Tipo | Dónde ocurre | Lo que puedes hacer |
|---|---|---|
| En el servidor | En la máquina. Es lo que mide el TPS. | Todo lo demás de esta página. Entidades, carga de chunks, plugins y redstone acaban todos aquí. |
| En el cliente | En el propio ordenador del jugador. Se nota como FPS bajos y tirones, no como hornos lentos. | Nada directamente, pero una distancia de visión más baja envía menos chunks y también le quita carga a él. |
| Red, o ping | Entre los dos. Es distancia y rutas, no cálculo. | Elige una región cerca de tus jugadores. Ninguna cantidad de CPU acorta un océano. |
Pregenera tus chunks
Generar terreno es lo más caro que hace un servidor. Biomas, cuevas, estructuras, minerales e iluminación se calculan la primera vez que alguien pasa por ahí, y cuatro jugadores a caballo en cuatro direcciones pueden bastar para hundir a un servidor sano hasta un TPS de una sola cifra. Hacerlo por adelantado, mientras nadie está conectado, mueve ese coste a un momento en que no molesta a nadie.
Instala Chunky
Es un simple archivo jar de plugin en la carpeta plugins, y funciona en todo nuestro software de servidor basado en Bukkit.
Pon el radio que de verdad quieres
Usa el mismo número que tu borde del mundo, en bloques. Generar mucho más allá del borde son horas de CPU para un terreno que nadie va a pisar nunca.
/chunky radius 5000Lánzalo con el servidor vacío
La generación en sí pesa: lánzala de noche o antes de dar la dirección. Si se interrumpe, sigue donde lo dejó.
/chunky start
Baja la distancia de visión y la de simulación
La distancia de visión es un radio, así que el coste de subirla crece al cuadrado y no en línea recta. Nuestro propio panel acepta de 2 a 32, y en ese rango un jugador pasa de 25 chunks a 4225. Multiplícalo por el número de personas conectadas y verás por qué es el primer ajuste que hay que tocar. Bajar de 10 a 8 casi no se nota y le quita al servidor más o menos un tercio de sus chunks.
| Distancia de visión | Chunks que mantiene un jugador | Frente a 10 |
|---|---|---|
| 2 chunksEl mínimo de nuestro panel | 25 | 6 % |
| 4 chunks | 81 | 18 % |
| 6 chunks | 169 | 38 % |
| 8 chunks | 289 | 66 % |
| 10 chunks | 441 | 100 % |
| 12 chunks | 625 | 142 % |
| 16 chunks | 1089 | 247 % |
| 32 chunksEl máximo de nuestro panel | 4225 | 958 % |
La distancia de simulación es la que da resultado. La distancia de visión decide lo que un jugador puede ver; la de simulación decide hasta dónde sigue funcionando el mundo, y por eso es la que de verdad cuesta ticks. Ponerla unos chunks por debajo de la distancia de visión es la respuesta habitual. Estos son los cinco ajustes de rendimiento que ofrece nuestro propio panel, con lo que hace cada uno.
| Ajuste | Rango | Lo que hace |
|---|---|---|
| Distancia de visión (chunks)view-distance | de 2 a 32 | Hasta dónde ven los jugadores. Más bajo es más ligero para la CPU y la memoria. |
| Distancia de simulación (chunks)simulation-distance | de 2 a 32 | Hasta dónde sigue funcionando el mundo. Por sí sola, la mayor palanca de rendimiento. |
| Alcance de entidades (%)entity-broadcast-range-percentage | de 10 a 500 | Hasta dónde se envían las entidades a los clientes. Más bajo reduce la carga de red. |
| Watchdog (ms)max-tick-time | de 1000 a 600.000 | Cuánto puede durar un tick antes de que el servidor se dé por bloqueado. Por debajo de 60.000, el servidor puede reiniciarse solo durante un lag fuerte. |
| Escritura síncrona de chunkssync-chunk-writes | Activado o desactivado | Desactivarla suele ser más rápido en un almacenamiento compartido. |
Limpia las entidades
Cada criatura, objeto en el suelo, marco, soporte de armadura y vagoneta es una entidad, y el servidor recorre la lista entera en cada tick. Quinientas gallinas apiñadas en diez bloques cuestan más que cincuenta jugadores paseando. Paper sabe aligerar todo eso sin que nadie lo note: los rangos de activación y las frecuencias de tick de paper-world-defaults.yml hacen que las entidades lejanas se actualicen menos a menudo, y los límites de aparición de bukkit.yml ponen un techo a cuántas pueden existir a la vez. Los marcos y los soportes de armadura de una construcción son los más traicioneros, porque nada los mata y nunca se mueven.
Optimiza la redstone
Una actualización de redstone se propaga en cascada: un solo cambio dispara actualizaciones de bloques en todo lo que está conectado, y un reloj rápido hace eso cientos de veces por segundo. Paper trae otra implementación de la redstone, mediblemente más barata en circuitos grandes, que merece la pena activar antes de empezar a prohibir mecanismos. Las tolvas merecen su propia regla: cada una comprueba en cada tick si hay objetos, se mueva algo o no, así que un sistema de clasificación de doscientas tolvas funciona todo el día a precio completo.
Usa Spark para encontrar el cuello de botella
Todo lo anterior es una suposición hasta que mides. Spark es un perfilador que te dice adónde se han ido los ticks: el tick de las entidades, la carga de chunks, el gestor de eventos de un plugin o el recolector de basura. Lánzalo mientras el servidor sufre de verdad, déjalo funcionar unos minutos, detenlo, y te da un enlace con el detalle. Paper lo trae incluido desde la 1.21, así que en la mayoría de nuestros servidores no hay nada que instalar antes.
/spark profiler start
/spark profiler stop
El lag que viene de los plugins
El número de plugins no es la cifra que importa. Quince plugins bien elegidos son mejores que cuarenta de los que la mitad repiten trabajo, pero un solo plugin que recorre los chunks en el hilo principal hace más daño que todos los demás juntos. Si un perfil de Spark pone un plugin en cabeza, busca primero una versión más reciente, después una opción de configuración que apague la parte cara y, por último, otra cosa que haga el mismo trabajo. Repasar la lista dos veces al año y quitar lo que nadie usa cuesta una hora y se paga solo.
Cuándo pasar a un plan mayor
Si has pregenerado tus chunks, has reducido la distancia de simulación, has aligerado las entidades y has perfilado con Spark, y la media de un minuto sigue sin aguantar 20, entonces lo que se queda corto es la máquina, no los ajustes. Estar todo el día por encima del ochenta por ciento de memoria, o picos de CPU en una partida normal, esa es la señal. Nuestros siete planes dicen todos lo que te dan, y nuestra guía sobre la memoria dice cuál encaja con cada tipo de servidor.
| Plan | vCPU | Memoria | Almacenamiento |
|---|---|---|---|
| Mini | 2 vCPU | 4 GB |  60 GB SSD |
| Starter | 2 vCPU | 8 GB |  60 GB SSD |
| Standard | 3 vCPU | 12 GB |  75 GB SSD |
| Premium | 4 vCPU | 24 GB |  150 GB SSD |
| Ultimate | 6 vCPU | 48 GB |  300 GB SSD |
| Enterprise | 8 vCPU | 64 GB |  375 GB SSD |
| Dedicated | 9 vCPU | 96 GB |  450 GB SSD |
Lo que viene con cada plan, en cada nivel, está en la lista completa de funciones.
Las preguntas que surgen cuando el servidor va lento
¿Más RAM arregla un TPS bajo?
Solo si el problema era la memoria. El TPS mide la CPU: un servidor puede usar solo la mitad de su memoria y aun así perder ticks porque un plugin hace demasiado en cada uno. Perfila primero y decide después qué comprar.
¿Qué distancia de visión elijo?
Entre 6 y 10 para la mayoría de los servidores, con la distancia de simulación unos chunks por debajo. La tabla de arriba muestra lo que cuesta cada paso, para que elijas una cifra en lugar de copiar una.
¿A partir de cuántos jugadores empieza a ir con lag un servidor?
Esa cifra no existe. Veinte jugadores repartidos por un mundo ya explorado cuestan menos que cinco construyendo redstone en un solo chunk. Lo que decide es lo que hacen los jugadores, no cuántos son.
¿Sirven de algo los reinicios programados?
Tapan una fuga más que arreglarla, pero funcionan: un reinicio cada noche borra las entidades acumuladas y devuelve la memoria que el recolector de basura nunca recuperó. Bueno tenerlo, pero no algo en lo que confiar.
¿Es seguro usar Spark en un servidor en producción?
Sí, está hecho para eso. Toma muestras en lugar de instrumentar, así que la sobrecarga es baja, y hay que lanzarlo durante un lag real para que el informe signifique algo.
Planes con margen para crecer
Mini4 GB6,95 €Plazo de 24 meses · 6,95 €/mes, y el mismo precio cada vez que se renuevaStarter8 GB10,95 €Plazo de 24 meses · 10,95 €/mes, y el mismo precio cada vez que se renuevaStandard12 GB14,95 €Plazo de 24 meses · 14,95 €/mes, y el mismo precio cada vez que se renuevaVer los 21 planes de las tres edicionesResponde a cuatro preguntas y obtén el tamaño correcto
El número de chunks de esta página es el cuadrado de dos veces la distancia de visión más uno, calculado sobre el rango que permite nuestra propia pantalla de ajustes, y la tabla de ajustes copia esa pantalla: las claves y los límites se leen de ella en el momento en que se construye la página.
Cuando ya está todo ajustado y sigue yendo lento
Pregenera los chunks, baja la distancia de visión, aligera las entidades y vuelve a medir. Si el tiempo por tick sigue cerca de cincuenta mientras sobra memoria, ninguno de los cuatro pasos de arriba es ya la respuesta: a un núcleo le falta tiempo. Para ese caso existe la línea Performance, en un AMD Ryzen 9 5900X en Alemania o un AMD Ryzen 9 7950X con RAM DDR5 en Polonia, con la misma memoria que tienes hoy.
Archivos de configuración y memoria
Buena parte del lag de un servidor se decide en sus archivos de configuración, y Every Paper.yml Setting Explained (2026) explica cada opción del más grande de ellos. Cuando el límite es más bien la memoria, How to Reduce RAM Usage on Your Minecraft Server enseña adónde se va. Las dos guías están en inglés.
Escrito y revisado por el equipo de Astroworld Hosting. Última revisión: 6 de septiembre de 2026.
Entrega: la mayoría de los servidores se entregan al instante y funcionan a los pocos segundos del pago; el resto llega en menos de 60 minutos durante el día y en menos de 12 horas por la noche.