Cómo optimizar su servidor de Minecraft sin romper sus granjas

Reducir simulation-distance no es lo mismo que reducir view-distance. Una modifica el área centrada en el jugador que el servidor simula; la otra controla cuántos datos de terreno se envían a los jugadores. Un paisaje lejano puede seguir siendo visible aunque una granja situada allí ya no se comporte como su propietario espera.

Esa distinción importa más que encontrar una configuración etiquetada como “optimizada”. Un servidor más tranquilo no supone gran mejora si los aldeanos dejan de reponer existencias o si un punto AFK consolidado deja de funcionar. El objetivo es eliminar el trabajo del que su comunidad puede prescindir y comprobar después que la jugabilidad que quería conservar sigue funcionando.

Este tutorial cubre los servidores modernos de Minecraft Java Edition. Los ajustes de distancia se aplican a Vanilla, Spigot y Paper; los comandos de plugins y los ajustes YAML se indican por separado. No es una receta universal para Bedrock, modpacks o Folia. Contraste la documentación con la versión exacta de su servidor: las referencias actuales pueden describir versiones más recientes, y ni los valores predeterminados ni la estructura de los archivos se mantienen fijos para siempre.

1. Mida el problema mientras ocurre#

Anote su versión de Minecraft, el software y la compilación del servidor, el número de jugadores y lo que están haciendo cuando se produce la ralentización. Una sala de comercio concurrida y un grupo explorando terreno nuevo son cargas de trabajo distintas. Analizar un servidor vacío no explicará ninguna de las dos; la documentación de Paper exige expresamente que el problema esté ocurriendo durante la recogida de datos.

En Paper, spark viene incluido desde la versión 1.21. En Spigot, instale primero un plugin spark independiente compatible; los siguientes comandos no vienen integrados en un servidor Vanilla sin modificar.

Ejecute esto dentro del juego con los permisos necesarios:

/spark tps
/spark profiler start --timeout 600

El comando del profiler graba durante diez minutos y devuelve la URL de un informe. Guarde ese informe junto con su configuración y sus notas sobre la carga de trabajo.

Con la tasa de ticks normal, Minecraft apunta a 20 TPS, lo que deja 50 milisegundos por tick. El MSPT describe cuánto tardan los ticks, por lo que revela una presión que una lectura de TPS por sí sola puede ocultar. Compare el MSPT mediano y el del percentil 95: este último ayuda a detectar ticks lentos recurrentes, pero puede pasar por alto los picos poco frecuentes. Compruebe también el máximo, en lugar de tratar un percentil saludable como prueba de que nada se detuvo.

Para los problemas intermitentes, el monitor de ticks de spark puede señalar los ticks que superan ese presupuesto:

/spark tickmonitor --threshold-tick 50

Anote lo que ocurrió en ese mismo momento. Si los tiempos de tick se mantienen saludables durante la queja, investigue la tasa de fotogramas del cliente o las condiciones de red antes de sacrificar la jugabilidad del servidor.

2. Haga una copia de seguridad e identifique qué ajustes se aplican realmente#

Antes de editar, detenga el servidor de forma limpia y haga una copia de seguridad de los mundos, los archivos de configuración y los datos de los plugins. Guarde la copia fuera del directorio del servidor en producción y compruebe que puede restaurarla. Una copia de la configuración facilita la reversión; una copia del mundo protege el trabajo que hay detrás.

Use un editor de texto, conserve la indentación del YAML y cambie una sola cosa por experimento. Después, inicie el servidor con normalidad y revise el log de arranque en busca de errores de configuración. No use /reload ni un cargador en caliente de plugins como atajo; recargar plugins puede dejar dependencias y estados inconsistentes.

En Vanilla, empiece por server.properties. En Spigot y Paper, revise también spigot.yml: los ajustes de distancia por mundo pueden sobrescribir el archivo de propiedades.

Este fragmento muestra la herencia, no un preajuste de rendimiento:

world-settings:
  default:
    view-distance: default
    simulation-distance: default

Aquí, default indica a estas opciones que usen server.properties. Combine las claves con la sección existente; no reemplace todo el archivo ni añada un segundo bloque world-settings. Revise también las secciones de mundos con nombre, porque un valor específico de un mundo puede sobrescribir el ajuste compartido.

Si sustituye anulaciones numéricas por herencia, trátelo como un cambio aparte y registre una nueva línea base. De lo contrario, podría alterar varias distancias efectivas antes de su primera prueba controlada.

3. Separe la visibilidad del terreno de la simulación#

Ambas distancias se miden en chunks alrededor del jugador, no en bloques ni como un diámetro.

• view-distance controla la cantidad de datos del mundo enviados al cliente. Reducirla sacrifica la visibilidad del terreno lejano a cambio de menos trabajo asociado a mantener disponible esa vista.
• simulation-distance controla el área de ticks centrada en el jugador. Reducirla puede disminuir el trabajo de simulación, pero también cambia el área en la que funcionan las granjas y entidades cercanas.

La distancia de visión no es gratuita solo porque parte del terreno quede fuera de la distancia de simulación. Igualmente, reducirla no sustituye arreglar un plugin costoso. Elija el primer experimento a partir del perfil y del compromiso de jugabilidad que pueda aceptar.

Pruebe un único cambio de distancia#

Supongamos que su server.properties actual contiene:

view-distance=10
simulation-distance=10

Si el perfil apunta a trabajo de ticks en las áreas cargadas, un experimento consiste en mantener sin cambios la distancia de visión y reducir un poco la distancia de simulación:

view-distance=10
simulation-distance=8

Estos números son ilustrativos, no valores predeterminados universales ni un preajuste probado de SharpHeberg. Si su distancia de visión actual es distinta, deje su propio valor como está. Reinicie de forma limpia, reproduzca la carga de trabajo original y recoja otro informe antes de hacer cualquier reducción adicional.

Si, en cambio, el perfil sugiere que el problema es mantener o enviar terreno lejano, pruebe la distancia de visión por separado. No reduzca ambos ajustes a la vez para luego intentar adivinar cuál ayudó.

La distancia de simulación no es un reglamento completo para las granjas. Los tickets de chunk, que mantienen los chunks cargados por motivos concretos, y los requisitos de proximidad del jugador difieren según las mecánicas y las versiones. “Cargado” no garantiza que el spawn, el crecimiento de cultivos, las entidades y las entidades de bloque se comporten igual. Compruebe los requisitos de su granja concreta en lugar de suponer que una única distancia garantiza su funcionamiento.

El spawn y el despawn naturales también tienen sus propias reglas de distancia; el mob-spawn-range de Spigot y los ajustes de despawn de Paper añaden más controles. Si una granja deja de funcionar tras el experimento, restaure primero la distancia anterior. No compense de inmediato cambiando varios ajustes de spawn.

4. En Spigot o Paper, inspeccione el trabajo de las entidades antes de recortar rangos#

Si el perfil apunta al procesamiento de entidades, inspeccione el área afectada. Busque objetos soltados que se acumulan, corrales abarrotados o una sala de comercio que hace trabajo innecesario. Coordínese con los propietarios antes de modificar construcciones. Reducir una fuente identificada de trabajo excesivo es más fácil de evaluar que debilitar el comportamiento de las entidades en todas partes.

Dos opciones de spigot.yml con nombres parecidos tienen funciones distintas:

Son controles de entidades, no las distancias basadas en chunks de más arriba. Un rango de seguimiento menor puede hacer que los mobs aparezcan de golpe; no equivale a reducir la carga de trabajo de su IA.

Los cambios de activación requieren un cuidado especial en torno a las granjas de hierro y los aldeanos. Las guías de la comunidad documentan granjas rotas y problemas de reposición por cambios demasiado agresivos de activación o de aldeanos inactivos. No toque estos ajustes salvo que el análisis de rendimiento justifique el compromiso y, en ese caso, pruebe la categoría de entidades afectada en lugar de copiar un preajuste completo.

La misma cautela se aplica a nerf-spawner-mobs, a la temporización de los hoppers y a los cambios en la fusión de objetos: alteran el comportamiento, no solo el consumo de recursos. No recorte a ciegas los límites de mobs ni instale un borrado programado de entidades como primera respuesta al lag.

5. Trate los ajustes de Paper como controles específicos de cada versión#

Paper tiene capas de configuración adicionales. Su estructura documentada incluye config/paper-global.yml para los ajustes globales y config/paper-world-defaults.yml para los ajustes de mundo compartidos. El paper-world.yml de un mundo puede sobrescribir esos valores predeterminados.

Localice ese archivo de sobrescritura con la documentación de su compilación. Las estructuras de directorios de mundos y dimensiones varían; copiar una ruta de un tutorial antiguo puede llevarle al lugar equivocado. Copie solo los ajustes que quiera sobrescribir, no el archivo de valores predeterminados completo.

Paper ofrece controles de spawn, despawn, colisiones y comportamiento de los hoppers. Son opciones para un problema identificado, no una lista de comprobación que haya que completar. Por ejemplo, desactivar el evento de movimiento del hopper puede romper plugins de protección que dependen de él. Una pequeña mejora de tiempos no justificaría saltarse en silencio una regla del servidor.

La referencia de spigot.yml citada la mantiene Paper e incluye comportamientos específicos de Paper. No dé por hecho que todas las opciones anidadas que documenta existen o se comportan igual en Spigot puro. Consulte la configuración generada para su implementación y versión antes de añadir una clave.

6. Siga el perfil más allá de los ajustes de distancia#

Investigue el trabajo de los plugins#

Si el informe apunta a una tarea de un plugin, guarde el informe y revise la configuración, la compatibilidad y las notas de versión de ese plugin. Paper recomienda expresamente compartir un informe de spark relevante con los desarrolladores de plugins al investigar problemas de rendimiento.

Reproduzca el problema en una copia de pruebas con copia de seguridad siempre que sea posible. Cambie una función o un plugin a la vez, respetando las dependencias, y repita después la misma actividad. Evite desactivar los plugins de protección o de economía en el servidor en producción solo para ver si sube el TPS.

Base también en datos el ajuste de Java y de memoria. Revise el comportamiento del recolector de basura y los requisitos de Java de la compilación exacta de su servidor antes de cambiar las opciones de arranque. Una colección copiada de flags de GC no es un paso de optimización universal.

Pregenere solo cuando la generación sea el problema#

Cuando la ralentización coincide con la exploración, compare el desplazamiento por terreno existente con el desplazamiento hacia terreno nuevo. Si el análisis de rendimiento indica que la generación de chunks es el cuello de botella, la pregeneración adelanta ese trabajo de generación al juego normal. Chunky ofrece herramientas para este fin.

Elija el área y las dimensiones previstas, compruebe la capacidad de disco y de copias de seguridad, y programe el trabajo fuera de las horas de más actividad. Pruebe primero un área limitada. La pregeneración no elimina el coste de cargar o enviar los chunks existentes, ni el de ejecutar las granjas que hay en ellos.

Las guías de la comunidad discrepan sobre hasta qué punto debe recomendarse la pregeneración en los servidores modernos. Trátela como una respuesta a una presión de generación medida, no como un mantenimiento obligatorio para toda instalación de Paper.

7. Compruebe la jugabilidad antes de conservar el cambio#

Repita la carga de trabajo original con un número y una distribución de jugadores comparables. Guarde juntos los informes de spark de antes y después, la diferencia de configuración y las notas. Repita la comparación si las condiciones han cambiado sustancialmente.

Después, pruebe el servidor tal como lo usan los jugadores:

• Ponga en marcha las granjas importantes desde sus posiciones AFK habituales, incluidas la recogida y el transporte.
• Compruebe los intercambios y la reposición de existencias de los aldeanos durante un ciclo de trabajo normal.
• Ejecute los clasificadores con hoppers y los relojes el tiempo suficiente para detectar objetos perdidos o tiempos alterados.
• Compruebe la visibilidad y el comportamiento de los mobs durante los desplazamientos, y pruebe cada mundo afectado.

Conserve un cambio solo si la mejora medida es útil y el compromiso en la jugabilidad es aceptable. Si el beneficio no está claro, restaure el valor anterior. No desactive nunca el guardado para que una gráfica de rendimiento tenga mejor aspecto.

Si el cuello de botella restante parece ser la capacidad del hosting, use el informe para orientar esa conversación. Puede consultar el hosting de Minecraft de SharpHeberg junto con su carga de trabajo y sus requisitos. Las decisiones de hosting y los cambios de configuración merecen la misma prueba: ¿funciona mejor el servidor sin perder la forma en que juega su comunidad?

Lectura relacionada: El coste real de un servidor de Minecraft de alto rendimiento en 2025. Trate cualquier precio de ese artículo anterior como histórico, no como tarifas actuales.

Fuentes#

Paper — server.properties

Paper — referencia de spigot.yml

Paper — configuración del mundo

Paper — análisis de rendimiento con spark

Minecraft optimization — guía de la comunidad

spark — encontrar picos de lag

Chunky — documentación

Paper-chan — guía de optimización

spark — TPS y MSPT

Paper — código fuente de la documentación de configuración