[Блог] Апдейт о RPi, GNU Linux и серверной составляющей Minecraft

Поковырялся в 64-битном дистрибутиве, повозился с ванильным 1.16.5, попробовал запустить 1.17.1 под Spigot и Paper. Ситуация складывается непростая, но есть с чем работать. Подробности внутри.

В качестве операционной системы выбрал дистрибутив GNU Linux - DietPi, модифицированный скриптами Debian. Дистрибутив крайне легкий по потреблению ресурсов и имеет интуитивно понятный функционал. Урезал всё, что мог урезать (DHCP, HDMI). Доступными стали 915.2 из 960 мегабайт.

По заявлению тех, кто успел протестировать 64 бита, система должна работать немногим шустрее 32-битки.

В погоне за производительностью упустил одну важную деталь. 64-битная версия занимает банально больше места в RAM. Поставил на вторую карту 32-битку, буду тестировать параллельно. В ней доступны 943,7 из 973 мегабайт.

В итоговой инструкции я постараюсь подробно раскрыть все вопросы.

Сейчас короткие итоги.

Мне удалось выиграть в кремниевой лотерее CPU. 1400 MHz взяты без заметной потери стабильности. Остановился на этой частоте, так как последующее её поднятие проводило к сокращению прироста производительности (и результаты стали неоднозначно скакать).

Пришлось потратиться на новую SD карту, так как псевдо-топ от Samsung Evo + (или Plus) в какой-то момент успели ребрендировать и переработать, вместе с чем производительность карты на RPi упала. В моём же случае, скорее всего, я успел сжечь контроллер за время предыдущих экспериментов. Максимальная скорость в тестах случайного чтения/записи не поднималась выше 0.N значений.

Впоследствии я приобрёл SanDisk Extreme A2 на 128гб. Разогнал карту на половину от возможного. Результат меня устроил, на том и остановился. Не спешу убивать ещё одну карту.

Оперативная память. Вот тут-то я в лотерее «проиграл» (не с треском, результаты всё ещё в средней зоне). Предельным, стабильным значением я выбрал 508 Mhz. Превентивно отвечу на вопрос "почему не 510", — для маленького потолка стабильности над головой. 510 мегагерц чуть чаще светится в аутсайдерах, чем 508 мегагерц. Из этого моя думалка решила, что 508 будет стабильнее себя вести и был таков.

P.S. На 530 мегагерц не смотрите. Этот заяц по всей поляне скачет и таймингами (вольтажом) не стабилизируется.

По доступным результатам тестов я засел крепко в середине топа производительности и выше себя прыгнуть не смогу, а хотелось бы. В случае с сервером, нехватка производительности памяти будет ощутима. Отключение HDMI модуля и уход полностью в headless обещали процентный прирост производительности, но посмотрим как пойдёт на деле.

Тезисно.

На данный момент успел протестировать Fabric 1.16.5, Spigot 1.16.5 (если мне не изменяет память) и Paper 1.17.1 (надо так же проверить на 1.16.5) на 64-битной версии операционной системы. Проверял вскользь, чтобы понять как обстоят дела с потреблением оперативной памяти.
С Fabric 1.16.x работа вроде бы возможна. Я сделаю всё, что есть в моих силах, чтобы его сбалансировать. Данная версия, на данном загрузчике для меня имеет особую важность из-за мода на генерацию мира, Overworld two. Я не знаю как разработчик мода это сделал, но на глаз он достиг скоростей генерации мира уровня ZGC, если не выше. Жаль Starlight не выходил на данную верcию, в арсенале остался только Phosphor.
Производительность и объём свободной памяти после Spigot'a не внушают надежды на его актуальность на малине. Но, интереса ради, посмотрю как он себя проявит на иных версиях.
Производительность и объём свободной памяти после Paper`a... крашнули сервер после моего входа в него. В обсуждениях о его оптимизации я наткнулся на информацию о минимальных значениях RAM в 2 гигайбайта. Проверю его ещё разок, но похоже этот вариант совсем не подходит в сложившейся ситуации.
Для того, чтобы разгрузить процессор от лишней нагрузки, я отдельно сгенерирую карту мира на своём ПК под каждую версию по определённому сиду.

На протяжении непродолжительной работы над собственным сервером и данным проектом, у меня складываются исключительно негативные впечатления о том, как и куда идёт разработка игры. Обратно пропорционально этому, я поражаюсь упорству разработчиков модов и высокопроизводительных серверных решений.

С каждым новым релизом крупного обновления, игра становится более всё требовательной к железу. Производительность на отдельно взятом устройстве между (допустим) версиями 1.12.2 и 1.17.1 отличается в разы, в негативную сторону. И это при том, что на 1.12.2 она была далеко не пределом мечтаний. Лично у меня 1.12.2 "заикалась" постоянно.

Для владельцев многопользовательских серверов такая закономерность и вовсе боком обходится. В последующем видео описывается причина, по которой самый известный сервер, 2b2t не мог покинуть версию 1.12.2 на протяжении многих лет и релизов.

Tl;dr: с выходом 13ого обновления майнкрафта, игра перестала адекватно работать на серверах численностью 200 человек. Вне зависимости от мощности железа. Плюс ко всему, мы говорим о Java, о голодном до памяти и скромном до ядер языке программирования.

The Biggest Problem with Minecraft Servers - Why 2b2t is Stuck on 1.12.2 от SalC1

На данный момент времени, 2b2t всё таки смог мигрировать на версию 1.16.4.

Во всём этом откровенно жаль разработчиков модификаций. Выходит обновление на игру, что-то изменилось и надо чинить старые моды. Устранять конфликты в рецептах (медь и 1.17.1), портировать старые моды вперёд, новые портировать назад и это при условии, что крупные сервера могут остаться стоять на месте, когда бытовые пользователи идут вперед к новому контенту.

И ладно бы этот контет хорошо работал, а не был сделан ягодицами наполовину...