Qué cuesta cada ajuste de tu servidor de Minecraft: probé 58 configuraciones

Lo que más lag causa en un servidor de Minecraft no suele ser lo que se cree. En 58 pruebas con un servidor Paper 26.3, la distancia de vista costó memoria y casi nada de tiempo de proceso, la de simulación costó tiempo de proceso, mil gallinas juntas llevaron cada paso del servidor a 136 milisegundos y duplicar la RAM no mejoró nada. De siete plugins populares, solo uno se notó.

Lo medí para el vídeo «Subí la distancia de renderizado a 32 y mi servidor de Minecraft se murió». Aquí tienes las cifras ordenadas y lo que conviene tocar primero.

Cómo se midió

Un servidor Paper 26.3 sin plugins (salvo en las pruebas de plugins), limitado a 4 hilos de un Ryzen 7 5700X y con 4 GB de memoria. Ocho jugadores de prueba, que son bots quietos en modo creativo y de noche, sobre un mundo pregenerado que se restauraba idéntico antes de cada prueba. Cada medida dura 60 segundos tras un calentamiento de 75.

La cifra principal es el tic: lo que tarda el servidor en procesar un paso del juego. Tiene 50 milisegundos por tic para ir a 20 TPS (ticks por segundo); si tarda más, aparece el lag. También medí la memoria ocupada después de cada recolección de basura de Java, que indica cuánta RAM necesita el servidor de verdad.

Resultados de un vistazo

Distancia de vista y de simulación: no cuestan lo mismo

La distancia de vista decide cuántos chunks recibe el jugador. Subirla casi no cambió el tic (de 14,3 a 17,6 ms entre 4 y 24), pero la memoria se multiplicó por cinco. Con 32 y 4 GB, la memoria se llenó, el servidor pasó más de un minuto en pausas y el tic llegó a 508 ms.

La distancia de simulación decide cuántos chunks siguen funcionando: mobs, cultivos y redstone. Bajarla de 12 a 2 redujo el tic de 20,6 a 11,5 ms sin tocar la memoria. Tienes el detalle y los valores recomendados en view-distance y simulation-distance: qué cuesta cada una.

Entidades: mil gallinas y un limitador que no limitaba

Con ocho jugadores conectados, invoqué gallinas todas juntas en un punto. Con 100 el tic fue de 15,3 ms; con 300, de 24,5; con 600, de 56,9, ya por encima de los 50; y con 1.000, de 135,6.

El plugin ChunkSpawnerLimiter limita los mobs por chunk, pero con su configuración por defecto no hizo nada con las 600 gallinas invocadas por comando: 57,0 ms, igual que sin él. El motivo es que el comando /summon no estaba entre los motivos de aparición que controla. Al añadirlo a la lista, las mismas 600 gallinas bajaron a 14,4 ms, un 75 % menos. Una granja real nace por cría o por huevos, que sí vienen en su lista por defecto, así que esta prueba muestra un límite del plugin más que un fallo.

¿Más RAM arregla el lag? No

Con la misma carga y la vista a 24, cuatro gigas dieron 19,3 ms por tic y ocho gigas, 20,4. El doble de memoria no bajó el tic. Con dos gigas, en cambio, el servidor dejó de responder por culpa de las pausas de la recolección de basura, más de 100 segundos en total. La RAM evita que el servidor se ahogue, pero no lo hace más rápido.

Terreno nuevo y Chunky

Generar terreno nuevo no subió el tic (21,2 frente a 20,7 ms con el mundo ya generado), porque la generación va en otros hilos. Pero Java gastó el doble de CPU, 1,73 núcleos frente a 0,87, y los jugadores recibieron un 26 % menos de chunks. El plugin Chunky pregeneró 3.721 chunks en 46 segundos, a 81 por segundo con 4 hilos, sin ningún jugador conectado: compensa hacerlo antes de abrir el servidor.

Plugins: casi ninguno se nota

Con 96 jugadores de prueba, LuckPerms, WorldGuard, ViaVersion y GriefPrevention quedaron entre 0 y 1,4 % de diferencia con el servidor sin plugins, dentro del ruido de la medida. EssentialsX incluso salió un 6 % mejor, que tampoco hay que interpretar como mejora real. El único que se notó fue GrimAC: +7,6 % de tic y 2,3 veces la memoria. Los datos completos están en qué plugins ralentizan un servidor de Minecraft.

¿Cuántos jugadores aguanta?

Con los ajustes por defecto (vista 10 y simulación 10), el tic cruzó los 50 ms con unos 134 jugadores de prueba. Con vista 8, simulación 4 y un limitador de entidades, con unos 145: un 8 % más. Con 25 jugadores, el servidor ajustado gastó un 24 % menos de tic (14,5 frente a 19,1 ms). Mejora real, pero modesta: ningún ajuste convierte un servidor de 4 hilos en uno enorme.

Qué tocar primero

1. Baja la distancia de simulación si el tic va justo: es el ajuste que más tiempo de proceso ahorró.
2. Vigila la memoria al subir la distancia de vista. Con 4 GB, 24 funcionó y 32 no.
3. Limita las entidades por chunk con un plugin que cubra cómo nacen tus mobs.
4. No compres más RAM esperando menos lag. Solo evita que el servidor se ahogue.
5. Pregenera el mundo antes de abrirlo si esperas que la gente explore.
6. Mide antes de culpar a un plugin. Con /tick query ves el tiempo medio por tic.

Si quieres más contexto, tienes la guía general de cómo optimizar un servidor de Minecraft para muchos jugadores sin lag y la de los mejores plugins para un servidor de Minecraft.

Límites de esta prueba

Los bots estaban quietos: representan un suelo de carga, no un techo, y con jugadores reales moviéndose y construyendo el techo será más bajo. Todo se midió en una sola máquina con un Ryzen 7 5700X, la base varió entre 13,2 y 14,4 ms entre repeticiones (una vez, 17,5), y las diferencias de 3 % o menos no son fiables. No es una prueba de proveedores de hosting.

Si buscas un servidor donde jugar sin montar nada, el directorio de 40servidoresMC tiene cientos de servidores hispanos con su estado y sus jugadores en tiempo real.

Imagen de portada generada con IA para 40servidoresMC. Es una ilustración, no una captura de las pruebas.