Folia
1.0.0
Fork of Paper, который добавляет региональную многопоточность на выделенный сервер.
Фолиа группирует близлежащие загруженные куски, образуя «независимый регион». См. документацию PaperMC для получения точных сведений о том, как Folia будет группировать близлежащие фрагменты. Каждый независимый регион имеет свою собственную тиковую петлю, которая тикает с обычным тикрейтом Minecraft (20TPS). Циклы тиков выполняются в пуле потоков параллельно. Главного потока больше нет, поскольку каждый регион фактически имеет свой собственный «основной поток», который выполняет весь цикл тика.
Для сервера с множеством разбросанных игроков Folia создаст множество разбросанных регионов и отметит их все параллельно в пуле потоков настраиваемого размера. Таким образом, Folia должна хорошо масштабироваться для таких серверов.
Folia также является собственным проектом, в обозримом будущем он не будет объединен с Paper.
Более подробный, но абстрактный обзор: Обзор проекта.
Типы серверов, которые естественным образом распределяют игроков, например skyblock или SMP, больше всего выиграют от Folia. На сервере также должно быть значительное количество игроков.
В идеале минимум 16 ядер (не потоков).
Во-первых, рекомендуется предварительно сгенерировать мир, чтобы значительно сократить количество требуемых рабочих потоков системы фрагментов.
Ниже приводится очень приблизительная оценка, основанная на тестировании, проведенном до выпуска Folia на тестовом сервере, который мы запускали и на пике которого было около 330 игроков. Так что это не точно и потребует дальнейшей настройки — просто примите это за отправную точку.
Следует учитывать общее количество доступных ядер на машине. Затем выделите потоки для:
-XX:ConcGCThreads=n . Не путайте этот флаг с -XX:ParallelGCThreads=n , поскольку параллельные потоки GC запускаются только тогда, когда приложение приостановлено GC, и поэтому не должны приниматься во внимание.После всего этого распределения оставшиеся ядра в системе до распределения 80% (общее количество выделенных потоков <80% доступного процессора) могут быть выделены для тиковых потоков (в глобальной конфигурации threaded-regions.threads).
Причина, по которой вам не следует выделять более 80% ядер, заключается в том, что плагины или даже сервер могут использовать дополнительные потоки, которые вы не можете настроить или даже предсказать.
Кроме того, все вышесказанное является приблизительным предположением, основанным на количестве игроков, но весьма вероятно, что распределение потоков не будет идеальным, и вам придется настроить его на основе использования потоков, которые вы в конечном итоге увидите.
Основной темы больше нет. Я ожидаю, что каждый существующий плагин потребует определенного уровня модификации для работы в Folia. Кроме того, многопоточность любого типа приводит к возможным состояниям гонки в данных, хранящихся в плагине, поэтому обязательно необходимо внести изменения.
Итак, ваши ожидания совместимости равны 0.
В настоящее время существует множество API, использующих основной поток. Я ожидаю, что практически никакие плагины, совместимые с Paper, будут совместимы с Folia. Однако есть планы добавить API, который позволит плагинам Folia быть совместимыми с Paper.
Например, планировщик Bukkit. Планировщик Bukkit по своей сути опирается на один основной поток. RegionScheduler Folia и EntityScheduler Folia позволяют планировать задачи до «следующего тика» любого региона, «владеющего» местоположением или объектом. Их можно реализовать на обычном Paper, за исключением того, что они планируются для основного потока — в обоих случаях выполнение задачи будет происходить в потоке, который «владеет» местоположением или объектом. Эта концепция применима в целом, поскольку текущий документ (однопоточный) можно рассматривать как один гигантский «регион», охватывающий все фрагменты во всех мирах.
Пока не решено, добавлять ли этот API непосредственно в сам Paper или в Paperlib.
Во-первых, Folia ломает многие плагины. Чтобы помочь пользователям определить, какие плагины работают, будут загружаться только те плагины, которые были явно отмечены автором(ами) для работы с Folia. Поместив «folia-supported: true» в файл plugin.yml плагина, авторы плагина могут пометить свой плагин как совместимый с региональной многопоточностью.
Другое важное правило заключается в том, что регионы тикают параллельно , а не одновременно . Они не обмениваются данными и не ожидают обмена данными, а обмен данными приведет к повреждению данных. Код, работающий в одном регионе, ни при каких обстоятельствах не может получать доступ или изменять данные, находящиеся в другом регионе. Тот факт, что в названии присутствует многопоточность, не означает, что теперь все потокобезопасно. На самом деле, есть лишь несколько вещей, которые были сделаны потокобезопасными, чтобы это произошло. Со временем количество проверок контекста потока будет только расти, даже если это приведет к снижению производительности — никто не собирается использовать или разрабатывать серверную платформу, которая чертовски глючная, и единственный способ предотвратить и найти такие ошибки. Ошибка заключается в том, чтобы привести к тому, что неверный доступ резко завершается неудачей в источнике плохого доступа.
Это означает, что плагины, совместимые с Folia, должны использовать преимущества API, таких как RegionScheduler и EntityScheduler, чтобы гарантировать, что их код выполняется в правильном контексте потока.
В общем, можно с уверенностью предположить, что регион владеет данными фрагментов примерно в 8 фрагментах от источника события (т. е. игрок разбивает блок и, вероятно, может получить доступ к 8 фрагментам вокруг этого блока). Но это не гарантировано — плагины должны использовать преимущества будущего API проверки потоков, чтобы гарантировать правильное поведение.
Единственная гарантия потокобезопасности заключается в том, что один регион владеет данными в определенных фрагментах — и если этот регион работает, то он имеет полный доступ к этим данным. Эти данные представляют собой данные объекта/фрагмента/poi и совершенно не связаны с ЛЮБЫМИ данными плагина.
Обычные правила многопоточности применяются к данным, которые плагины хранят/обращаются к своим собственным данным или данным другого плагина – событиям/командам/и т.д. вызываются параллельно, потому что регионы работают параллельно (мы НЕ МОЖЕМ вызывать их синхронно, так как это вызывает проблемы взаимоблокировки и снижает производительность). Простых путей выхода из этой ситуации нет, это зависит исключительно от того, к каким данным осуществляется доступ. Иногда параллельной коллекции (например, ConcurrentHashMap) достаточно, и часто небрежное использование параллельной коллекции только скрывает проблемы с потоками, которые затем становится практически невозможно отладить.
Чтобы правильно понять дополнения API, прочтите Обзор проекта.
Чтобы правильно понять дополнения API, прочтите Обзор проекта.
Общие практические правила:
Команды для сущностей/игроков вызываются в регионе, которому принадлежит сущность/игрок. Консольные команды выполняются в глобальном регионе.
События, связанные с одним объектом (т. е. игрок разбивает/устанавливает блок), вызываются на объекте, владеющем регионом. События, связанные с действиями над объектом (например, повреждением объекта), вызываются в регионе, владеющем целевым объектом.
Модификатор async для событий устарел — все события, запускаемые из регионов или глобального региона, считаются синхронными , даже если основного потока больше нет.
< 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 > Файл PATCHES-LICENSE описывает лицензию на патчи API и сервера, находящиеся в ./patches и его подкаталогах, если не указано иное.
Форк основан на примере форка PaperMC, который можно найти здесь. Таким образом, в этом проекте он содержит модификации; информацию о лицензии для измененных файлов см. в репозитории.
