Folia
1.0.0
Fork of Paper que agrega subprocesos múltiples regionalizados al servidor dedicado.
Los grupos de folia cercanos cargaron trozos para formar una "región independiente". Consulte la documentación de PaperMC para obtener detalles exactos sobre cómo Folia agrupará los fragmentos cercanos. Cada región independiente tiene su propio ciclo de ticks, que se marca al ritmo normal de Minecraft (20TPS). Los bucles de tick se ejecutan en un grupo de subprocesos en paralelo. Ya no existe un hilo principal, ya que cada región tiene efectivamente su propio "hilo principal" que ejecuta todo el ciclo de ticks.
Para un servidor con muchos jugadores dispersos, Folia creará muchas regiones dispersas y las marcará todas en paralelo en un grupo de subprocesos de tamaño configurable. Por lo tanto, Folia debería escalar bien para servidores como este.
Folia también es un proyecto propio y no se fusionará con Paper en el futuro previsible.
Una descripción general más detallada pero abstracta: descripción general del proyecto.
Los tipos de servidores que distribuyen naturalmente a los jugadores, como skyblock o SMP, serán los que más se beneficiarán de Folia. El servidor también debería tener un número considerable de jugadores.
Lo ideal es al menos 16 núcleos (no subprocesos).
En primer lugar, se recomienda que el mundo esté pregenerado para que la cantidad de subprocesos de trabajo del sistema de fragmentos necesarios se reduzca considerablemente.
La siguiente es una estimación muy aproximada basada en las pruebas realizadas antes de que se lanzara Folia en el servidor de prueba que ejecutamos y que tenía un máximo de ~330 jugadores. Por lo tanto, no es exacto y requerirá ajustes adicionales; tómelo como punto de partida.
Se debe tener en cuenta el número total de núcleos disponibles en la máquina. Luego, asigne hilos para:
-XX:ConcGCThreads=n . No confunda este indicador con -XX:ParallelGCThreads=n , ya que los subprocesos de GC paralelos solo se ejecutan cuando el GC pausa la aplicación y, como tal, no deben tenerse en cuenta.Después de toda esa asignación, los núcleos restantes en el sistema hasta el 80% de la asignación (total de subprocesos asignados <80% de CPU disponibles) se pueden asignar a tickthreads (bajo configuración global, threaded-regions.threads).
La razón por la que no debes asignar más del 80% de los núcleos se debe al hecho de que los complementos o incluso el servidor pueden utilizar subprocesos adicionales que no puedes configurar ni predecir.
Además, todo lo anterior es una suposición aproximada basada en el número de jugadores, pero es muy probable que la asignación de subprocesos no sea ideal y necesitarás ajustarla según el uso de los subprocesos que termines viendo.
Ya no hay hilo principal. Espero que todos los complementos que existen requieran algún nivel de modificación para funcionar en Folia. Además, el subproceso múltiple de cualquier tipo introduce posibles condiciones de carrera en los datos retenidos por el complemento, por lo que es probable que sea necesario realizar cambios.
Entonces, tenga sus expectativas de compatibilidad en 0.
Actualmente, existen muchas API que se basan en el hilo principal. Básicamente espero que ningún complemento que sea compatible con Paper sea compatible con Folia. Sin embargo, hay planes para agregar una API que permitiría que los complementos de Folia sean compatibles con Paper.
Por ejemplo, el programador Bukkit. El Bukkit Scheduler se basa inherentemente en un único hilo principal. RegionScheduler de Folia y EntityScheduler de Folia permiten programar tareas para el "siguiente tick" de cualquier región "propietaria" de una ubicación o de una entidad. Estos podrían implementarse en Paper normal, excepto que se programan en el hilo principal; en ambos casos, la ejecución de la tarea se producirá en el hilo que "posee" la ubicación o entidad. Este concepto se aplica en general, ya que el Papel actual (de un solo hilo) puede verse como una "región" gigante que abarca todos los fragmentos de todos los mundos.
Aún no se ha decidido si agregar esta API directamente a Paper o a Paperlib.
Primero, Folia rompe muchos complementos. Para ayudar a los usuarios a determinar qué complementos funcionan, solo se cargarán los complementos que los autores hayan marcado explícitamente para funcionar con Folia. Al colocar "folia-supported: true" en el archivo plugin.yml del complemento, los autores del complemento pueden marcar su complemento como compatible con subprocesos múltiples regionalizados.
La otra regla importante es que las regiones funcionan en paralelo y no al mismo tiempo . No comparten datos, no esperan compartir datos y compartir datos causará corrupción de datos. El código que se ejecuta en una región bajo ninguna circunstancia puede acceder o modificar datos que se encuentren en otra región. El hecho de que el nombre incluya subprocesos múltiples no significa que ahora todo sea seguro para subprocesos. De hecho, solo hay unas pocas cosas que se hicieron seguras para subprocesos para que esto suceda. A medida que pasa el tiempo, el número de comprobaciones de contexto de subprocesos no hará más que crecer, incluso si supone una penalización en el rendimiento: nadie va a utilizar ni desarrollar una plataforma de servidor que tenga muchos errores, y la única manera de prevenirlos y encontrarlos bugs es hacer que los malos accesos fallen en la fuente del mal acceso.
Esto significa que los complementos compatibles con Folia deben aprovechar API como RegionScheduler y EntityScheduler para garantizar que su código se ejecute en el contexto de subproceso correcto.
En general, es seguro asumir que una región posee fragmentos de datos en aproximadamente 8 fragmentos desde la fuente de un evento (es decir, el jugador rompe el bloque, probablemente pueda acceder a 8 fragmentos alrededor de ese bloque). Pero esto no está garantizado: los complementos deben aprovechar la próxima API de verificación de subprocesos para garantizar un comportamiento correcto.
La única garantía de seguridad de los subprocesos proviene del hecho de que una sola región posee datos en ciertos fragmentos, y si esa región funciona, entonces tiene acceso completo a esos datos. Estos datos son específicamente datos de entidad/fragmento/poi y no tienen ninguna relación con NINGÚN dato de complemento.
Las reglas normales de subprocesos múltiples se aplican a los datos que los complementos almacenan/acceden a sus propios datos o a los de otros complementos: eventos/comandos/etc. se llaman en paralelo porque las regiones funcionan en paralelo (NO PODEMOS llamarlas de manera sincrónica, ya que esto abre problemas de estancamiento y perjudicaría el rendimiento). No hay salida fácil a esto, depende únicamente de a qué datos se accede. A veces, una colección concurrente (como ConcurrentHashMap) es suficiente y, a menudo, una colección concurrente utilizada descuidadamente solo ocultará problemas de subprocesos, que luego se volverán casi imposibles de depurar.
Para comprender correctamente las adiciones de API, lea la descripción general del proyecto.
Para comprender correctamente las adiciones de API, lea la descripción general del proyecto.
Reglas generales:
Los comandos para entidades/jugadores se llaman en la región propietaria de la entidad/jugador. Los comandos de la consola se ejecutan en la región global.
Los eventos que involucran a una sola entidad (es decir, los descansos del jugador/bloqueo de lugares) se convocan en la entidad propietaria de la región. Los eventos que involucran acciones sobre una entidad (como daño a la entidad) se invocan en la región propietaria de la entidad objetivo.
El modificador async para eventos está obsoleto: todos los eventos activados desde regiones o la región global se consideran sincrónicos , aunque ya no haya un hilo principal.
< repository >
< id >papermc</ id >
< url >https://repo.papermc.io/repository/maven-public/</ url >
</ repository >< dependency >
< groupId >dev.folia</ groupId >
< artifactId >folia-api</ artifactId >
< version >1.20.1-R0.1-SNAPSHOT</ version >
< scope >provided</ scope >
</ dependency > El archivo PATCHES-LICENSE describe la licencia para los parches de API y servidor, que se encuentran en ./patches y sus subdirectorios, excepto cuando se indique lo contrario.
La bifurcación se basa en el ejemplo de bifurcación de PaperMC que se encuentra aquí. Como tal, contiene modificaciones en este proyecto; consulte el repositorio para obtener información sobre la licencia de los archivos modificados.
