Tú decides qué servicios podemos activar para análisis, personalización y contenido externo.
Utilizamos cookies y tecnologías similares en nuestro sitio web para personalizar el contenido, integrar medios externos y comprender mejor el uso de determinadas secciones.
Cookies necesarias
Estas entradas garantizan funciones básicas como la seguridad, la estabilidad y el procesamiento de formularios.
Tus datos pueden tratarse con tu consentimiento o sobre la base de intereses legítimos. En la configuración de cookies puedes rechazar cada categoría opcional o autorizarla expresamente.
Algunos servicios procesan datos personales en terceros países. Al dar tu consentimiento, también aceptas esta transferencia. Encontrarás más información en nuestra política de privacidad.
Puedes volver a abrir y modificar tu selección en cualquier momento. · 1.0.2
Minecraft: Optimización del rendimiento del servidor
Descubre cómo optimizar los servidores de Minecraft para mejorar el rendimiento y disfrutar de una experiencia de juego más fluida con estos consejos de configuración → Más información
10 de noviembre de 202622 min de lectura4 Visitas0 útil
¿En qué consiste exactamente la optimización?
La optimización es un aspecto importante para que los servidores de Minecraft funcionen sin problemas. Si tienes un servidor público, debes dedicarle suficiente tiempo. Solo con tiempo y pruebas podrás obtener el mejor resultado. Por eso, no es necesario seguir esta guía al pie de la letra: su objetivo es ayudarte a avanzar en la dirección correcta.
En la mayoría de los casos, optimizar un servidor implica cambiar muchos ajustes, lo que a veces modifica considerablemente su comportamiento. Entre otras cosas, se reducen algunos ajustes para aliviar la carga del servidor y mejorar así el rendimiento. Sin embargo, para no perjudicar demasiado la experiencia general de juego, siempre debes encontrar un punto medio.
Vanilla
Lamentablemente, las opciones para optimizar un servidor Vanilla son muy limitadas, ya que hay pocos ajustes disponibles. Intentaremos darle un poco más de potencia al servidor Vanilla con las siguientes medidas:
Distancia de renderizado
Una medida muy habitual consiste en reducir la distancia de renderizado. El valor predeterminado es de 10 chunks, pero muchos jugadores usan bastantes menos, por ejemplo, entre 6 y 8. Algunos se exceden con la cantidad de chunks y la configuran, por ejemplo, en 32. Esto significa que el servidor debe cargar y procesar todos esos chunks, lo que consume mucho rendimiento.
En un servidor Vanilla, puedes modificar la distancia de renderizado en el archivo de configuración "server.properties" cambiando el valor "view-distance". Para no limitar demasiado la experiencia de juego, recomendamos establecerlo en 5-6, lo que puede reducir la carga del servidor hasta en un 50 %.
Ya tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Compresión de datos
En un servidor se intercambian datos constantemente entre el servidor y los jugadores conectados. Los movimientos de los jugadores se envían al servidor, que a su vez los reenvía a los demás jugadores. Las acciones de los jugadores y los eventos del mundo, como las explosiones, también forman parte de los datos que se transmiten continuamente.
Para hacer este intercambio más eficiente, se puede duplicar el tamaño de los datos comprimidos, de modo que el servidor solo tenga que realizar el 50 % del trabajo para intercambiar los mismos datos con los jugadores. Para ello, hay que modificar el valor "network-compression-threshold" en el archivo de configuración "server.properties". Se recomienda establecerlo en 512. También tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
FAQ
Preguntas frecuentes
La distancia de renderizado predeterminada es de 10 chunks. Reducirla a 5-6 en server.properties (valor view-distance) puede aliviar la carga del servidor hasta en un 50 % sin limitar demasiado la experiencia de juego.
La guía incluye optimizaciones para servidores Vanilla, Forge, Bukkit, Spigot y Paper Spigot. Paper Spigot ofrece más opciones adicionales, como límites de aparición, alcances de activación de entidades, generadores de mobs y ajustes de redstone.
Un servidor Vanilla ofrece menos opciones de configuración que plataformas como Spigot o Paper Spigot, por lo que la optimización se limita principalmente a la distancia de renderizado y la compresión de datos.
No. La guía es una ayuda, no una receta que debas seguir obligatoriamente. Como la optimización puede cambiar mucho el comportamiento del servidor, tómate el tiempo necesario para hacer pruebas y encontrar un buen equilibrio entre rendimiento y experiencia de juego.
Comentarios
¿Te resultó útil este artículo?
Tus comentarios nos ayudan a priorizar y mejorar los contenidos.
0 de 0 Las valoraciones consideraron útil este artículo.
Ayuda personalizada
¿No te basta con la guía?
Nuestro equipo de soporte de ZAP conoce tu producto. Describe brevemente tu consulta y te ayudaremos personalmente.
Zappy conoce esta guía y te responde directamente en el chat.
Navegación
Minecraft
Alojamiento de servidores desde 2,49 € / mes, disponible al instante, con protección DDoS incluida.
Al igual que en Vanilla, las opciones que se pueden configurar directamente en el servidor son algo limitadas, ya que solo hay disponibles archivos de configuración muy pequeños. Sin embargo, es posible instalar mods adicionales para reducir un poco la carga del servidor.
Precarga de chunks
Una forma de reducir la carga del servidor es precargar chunks. Así, cuando haya jugadores conectados, el servidor solo tendrá que cargar los datos de los chunks guardados, en lugar de crear y generar los chunks desde cero. Lo ideal es iniciar este proceso por la noche, antes de terminar el día.
Para ello, hay que instalar un mod adicional. Puedes descargar un mod muy adecuado aquí.
Después, puedes instalarlo en el servidor como de costumbre, tal como se describe en nuestras guías.
Antes de reiniciar el servidor, asegúrate de que "max-tick-time" esté establecido en "-1" en "server.properties". De lo contrario, el servidor podría bloquearse. También recomendamos disponer de al menos entre 8 y 10 GB de RAM, ya que el proceso consume mucha memoria. Puedes aumentar temporalmente la RAM durante la noche y volver a reducirla después.
Información
Ten en cuenta que el mod mencionado puede no ser compatible con tu versión de Forge y que el proceso puede variar si utilizas otro mod.
Cuando hayas iniciado el servidor con el mod, abre la consola. Recomendamos establecer un límite del mundo con un radio de 16.000 bloques. Para ello, ejecuta los siguientes comandos en orden:
worldborder center 0 0
worldborder set 16000
Información
Si es necesario, sustituye las coordenadas por las del centro de tu mundo para evitar que quede «recortado» (por ejemplo, si ya se ha construido allí).
Una vez establecido el límite, puedes iniciar la precarga. Para ello, ejecuta el siguiente comando:
pregen gen startWorldBorder
Ahora se precargarán uno a uno todos los chunks que se encuentren dentro del límite. El proceso puede tardar hasta 8 horas, según la cantidad de mods instalados. La consola mostrará periódicamente el progreso mediante mensajes informativos. Cuando termine el proceso, también aparecerá un aviso en la consola.
Información
El mod puede permanecer instalado en el servidor después de completar el proceso. Seguirá optimizando chunks mientras el servidor esté en funcionamiento y también funciona cuando no hay ningún jugador conectado.
Bukkit
Distancia de renderizado
Una medida muy habitual consiste en reducir la distancia de renderizado. El valor predeterminado es de 10 chunks, pero muchos jugadores usan bastantes menos, por ejemplo, entre 6 y 8. Algunos se exceden con la cantidad de chunks y la configuran, por ejemplo, en 32. Esto significa que el servidor debe cargar y procesar todos esos chunks, lo que consume mucho rendimiento.
Puedes modificar la distancia de renderizado de un servidor Bukkit en el archivo de configuración "server.properties" cambiando el valor "view-distance". Para no limitar demasiado la experiencia de juego, recomendamos establecerlo en 5-6, lo que puede reducir la carga del servidor hasta en un 50 %.
Ya tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Compresión de datos
En un servidor se intercambian datos constantemente entre el servidor y los jugadores conectados. Los movimientos de los jugadores se envían al servidor, que a su vez los reenvía a los demás jugadores. Las acciones de los jugadores y los eventos del mundo, como las explosiones, también forman parte de los datos que se transmiten continuamente.
Para hacer este intercambio más eficiente, se puede duplicar el tamaño de los datos comprimidos, de modo que el servidor solo tenga que realizar el 50 % del trabajo para intercambiar los mismos datos con los jugadores. Para ello, hay que modificar el valor "network-compression-threshold" en el archivo de configuración "server.properties". Se recomienda establecerlo en 512. También tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Límites de aparición
En este paso se reducen un poco las tasas generales de aparición de mobs en el servidor. La diferencia con respecto a los valores predeterminados apenas se nota. Sin embargo, en algunos casos, por ejemplo, en las granjas de mobs, es posible que la granja no funcione como esperabas.
Para modificar estos ajustes, hay que editar el archivo de configuración "bukkit.yml". Cambia los siguientes valores en "spawn-limits":
monsters: 50 #Predeterminado: 70
animals: 10 #Predeterminado: 15
water-animals: 3 #Predeterminado: 5
ambient: 4 #Predeterminado: 15
Información
Spigot
Distancia de renderizado
Una medida muy habitual consiste en reducir la distancia de renderizado. El valor predeterminado es de 10 chunks, pero muchos jugadores usan bastantes menos, por ejemplo, entre 6 y 8. Algunos se exceden con la cantidad de chunks y la configuran, por ejemplo, en 32. Esto significa que el servidor debe cargar y procesar todos esos chunks, lo que consume mucho rendimiento.
En un servidor Spigot, puedes modificar la distancia de renderizado en el archivo de configuración "spigot.yml" cambiando el valor "view-distance". Para no limitar demasiado la experiencia de juego, recomendamos establecerlo en 5-6, lo que puede reducir la carga del servidor hasta en un 50 %.
Información
Si lo prefieres, también puedes establecer el valor en 4. Esto puede ayudar mucho a reducir el lag, por ejemplo, en servidores de mundos de granjas que funcionan con la versión 1.13 o posterior.
Compresión de datos
En un servidor se intercambian datos constantemente entre el servidor y los jugadores conectados. Los movimientos de los jugadores se envían al servidor, que a su vez los reenvía a los demás jugadores. Las acciones de los jugadores y los eventos del mundo, como las explosiones, también forman parte de los datos que se transmiten continuamente.
Para hacer este intercambio más eficiente, se puede duplicar el tamaño de los datos comprimidos, de modo que el servidor solo tenga que realizar el 50 % del trabajo para intercambiar los mismos datos con los jugadores. Para ello, hay que modificar el valor "network-compression-threshold" en el archivo de configuración "server.properties". Se recomienda establecerlo en 512. También tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Límites de aparición
En este paso se reducen un poco las tasas generales de aparición de mobs en el servidor. La diferencia con respecto a los valores predeterminados apenas se nota. Sin embargo, en algunos casos, por ejemplo, en las granjas de mobs, es posible que la granja no funcione como esperabas.
Para modificar estos ajustes, hay que editar el archivo de configuración "bukkit.yml". Cambia los siguientes valores en "spawn-limits":
monsters: 50 #Predeterminado: 70
animals: 10 #Predeterminado: 15
water-animals: 3 #Predeterminado: 5
Paper Spigot
Información
Desde Paper 1.19 ya no existe un único archivo "paper.yml". El archivo anterior se dividió en varios archivos dentro de la carpeta "config": "paper-global.yml" (ajustes para todo el servidor) y "paper-world-defaults.yml" (valores predeterminados para todos los mundos, que se pueden sobrescribir por mundo en un archivo "paper-world.yml" propio). "bukkit.yml" y "spigot.yml" no se ven afectados y se siguen utilizando igual que antes. Como Paper modifica de vez en cuando algunos nombres y rutas de los ajustes, si encuentras alguna diferencia, consulta los comentarios del archivo de configuración correspondiente o la documentación oficial de Paper.
Distancia de renderizado
Una medida muy habitual consiste en reducir la distancia de renderizado. El valor predeterminado es de 10 chunks, pero muchos jugadores usan bastantes menos, por ejemplo, entre 6 y 8. Algunos se exceden con la cantidad de chunks y la configuran, por ejemplo, en 32. Esto significa que el servidor debe cargar y procesar todos esos chunks, lo que consume mucho rendimiento.
En un servidor (Paper) Spigot, puedes modificar la distancia de renderizado en el archivo de configuración "spigot.yml" cambiando el valor "view-distance". Para no limitar demasiado la experiencia de juego, recomendamos establecerlo en 5-6, lo que puede reducir la carga del servidor hasta en un 50 %.
Información
Si lo prefieres, también puedes establecer el valor en 4. Esto puede ayudar mucho a reducir el lag, por ejemplo, en servidores de mundos de granjas que funcionan con la versión 1.13 o posterior.
Compresión de datos
En un servidor se intercambian datos constantemente entre el servidor y los jugadores conectados. Los movimientos de los jugadores se envían al servidor, que a su vez los reenvía a los demás jugadores. Las acciones de los jugadores y los eventos del mundo, como las explosiones, también forman parte de los datos que se transmiten continuamente.
Para hacer este intercambio más eficiente, se puede duplicar el tamaño de los datos comprimidos, de modo que el servidor solo tenga que realizar el 50 % del trabajo para intercambiar los mismos datos con los jugadores. Para ello, hay que modificar el valor "network-compression-threshold" en el archivo de configuración "server.properties". Se recomienda establecerlo en 512. También tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Distancia de renderizado
Una medida muy habitual consiste en reducir la distancia de renderizado. El valor predeterminado es de 10 chunks, pero muchos jugadores usan bastantes menos, por ejemplo, entre 6 y 8. Algunos se exceden con la cantidad de chunks y la configuran, por ejemplo, en 32. Esto significa que el servidor debe cargar y procesar todos esos chunks, lo que consume mucho rendimiento.
Puedes modificar la distancia de renderizado de un servidor Forge en el archivo de configuración "server.properties" cambiando el valor "view-distance". Para no limitar demasiado la experiencia de juego, recomendamos establecerlo en 5-6, lo que puede reducir la carga del servidor hasta en un 50 %.
Ya tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Compresión de datos
En un servidor se intercambian datos constantemente entre el servidor y los jugadores conectados. Los movimientos de los jugadores se envían al servidor, que a su vez los reenvía a los demás jugadores. Las acciones de los jugadores y los eventos del mundo, como las explosiones, también forman parte de los datos que se transmiten continuamente.
Para hacer este intercambio más eficiente, se puede duplicar el tamaño de los datos comprimidos, de modo que el servidor solo tenga que realizar el 50 % del trabajo para intercambiar los mismos datos con los jugadores. Para ello, hay que modificar el valor "network-compression-threshold" en el archivo de configuración "server.properties". Se recomienda establecerlo en 512. También tenemos una entrada sobre este tema en nuestra guía, que encontrarás aquí.
Si quieres, puedes ajustar los valores a tu gusto. De lo contrario, los valores indicados son un punto de partida muy equilibrado.
Para mejorar aún más la aparición de mobs, también debes cambiar el valor "monster-spawns" en la sección "ticks-per" del archivo "bukkit.yml":
monster-spawns: 2 #Predeterminado: 1
Si, por ejemplo, hay un problema general con los monstruos (que puedes detectar en el informe de tiempos), puedes aumentar el valor hasta 5. Observa el comportamiento del servidor con cada valor para encontrar el más adecuado.
Procesamiento de chunks
Minecraft funciona con los llamados chunks. Cada chunk consta de 16x16 bloques que se unen y representan visualmente el mundo para el cliente. Por lo tanto, el servidor trabaja únicamente con chunks y carga en la RAM los que necesita. Cuantos más chunks cargue y procese de forma continua, más recursos tiene que dedicar el servidor, lo que puede ralentizarlo considerablemente.
Los servidores con la configuración predeterminada nunca descargan los chunks cargados. Esto puede provocar un uso muy elevado de la RAM y hacer que se necesite una gran cantidad de memoria. Por desgracia, el rendimiento del servidor se reduce mucho, ya que cada vez hay más elementos que procesar.
Para que el servidor solo cargue los chunks que necesita en ese momento, puedes modificar la siguiente opción en "chunk-gc" dentro de "bukkit.yml":
period-in-ticks: 300 #Predeterminado: 600
Información
El antiguo valor adicional "load-threshold" ya no existe en las versiones actuales de Paper, Spigot y Bukkit. Además, Paper limita "period-in-ticks" en el servidor a un máximo de 20 ticks (1 segundo), por lo que un valor mayor prácticamente no tiene efecto en un servidor basado en Paper (por ejemplo, Paper Spigot).
La opción "period-in-ticks" determina cada cuánto tiempo, en segundos, se deben descargar los chunks. Si lo deseas, puedes reducir aún más este valor, pero ten en cuenta que podría producirse un efecto no deseado: un bucle.
En ese caso, el chunk se descargaría aunque volviera a necesitarse poco después. El servidor tendría que invertir de nuevo tiempo y recursos en cargarlo. Esto se repetiría una y otra vez y supondría más carga para el servidor que si los chunks permanecieran cargados, por ejemplo, un minuto más.
ambient: 4 #Predeterminado: 15
Información
Si quieres, puedes ajustar los valores a tu gusto. De lo contrario, los valores indicados son un punto de partida muy equilibrado.
Para mejorar aún más la aparición de mobs, también debes cambiar el valor "monster-spawns" en la sección "ticks-per" del archivo "bukkit.yml":
monster-spawns: 2 #Predeterminado: 1
Si, por ejemplo, hay un problema general con los monstruos (que puedes detectar en el informe de tiempos), puedes aumentar el valor hasta 5. Observa el comportamiento del servidor con cada valor para encontrar el más adecuado.
Procesamiento de chunks
Minecraft funciona con los llamados chunks. Cada chunk consta de 16x16 bloques que se unen y representan visualmente el mundo para el cliente. Por lo tanto, el servidor trabaja únicamente con chunks y carga en la RAM los que necesita. Cuantos más chunks cargue y procese de forma continua, más recursos tiene que dedicar el servidor, lo que puede ralentizarlo considerablemente.
Los servidores con la configuración predeterminada nunca descargan los chunks cargados. Esto puede provocar un uso muy elevado de la RAM y hacer que se necesite una gran cantidad de memoria. Por desgracia, el rendimiento del servidor se reduce mucho, ya que cada vez hay más elementos que procesar.
Para que el servidor solo cargue los chunks que necesita en ese momento, puedes modificar la siguiente opción en "chunk-gc" dentro de "bukkit.yml":
period-in-ticks: 300 #Predeterminado: 600
Información
El antiguo valor adicional "load-threshold" ya no existe en las versiones actuales de Paper, Spigot y Bukkit. Además, Paper limita "period-in-ticks" en el servidor a un máximo de 20 ticks (1 segundo), por lo que un valor mayor prácticamente no tiene efecto en un servidor basado en Paper (por ejemplo, Paper Spigot).
La opción "period-in-ticks" determina cada cuánto tiempo, en segundos, se deben descargar los chunks. Si lo deseas, puedes reducir aún más este valor, pero ten en cuenta que podría producirse un efecto no deseado: un bucle.
En ese caso, el chunk se descargaría aunque volviera a necesitarse poco después. El servidor tendría que invertir de nuevo tiempo y recursos en cargarlo. Esto se repetiría una y otra vez y supondría más carga para el servidor que si los chunks permanecieran cargados, por ejemplo, un minuto más.
Alcance de aparición
Los mobs pueden aparecer a determinadas distancias de los jugadores. Aquí reducimos un poco ese alcance para evitar problemas con la aparición de mobs. Este ajuste es muy importante, ya que algunos ajustes de aparición ya se han explicado más arriba.
Cambia el siguiente ajuste en "world-settings" dentro de "spigot.yml":
mob-spawn-range: 3 #Predeterminado: 4
Alcances de activación de entidades
Aquí se define cuándo se activan las entidades, es decir, los animales y los monstruos. Esto significa que los animales pueden moverse y los monstruos pueden detectar a los jugadores. En general, todos los mobs están activados, pero funcionan en una especie de modo de espera. En ese modo, pueden seguir moviéndose y detectando jugadores, pero lo hacen más despacio para que el servidor no tenga que dedicar tantos recursos.
También debes realizar estos cambios en "entity-activation-range" dentro de "spigot.yml". Recomendamos los siguientes valores:
Las tolvas son una parte muy importante de Minecraft, pero pueden ser muy perjudiciales para el rendimiento del servidor. Por cada tolva colocada, el servidor debe comprobar 20 veces por segundo si hay algún objeto listo para recogerse. Mover objetos de una tolva a otra o a un cofre también consume recursos valiosos.
Para mejorar un poco la situación, aumentamos los intervalos en los que el servidor realiza estas acciones. Con los valores indicados, las acciones se ejecutarán y comprobarán cada 3 segundos. Las tasas de transferencia no cambiarán. Sin embargo, es posible que los relojes de redstone construidos con tolvas dejen de funcionar correctamente.
Para ajustar estos valores, modifica los siguientes parámetros en "spigot.yml":
hopper-transfer: 24 #Predeterminado: 8
hopper-check: 24 #Predeterminado: 8
hopper-amount: 3 #Predeterminado: 1
Colisiones
Desde Minecraft 1.9 hay colisiones, por lo que, por ejemplo, un jugador ya no puede atravesar a otro. Aquí se define con qué frecuencia pueden colisionar las entidades. Esto puede sobrecargar bastante el servidor, sobre todo en las granjas de mobs, donde muchos mobs se concentran en un espacio reducido.
Para ajustar este valor, modifica el siguiente parámetro en "spigot.yml":
max-entity-collisions: 1 #Predeterminado: 8
Las colisiones entre mobs no tienen consecuencias importantes, así que puedes reducir este valor. Este ajuste no se aplica a los jugadores, solo a los mobs.
Radio de agrupación
El radio de agrupación determina qué objetos y puntos de experiencia se combinan, lo que reduce la cantidad de entidades que debe procesar el servidor. Aumentar este radio puede beneficiar a los jugadores, especialmente en servidores donde hay muchos objetos en el suelo. También en este caso conviene encontrar un punto medio; de lo contrario, podría producirse lag porque el servidor tendría que comprobar un área más grande, lo que consume muchos recursos.
Para ajustar estos valores, modifica los siguientes parámetros bajo "merge-radius" en "spigot.yml":
item: 4.0 #Predeterminado: 2.5
exp: 6.0 #Predeterminado: 3.0
Información
No establezcas los valores por encima de 8, ya que podría producirse el efecto de lag mencionado anteriormente.
Límites de aparición
En este paso se reducen un poco las tasas generales de aparición de mobs en el servidor. La diferencia con respecto a los valores predeterminados apenas se nota. Sin embargo, en algunos casos, por ejemplo, en las granjas de mobs, es posible que la granja no funcione como esperabas.
Para modificar estos ajustes, hay que editar el archivo de configuración "bukkit.yml". Cambia los siguientes valores en "spawn-limits":
monsters: 50 #Predeterminado: 70
animals: 10 #Predeterminado: 15
water-animals: 3 #Predeterminado: 5
ambient: 4 #Predeterminado: 15
Información
Si quieres, puedes ajustar los valores a tu gusto. De lo contrario, los valores indicados son un punto de partida muy equilibrado. En un servidor Paper Spigot, también puedes establecer estos mismos valores, que tendrán prioridad, en "entities.spawning.spawn-limits" dentro de "paper-world-defaults.yml".
Para mejorar aún más la aparición de mobs, también debes cambiar el valor "monster-spawns" en la sección "ticks-per" del archivo "bukkit.yml":
monster-spawns: 2 #Predeterminado: 1
Si, por ejemplo, hay un problema general con los monstruos (que puedes detectar en el informe de tiempos), puedes aumentar el valor hasta 5. Observa el comportamiento del servidor con cada valor para encontrar el más adecuado.
Procesamiento de chunks
Minecraft funciona con los llamados chunks. Cada chunk consta de 16x16 bloques que se unen y representan visualmente el mundo para el cliente. Por lo tanto, el servidor trabaja únicamente con chunks y carga en la RAM los que necesita. Cuantos más chunks cargue y procese de forma continua, más recursos tiene que dedicar el servidor, lo que puede ralentizarlo considerablemente.
Los servidores con la configuración predeterminada nunca descargan los chunks cargados. Esto puede provocar un uso muy elevado de la RAM y hacer que se necesite una gran cantidad de memoria. Por desgracia, el rendimiento del servidor se reduce mucho, ya que cada vez hay más elementos que procesar.
Para que el servidor solo cargue los chunks que necesita en ese momento, puedes modificar la siguiente opción en "chunk-gc" dentro de "bukkit.yml":
period-in-ticks: 300 #Predeterminado: 600
Información
El antiguo valor adicional "load-threshold" ya no existe en las versiones actuales de Paper, Spigot y Bukkit. Además, Paper limita "period-in-ticks" en el servidor a un máximo de 20 ticks (1 segundo), por lo que un valor mayor prácticamente no tiene efecto en un servidor basado en Paper (por ejemplo, Paper Spigot).
La opción "period-in-ticks" determina cada cuánto tiempo, en segundos, se deben descargar los chunks. Si lo deseas, puedes reducir aún más este valor, pero ten en cuenta que podría producirse un efecto no deseado: un bucle.
En ese caso, el chunk se descargaría aunque volviera a necesitarse poco después. El servidor tendría que invertir de nuevo tiempo y recursos en cargarlo. Esto se repetiría una y otra vez y supondría más carga para el servidor que si los chunks permanecieran cargados, por ejemplo, un minuto más.
Alcance de aparición
Los mobs pueden aparecer a determinadas distancias de los jugadores. Aquí reducimos un poco ese alcance para evitar problemas con la aparición de mobs. Este ajuste es muy importante, ya que algunos ajustes de aparición ya se han explicado más arriba.
Cambia el siguiente ajuste en "world-settings" dentro de "spigot.yml":
mob-spawn-range: 3 #Predeterminado: 4
Generadores de mobs
Los generadores de mobs se usan con mucha frecuencia, sobre todo en servidores CityBuild, y a veces en grandes cantidades. Estos generadores hacen que aparezcan cada vez más mobs en el servidor, lo que puede provocar numerosos problemas.
Esta opción ajusta un poco el comportamiento de aparición de los generadores para que el servidor los active en intervalos más largos. Para ello, modifica el siguiente valor bajo "tick-rates" en "paper-world-defaults.yml":
mob-spawner: 3 #Predeterminado: 1
Información
El valor indicado no modifica demasiado el comportamiento ni afecta mucho a la experiencia de juego.
Alcances de activación de entidades
Aquí se define cuándo se activan las entidades, es decir, los animales y los monstruos. Esto significa que los animales pueden moverse y los monstruos pueden detectar a los jugadores. En general, todos los mobs están activados, pero funcionan en una especie de modo de espera. En ese modo, pueden seguir moviéndose y detectando jugadores, pero lo hacen más despacio para que el servidor no tenga que dedicar tantos recursos.
También debes realizar estos cambios en "entity-activation-range" dentro de "spigot.yml". Recomendamos los siguientes valores:
Las tolvas son una parte muy importante de Minecraft, pero pueden ser muy perjudiciales para el rendimiento del servidor. Por cada tolva colocada, el servidor debe comprobar 20 veces por segundo si hay algún objeto listo para recogerse. Mover objetos de una tolva a otra o a un cofre también consume recursos valiosos.
Para mejorar un poco la situación, aumentamos los intervalos en los que el servidor realiza estas acciones. Con los valores indicados, las acciones se ejecutarán y comprobarán cada 3 segundos. Las tasas de transferencia no cambiarán. Sin embargo, es posible que los relojes de redstone construidos con tolvas dejen de funcionar correctamente.
Para ajustar estos valores, modifica los siguientes parámetros en "spigot.yml":
hopper-transfer: 24 #Predeterminado: 8
hopper-check: 24 #Predeterminado: 8
hopper-amount: 3 #Predeterminado: 1
Colisiones
Desde Minecraft 1.9 hay colisiones, por lo que, por ejemplo, un jugador ya no puede atravesar a otro. Aquí se define con qué frecuencia pueden colisionar las entidades. Esto puede sobrecargar bastante el servidor, sobre todo en las granjas de mobs, donde muchos mobs se concentran en un espacio reducido.
En un servidor Paper Spigot, este valor ya no se encuentra en "spigot.yml", sino bajo "collisions" en "paper-world-defaults.yml":
max-entity-collisions: 1 #Predeterminado: 8
Las colisiones entre mobs no tienen consecuencias importantes, así que puedes reducir este valor. Este ajuste no se aplica a los jugadores, solo a los mobs.
Radio de agrupación
El radio de agrupación determina qué objetos y puntos de experiencia se combinan, lo que reduce la cantidad de entidades que debe procesar el servidor. Aumentar este radio puede beneficiar a los jugadores, especialmente en servidores donde hay muchos objetos en el suelo. También en este caso conviene encontrar un punto medio; de lo contrario, podría producirse lag porque el servidor tendría que comprobar un área más grande, lo que consume muchos recursos.
Para ajustar estos valores, modifica los siguientes parámetros bajo "merge-radius" en "spigot.yml":
item: 4.0 #Predeterminado: 2.5
exp: 6.0 #Predeterminado: 3.0
Información
No establezcas los valores por encima de 8, ya que podría producirse el efecto de lag mencionado anteriormente.
Explosiones
En Paper Spigot se han reprogramado muchos componentes de los servidores de Minecraft para mejorar su rendimiento. Esto también se aplica a las explosiones. El software las gestionará de forma más eficiente para evitar grandes problemas de lag en el servidor.
Para ello, modifica el siguiente valor bajo "environment" en "paper-world-defaults.yml":
optimize-explosions: true #Predeterminado: false
Cofres
También hay un pequeño ajuste de optimización para los cofres. Si un gato está sentado encima de un cofre, no se puede abrir. Para comprobarlo, el servidor debe revisar todos los mobs que se encuentran en cierto radio y comprobar si alguno está sentado encima del cofre. Este proceso consume mucho tiempo y se repite cada vez que alguien abre un cofre.
Puedes desactivar esta opción bajo "entities.behavior" en "paper-world-defaults.yml" con el siguiente cambio:
Los inventarios se usan con frecuencia, pero no todos son iguales. Por ejemplo, un cofre o una mesa de trabajo también son inventarios. Con este cambio puedes darle un pequeño respiro al servidor sin que nadie lo note. Básicamente, se establece el número de ticks que deben transcurrir antes de que el servidor actualice cada inventario.
Para ello, modifica el siguiente valor bajo "tick-rates" en "paper-world-defaults.yml":
container-update: 3 #Predeterminado: 1
Información
No establezcas el valor por encima de 5, ya que el inventario podría empezar a funcionar de forma inestable. En modos de juego como SurvivalGames, donde todos los jugadores intentan acceder a los cofres del centro y conseguir los mejores objetos, no cambies el valor: déjalo en "1".
Guardado de datos de chunks
Cuando se realizan cambios en un chunk, no se escriben directamente en el disco, sino que primero se cargan en la RAM. Aun así, los cambios se guardan con mucha frecuencia, lo que a veces puede provocar mucho lag, sobre todo si el servidor intenta guardar cambios masivos.
Con este cambio reducimos la cantidad máxima de chunks que se pueden guardar en una operación. Esto puede aumentar el uso de la RAM en algunos momentos, ya que los cambios permanecen más tiempo en ella.
Realiza el siguiente cambio bajo "chunks" en "paper-world-defaults.yml":
Redstone se utiliza con mucha frecuencia en circuitos que a veces son extremadamente grandes. En los servidores públicos, puede ser uno de los puntos más débiles: casi el 90 % de los servidores pueden sufrir mucho lag a causa de circuitos de redstone grandes. Aquí utilizamos un método alternativo de procesamiento de redstone de Paper Spigot, que reduce considerablemente su impacto y mantiene la misma funcionalidad que en Vanilla.
Para ello, modifica el siguiente ajuste bajo "misc" en "paper-world-defaults.yml":
Además de "VANILLA", puedes elegir "EIGENCRAFT" y "ALTERNATE_CURRENT". Según Paper, "ALTERNATE_CURRENT" es actualmente la opción más rápida y la que menos se aleja del comportamiento de Vanilla.
Información
¡Atención! En algunas situaciones, esto puede cambiar considerablemente el comportamiento de Redstone.
Fuente preferida en Google
