что такое mspt майнкрафт
Оптимизация сервера Minecraft
В нашем блоге мы уже рассказывали, как создать свой сервер Minecraft, однако с тех пор прошло 5 лет и многое поменялось. Делимся с вами актуальными способами создания и оптимизации серверной части столь популярной игры.
За свою 9-летнюю историю (если считать от даты релиза) Minecraft заработал потрясающее количество поклонников и хейтеров как среди обычных игроков, так и среди гиков. Простая концепция мира из кубиков превратилась из обычного развлечения в универсальную среду для общения и создания различных объектов из реального мира.
Помимо строительства, в игре есть возможность создавать логические схемы, которые позволяют реализовывать полноценные алгоритмы внутри Minecraft. На YouTube полно весьма впечатляющих роликов, где люди, приложив огромное количество сил и потратив множество времени, создали копию того или иного электронного устройства или построили детальную копию существующих и вымышленных архитектурных сооружений. Все ограничивается лишь фантазией геймера и возможностями игровой вселенной.
Но не будем дальше говорить о том, что именно игроки создают, а посмотрим на серверную часть приложения и осветим проблемы (порой весьма сложные), которые могут возникнуть в процессе работы под нагрузкой. Сразу оговоримся, что речь пойдет только о Java Edition.
Виды серверов
Самым простым вариантом является сервер, встроенный в клиент игры. Создали мир, нажали на одну кнопочку, и вот сервер стал доступен по локальной сети. Никакой серьезной нагрузки такой вариант выдержать не может, а поэтому мы не будем его даже рассматривать.
Vanilla
Компания Mojang Studios распространяет серверную часть игры в виде Java-приложения бесплатно на официальном сайте. Это позволяет создать свой собственный выделенный сервер и персональный мир, сделав его доступным для подключения из любой точки планеты. Для тех, кто делает это впервые, есть отличный туториал, доступный в соответствующей игровой Wiki.
У этого подхода есть один серьезный недостаток, а именно — отсутствие возможностей «из коробки» подключать плагины, расширяющие функционал сервера и позволяющие не только автоматизировать многие процессы, но и оптимизировать производительность. Кроме того, у официального сервера достаточно большое потребление оперативной памяти на каждого подключенного игрока.
Bukkit
Созданное энтузиастами на базе Vanilla-версии серверное приложение Bukkit значительно расширяло возможности игры за счет поддержки плагинов и модов (модификаций). Оно позволило не только добавлять в игровой процесс новые блоки, но и выполнять различные манипуляции, недоступные ванильному ПО. Что интересно, памяти это приложение требовало значительно меньше.
Установить Bukkit не составляет особого труда, соответствующая инструкция есть на ресурсе GamePedia. Но это не имеет смысла, так как с 2014 года команда Bukkit распалась, разработчики проекта стали сотрудниками Mojang Studios, а репозиторий заброшен. Таким образом, Bukkit фактически мертв, и имеет смысл обратить внимание на два следующих проекта.
SpigotMC
Для облегчения жизни разработчиков плагинов была необходимость в API для взаимодействия с игровым миром. Именно эту задачу и решили создатели Spigot, взяв за основу ядро Bukkit и переработав его для достижения лучшей надежности и производительности. Тем не менее, Git-репозиторий проекта был заблокирован в связи с Законом об авторском праве в цифровую эпоху (DMCA), и скачать оттуда исходники невозможно.
На текущий момент SpigotMC активно развивается и используется. Он поддерживает все плагины, созданные под Bukkit, однако с ним обратно не совместим. Чтобы обойти запрет DMCA Takedown, был придуман элегантный способ под названием BuildTools. Этот инструмент избавляет от необходимости дистрибуции скомпилированного приложения и позволяет пользователям выполнить компиляцию Spigot, CraftBukkit и Bukkit из исходного кода. Все это делает запрет DMCA бесполезным.
PaperMC
Казалось бы, все круто, и Spigot стал прекрасным вариантом. Но некоторым энтузиастам этого показалось мало, и они запилили свой собственный форк Spigot «на стероидах». На странице проекта ключевым достоинством указано, что “It’s stupid fast”. Развитое коммьюнити позволяет оперативно решать возникающие вопросы, а расширенное API — делать интересные плагины. Запустить PaperMC можно одной простой командой, приведенной в документации.
С совместимостью у PaperMC все прекрасно, так что написанные плагины под SpigotMC легко заработают и на PaperMC, но без официальной поддержки. Обратная совместимость со SpigotMC также присутствует. Теперь, когда мы перечислили различные варианты создания сервера, перейдем к тем проблемам производительности, которые могут возникать.
Проблемы и решения
Главное, что нужно понимать, — все, что касается обработки игрового мира будет обрабатываться только на одном вычислительном ядре физического сервера. Так что если вдруг у вас прекрасный сервер с десятком вычислительных ядер, то загружено будет только одно. Все остальные будут фактически простаивать. Такова уж архитектура приложения, и ничего вы с этим поделать не сможете. Так что при выборе сервера следует обращать внимание не на количество ядер, а на тактовую частоту. Чем она будет выше, тем лучше будет производительность.
Что касается вопроса об объеме оперативной памяти, тут следует исходить из следующих показателей:
Для запуска серверной части рекомендуем воспользоваться флагами, указанными в статье Tuning the JVM – G1GC Garbage Collector Flags for Minecraft. Эта «черная магия» позволяет серверу грамотно настроить «сборщик мусора» и оптимизирует использование оперативной памяти. Не стоит выделять памяти больше, чем реально потребляет сервер при пиковом наплыве игроков.
Генерация карты блоков
“Вы действительно считаете, что Луна существует, только когда вы на неё смотрите?” (Альберт Эйнштейн)
Абсолютно новый сервер. Как только игрок первый раз успешно подключается, игровой персонаж появляется на общей точке сбора (спаун). Это единственное место, где игровой мир предварительно генерируется сервером. В этот же момент клиентская часть смотрит в настройки, и ключевым параметром является дальность прорисовки. Измеряется она в чанках (область карты 16×16 и высотой в 256 блоков) Сколько чанков там указано, именно столько и будет запрошено у сервера.
На сервере хранится глобальная карта мира, и если в ней еще нет сгенерированных блоков в точке появления игрового персонажа, то сервер их динамически генерирует и сохраняет у себя. Мало того, что это требует больших вычислительных ресурсов, так еще и постоянно увеличивает размер карты мира. На одном из старейших анархических серверов 2b2t (2builders2tools) размер карты уже превысил 8 Tb, а граница мира проходит на отметке в 30 млн блоков. С этим сервером связаны тысячи историй, и он заслуживает отдельной статьи серии статей.
Генерация мира вокруг одного игрока — не проблема. Генерация мира вокруг сотни игроков вызовет незначительные тормоза сервера на протяжении короткого времени, после чего нагрузка снизится. Генерация мира на дальность прорисовки клиента вокруг тысячи игроков уже способна «уронить» сервер и повыбрасывать с него всех клиентов по таймауту.
В серверном ПО имеется такое значение, как TPS (Ticks per Server — тактов в секунду). Штатно 1 такт равен 50 мс. (1 секунда реального мира равна 20 тактам игрового мира). Если обработка одного такта вырастет до 60 секунд — серверное приложение будет закрыто, выкинув всех игроков.
Выход — ограничить мир определенными координатами и выполнить предварительную генерацию блоков. Тем самым мы снимаем необходимость динамической генерации в процессе игры, и серверу будет достаточно прочитать уже существующую карту. Оба вопроса решаются одним-единственным плагином WorldBorder.
Проще всего задать границу мира в виде окружности относительно точки спауна (хотя можно ее сделать любой формы) одной командой:
Если игровой персонаж попытается пересечь границу, то будет отброшен на несколько блоков назад. Если это проделать несколько раз за ограниченное время, то нарушитель будет принудительно телепортирован на точку спауна. Предварительная генерация мира выполняется еще проще, командой:
Поскольку данное действие потенциально может затронуть игроков, находящихся на сервере, не забудьте подтвердить выполнение:
В общей сложности на то, чтобы сгенерировать мир радиусом в 5000 блоков (
40 млрд блоков) ушло примерно 2 часа на процессоре Intel® Xeon® Gold 6240. Поэтому, если хотите запустить прегенерацию большей карты, учитывайте, что этот процесс займет приличное количество времени, а TPS сервера будет серьезно снижено. Кроме того, помните, что даже радиус в 5000 блоков потребует примерно 2 Гб места на дисковом накопителе.
Несмотря на то, что крайняя версия плагина была разработана для Minecraft версии 1.14, опытным путем выяснено, что она прекрасно работает и на последующих версиях. Полный список команд с пояснениями доступен на форуме плагина.
Проблемные блоки
Если блоков TNT несколько, то детонация одного блока вызывает детонацию и включение гравитации у соседних блоков, разбрасывая их во все стороны. Вся эта красивая механика на стороне сервера выглядит как множество операций по подсчету траектории каждого из блоков, а также взаимодействия с соседними блоками. Задача крайне ресурсоемкая, что легко может проверить каждый. Сгенерируйте и подорвите куб из блоков TNT, размером хотя бы 30x30x30. И если вы думали, что у вас хороший мощный игровой компьютер, то сильно заблуждались 😉
Подобный «эксперимент» на сервере с Intel® Xeon® Gold 6240 привел к серьезной «просадке» TPS и 80% нагрузке на CPU в течение всего времени детонации блоков. А следовательно, если кто-либо из игроков сможет проделать подобное, то проблема с производительностью затронет всех находящихся на сервере игроков.
Еще более жесткий вариант — Кристаллы Края. Если TNT все же взрывается последовательно, то Кристаллы Края детонируют все одновременно, что в теории может вообще остановить работу серверного приложения.
Избежать этого сценария можно, только полностью запретив использование данных блоков в игровом мире. Например, с помощью плагина WorldGuard. Обратите внимание, что сам по себе этот плагин не работает без другого плагина WorldEdit. Так что устанавливаете вначале WorldEdit, а затем WorldGuard.
Заключение
Грамотное управление игровым сервером — задача не из простых. Сложности и снижение производительности будут поджидать на каждом шагу, особенно если не брать в расчет саму механику игрового процесса. Предусмотреть все невозможно, ведь игроки порой бывают очень изобретательны в попытках заставить сервер выполнить то, для чего он не был предназначен. Только разумный баланс между рисками и устанавливаемыми ограничениями позволит серверу работать в непрерывном режиме и не снижать свою производительность до критичных значений.
На карантине некоторые наши сотрудники соскучились по любимым офисам и решили воссоздать их внутри Minecraft. У вас тоже есть шанс заглянуть к нам в гости, не рискуя своим здоровьем и не тратя время на дорогу.
Для этого мы приглашаем всех желающих на наш сервер minecraft.selectel.ru (версия клиента 1.15.2), где воссозданы дата-центры Цветочная-1 и Цветочная-2. Не забудьте согласиться со скачиванием дополнительных ресурсов, они необходимы для корректного отображения некоторых локаций.
Вас ждут квесты, промокоды, «пасхалки» и приятное общение.
Туториал Оптимизация Сервера Minecraft | by Rgferg1 2020-09-13
Добрый вечер, пользователи. Каждый сталкивался с такой проблемой, что тормозит сервер. При таких условиях будет низкий TPS.
Что такое TPS?
TPS (Ticks per Second) — это число тактов за секунду. Чем более высокий данный показатель, тем большая производительность сервера. В норме показатель 20.0. TPS может существенно снижаться в случае значительной нагрузки на сервер. И в консоль выводятся такие строчки: [Server thread/WARN]: Can’t keep up! Is the server overloaded? Running 9999ms or 9999 ticks behind
Чтобы посмотреть значение TPS введите команду: /tps
YAML:
#CoreProtect Config
# If enabled, extra data is displayed when doing rollbacks and restores.
# If disabled, you can manually trigger it in-game by adding «#verbose»
# to the end of your rollback statement.
verbose: true
# MySQL is optional and not required.
# If you prefer to use MySQL, enable the following and fill out the fields.
use-mysql: false
table-prefix: СВОИ ДАННЫЕ
mysql-host: СВОИ ДАННЫЕ
mysql-port: СВОИ ДАННЫЕ
mysql-database: СВОИ ДАННЫЕ
mysql-username: СВОИ ДАННЫЕ
mysql-password: СВОИ ДАННЫЕ
# If enabled, CoreProtect will check for updates when your server starts up.
# If an update is available, you’ll be notified via your server console.
check-updates: true
# If enabled, other plugins will be able to utilize the CoreProtect API.
api-enabled: true
# If no radius is specified in a rollback or restore, this value will be
# used as the radius. Set to «0» to disable automatically adding a radius.
default-radius: 10
# The maximum radius that can be used in a command. Set to «0» to disable.
# To run a rollback or restore without a radius, you can use «r:#global».
max-radius: 100
# If enabled, items taken from containers (etc) will be included in rollbacks.
rollback-items: true
# If enabled, entities, such as killed animals, will be included in rollbacks.
rollback-entities: true
# If enabled, generic data, like zombies burning in daylight, won’t be logged.
skip-generic-data: true
# Logs blocks placed by players.
block-place: true
# Logs blocks broken by players.
block-break: true
# Logs blocks that break off of other blocks; for example, a sign or torch
# falling off of a dirt block that a player breaks. This is required for
# beds/doors to properly rollback.
natural-break: true
# Properly track block movement, such as sand or gravel falling.
block-movement: true
# Properly track blocks moved by pistons.
pistons: true
# Logs blocks that burn up in a fire.
block-burn: true
# Logs when a block naturally ignites, such as from fire spreading.
block-ignite: true
# Logs explosions, such as TNT and Creepers.
explosions: true
# Track when an entity changes a block, such as an Enderman destroying blocks.
entity-change: true
# Logs killed entities, such as killed cows and enderman.
entity-kills: false
# Logs text on signs. If disabled, signs will be blank when rolled back.
sign-text: false
# Logs lava and water sources placed/removed by players who are using buckets.
buckets: true
# Logs natural tree leaf decay.
leaf-decay: true
# Logs tree growth. Trees are linked to the player who planted the sappling.
tree-growth: true
# Logs mushroom growth.
mushroom-growth: true
# Logs natural vine growth.
vine-growth: true
# Logs when portals such as Nether portals generate naturally.
portals: true
# Logs water flow. If water destroys other blocks, such as torches,
# this allows it to be properly rolled back.
water-flow: true
# Logs lava flow. If lava destroys other blocks, such as torches,
# this allows it to be properly rolled back.
lava-flow: true
# Allows liquid to be properly tracked and linked to players.
# For example, if a player places water which flows and destroys torches,
# it can all be properly restored by rolling back that single player.
liquid-tracking: true
# Track item transactions, such as when a player takes items from a
# chest, furnace, or dispenser. Necessary for any item based rollbacks.
item-transactions: true
# Track player interactions, such as when a player opens a door, presses
# a button, or opens a chest. Player interactions can’t be rolled back.
player-interactions: true
# Logs messages that players send in the chat.
player-messages: false
# Logs all commands used by players.
player-commands: false
# Logs the logins and logouts of players.
player-sessions: false
# Logs when a player changes their Minecraft username.
username-changes: false
# Logs changes made via the plugin «WorldEdit» if it’s in use on your server.
worldedit: true
# CoreProtect is donationware. Obtain a donation key from coreprotect.net/donate/
donation-key:
# Logs items dropped by players.
item-drops: true
# Logs items picked up by players.
item-pickups: true
# Track all hopper transactions, such as when a hopper removes items from a
# chest, furnace, or dispenser.
hopper-transactions: false
Также у этого плагина бывают проблемы с базой данной. Если что-то пойдет не так, то ваш ТПС упадет то 0.60. И ваш сервер просто зависнет. Такое было у меня.
Мобы
Сервер может оставать из за мобов. С помощью таймингов вы можете остледить именно какие мобы нагружают сервер.
С помощью плагина MFM, вы можете регулировать спавн и число мобов.
Спавн мобов лучше настроить в bukkit.yml, spigot.yml
ФИКСЫ
Один из игроков может сидеть с чит клиента. И посылать слишком много пакетов, что заставит сервер тормозит а в скоре и положить его. Также пользование предметов с 1000 лвл может тоже замедлять работу сервера. Есть фиксы на это. Ниже.
Ссылки не предоставил, ищите сами. Google.com и Yandex.ru, может попозже залью.
Совет: На свой выбор. Некоторые плагины могут конфликтовать с друг другом. Не ставьте их всех подряд.
Принцип работы протокола MSTP
Сегодня поговорим об MSTP. Перед тем, как разбираться с MSTP, надо ознакомиться с протоколами STP и RSTP. MSTP является модификацией RSTP, а значит и STP. Если RSTP это тот же STP, только с более оптимизированной отправкой BPDU и в целом работы STP, то почему надо придумывать MSTP, который работает на основе RSTP? Основная фишка MSTP — это умение работать с VLAN-ми. Некоторые читатели могут сказать — «Подождите, а разве на Cisco pvst+ и rpvst+ не умеют работать с вланами?» RPVST+ и PVST+ просто запускает автономные инстанции RSTP или STP в пределе одного влана. Но тут возникают проблемы:
spanning-tree mst configuration
name Note
instance 1 vlan 10-50
instance 2 vlan 51-100
До начала поля MST Extension, BPDU MSTP очень трудно отделить от BPDU RSTP и, грубо говоря, IST это есть классический RSTP. MSTP лишь добавляет данные о MSTI. В BPDU хранится информация о Root Bridge для Instance 0-2. Таким образом, для всех вланов и инстанций отправляется только один BPDU, который содержит всю необходимую информацию. Это огромная экономия по сравнению с PVST+ и RPVST+. Посмотрим вывод команды show spanning-tree mst на коммутаторе Sw2:
Для instance 0 есть специальное поле — Regional Root. Regional Root мы выбрали Sw3 при помощи команды spanning-tree mst 0 root primary. Regional Root — это корневой коммутатор для MSTI 0 в пределах одного региона. Для MSTI1 Root также Sw3, а для MSTI2 — Sw2. В плане блокирования портов и сходимости MSTP повторяет принципы RSTP на основе которого и работает, поэтому, думаю, работа MSTP в пределах одного региона довольно понятна. Рассмотрим топологию с двумя регионами:
Про Region A было сказано выше, теперь попытаемся разобраться как взаимодействую между собой регионы. В region B у коммутаторов следующая конфигурация:
spanning-tree mst configuration
name RegionB
instance 1 vlan 10-30
instance 2 vlan 31-60
При этом Sw9 — spanning-tree mst 1 root primary — корневой коммутатор для Vlan 10-30, а Sw10 — spanning-tree mst 2 root primary — корневой коммутатор для Vlan 31-60.
Построение дерева STP в Region B аналогично Region A и было описано выше. Только скажем, так как мы не задавали Root Bridge для MSTI 0 в Region B, то он будет выбран по наименьшему MAC-адресу среди Sw9-12. Наименьший MAC-адрес у Sw9. Вывод команды с Sw10:
IST — это дерево в пределах одного региона, CIST — это дерево между регионами, CST — это дерево, объеденившее в себе и деревья внутри региона, и дерево для соединения регионов.
Так как мы ввели команду spanning-tree mst 0 root primary на Sw3, то CIST Root Bridge для обоих регионов будет Sw3. Если во всей топологии всего один регион, то Regional Root Bridge и CIST Root Bridge совпадают. Если регионов много, то выбирается лучший Regional Root среди всех регионов. Также в выборах на роль CIST Root Bridge могут использоваться коммутаторы, которые используют протоколы отличные от MSTP. Если попытаться построить общую картину, то объяснить взаимодействие регионов можно так: Каждый регион представляется объединение некоторого количества коммутаторов и представляется другим коммутаторам как один большой виртуальный коммутатор. То есть, если рассмотреть нашу топологию глазами региона B, то для него получится такая картина:
Аналогично будет и для региона А, регион В будет представляться одним коммутатором. В каждом регионе, у каждого коммутатора есть Root Port, подключающий его к Regional Root. Также у каждого региона выбирается один Root Port для MSTI 0, который ведет к общему СIST Root Bridge. Такими портами могут быть порты Gi1/1 на Sw9 и Sw10, так как они соединяют регионы. В нашей топологии, Sw9 обладает лучшим Bridge ID, то Root Port выбирается на нем, а на Sw10 порт Gi1/1 блокируется. На Sw9 для MSTI 0 порт Gi1/1 он является Root Port, но, например, для MSTI 1 и 2, есть Root Port для Instance Root Bridge и порт, который ведет к CIST Root Bridge, получает новую роль — Master. От отдного региона к другому может быть только один работающий канал или другими словами только один Master порт и только на одном коммутаторе. Вот информация о MST на коммутаторе Sw9, на котором будет выбран Master порт, обратите внимание на порт Gi1/1:
Данный порт для MSTI 0, как мы говорили, имеет роль Root, а для MSTI 1-2 Master. Также вводится новый тип канала — P2p Bound ( RSTP). Тип Boundary присваивается тем портам, которые стоят на границе с другим регионом или другой разновидностью протокола STP. Через Master порт в данный регион передается информация о CIST Root Bridge, отличительная черта заключается также в том, что данный порт сам по себе не отправляет BPDU, а только принимает, в отличие от типа порта P2P в RSTP. Исключением является только BPDU с флагом TC (изменение топологии). Посмотрим, как коммутатором в одном регионе обрабатывается BPDU из другого региона. Как мы сказали на Master порте Gi1/1 Sw9 будут приниматься BPDU от Sw1, при этом сам Sw9 отправлять не будет, рассмотрим его еще раз:
Sw10(config-if)# spanning-tree mst 0 priority 61440
Sw10(config-if)# interface gigabitEthernet 1/1
Sw10(config-if)# spanning-tree mst 0 cost 10000
И мы получим, что Sw10, несмотря на свой ужасный приоритет, стал Regional Root Bridge:
Таким образом, выбор Regional Root Bridge происходит в такой последовательности и никогда не может Regional Root Bridge быть коммутатор без граничных портов:
Возможны два случая:
Случай же, когда Root Bridge находится среди RPVST коммутаторов более сложный и нерекомендованный. Представим, что у нас RSTP1 является Root Bridge для всех вланов. Для простоты будем считать, что созданы вланы 1-3 и введена команда spanning-tree vlan 1-3 priority 12288, самый низкий приоритет среди RSTP и MSTP коммутаторов. Sw10 начнет получать BPDU по каждому из вланов. Очень важно понимать, что MSTP коммутатором будет обработан только BPDU для Vlan 1. Как это проиходит?
Попытаемся объяснить. Sw10 принял по native vlan BPDU для vlan 1 с приоритетом 12288+1. Обработал и решил, что Gi1/0 его Root Port. Потом пришли PVST BPDU для остальных вланов (1-3), он их изучил для проверки целостности корневого коммутатора и там оказались приоритеты 12288+2, 12288+3 для вланов 2-3, которые больше чем 12288+1. Целостность разрушается — с одной стороны это должен быть Root Port, а получение других более больших приоритетов заставляет порт перейти в роль Designated. Такая двусмысленность непозволительна для таких протоколов и MST блокирует данный порт переводя его в состояние BKN, сообщая об ошибке — Blocking root port Gi1/0: Inconsitent inferior PVST BPDU received. Чтоб предотвратить такое, необходимо, чтоб ни один vlan, BPDU которого будут передаваться по данному порту, не имел приоритет хуже (больше), чем у vlan 1. То есть, если мы уменьшим приоритеты вланов 2-3 до 4096, заведомо меньше, чем у влана 1, то исправим данную проблему.
Как видим, появилось сообщение, которое восстанавливает правильную работу порта — PVST Simulation inconsistency cleared on port GigabitEhternet 0/1.
На этом, думаю, завершить разговор о MSTP. Полезные ссылки внизу: