Minecraft долго генерирует мир: как предгенерировать чанки на VPS и не перегрузить сервер

Игрок садится на элитры, разгоняется фейерверком и летит к горизонту. Под ним ничего нет: серверу приходится создавать рельеф, пещеры, биомы и структуры прямо сейчас, пока человек уже пролетает над этим местом. Картинка догоняет его рывками, у остальных в этот момент подтормаживает всё подряд, а в консоли копятся жалобы на задержки. Виноват не обязательно слабый сервер и не обязательно кривой плагин. Просто в одну и ту же секунду процессор делает две разные работы: ведёт игру и сочиняет мир.

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

Две работы, которые путают под одним словом «лаги»

Мир Minecraft состоит из чанков, и существует два принципиально разных состояния участка карты: его ещё нет, и он уже создан. Если участка нет, серверу нужно сгенерировать его: посчитать рельеф, заполнить блоками, разместить руды, деревья, структуры. Если участок создан, серверу достаточно прочитать его с диска и держать в памяти, пока рядом есть игроки. Это заметно более дешёвая операция.

Предгенерация сводит всё к простой идее: превратить дорогую работу «создать» в дешёвую «прочитать» заранее. Игрок, прилетевший в подготовленную область, больше не заставляет сервер что-то выдумывать. Сервер лишь поднимает с NVMe то, что уже лежит.

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

Радиус как обещание диску

Самая коварная часть предгенерации — не команда запуска, а число, которое вы в неё вписываете. Радиус кажется одним безобидным параметром, но площадь растёт с его квадратом.

Возьмём для наглядности квадратную область со стороной в два радиуса. Условный пример, не измерение: если радиус равен 1 000 блоков, сторона области 2 000, площадь 4 миллиона квадратных блоков. Увеличим радиус вдвое, до 2 000: сторона 4 000, площадь 16 миллионов. Вдвое больший радиус дал вчетверо больше территории. Втрое больший, 3 000, даст уже в девять раз больше, чем исходные 1 000. Общая формула проста: во сколько раз вы увеличили радиус, в стольких же раза в квадрате вырастет число чанков, а вместе с ними и время работы, и размер папки мира.

Один чанк занимает 16 на 16 блоков, то есть 256 колонн. Значит, число чанков в квадрате можно получить, разделив площадь на 256. Для условного квадрата 2 000 × 2 000 это порядка 15 600 чанков, для 4 000 × 4 000 около 62 500. Эти цифры — просто арифметика, а не прогноз скорости или размера. Сколько секунд уйдёт на один чанк и сколько мегабайт он займёт на диске, зависит от версии игры, ядра, генератора мира, наличия структур и мощности сервера. Эти величины нужно измерять у себя, и ниже описано, как.

Чтобы квадратичный рост стал осязаемым, сравним три условные карты, не привязывая их к скорости или размеру на диске. Берём квадрат со стороной в два радиуса и делим площадь на 256 блоков в чанке. Радиус 500 даёт сторону 1 000, площадь 1 миллион и около 3 900 чанков. Радиус 1 000 даёт около 15 600 чанков. Радиус 2 000 даёт около 62 500. Каждое удвоение радиуса означает вчетверо больше работы, а не вдвое.

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

Практический вывод: решение о радиусе — это решение о трёх ресурсах сразу.

• Время процессора. Чем больше чанков, тем дольше генератор занимает ядра.
• Дисковое пространство. Папка мира растёт вместе с числом созданных чанков, а на небольшом NVMe-диске это быстро становится заметно.
• Резервные копии и перенос. Огромный мир дольше архивируется и дольше копируется на другую машину.

Поэтому разумный порядок такой: сначала решить, какая территория вам реально нужна, потом оценить её площадь, а уже затем запускать задание.

Где на самом деле играет ваша группа

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

Чтобы определить полезную область, полезно ответить на несколько вопросов о вашей группе, а не о Minecraft вообще.

• Сколько людей и как они двигаются? Небольшая компания друзей, которая строит рядом, расходится по карте гораздо меньше, чем публичный сервер с исследователями.
• Есть ли естественные границы? Если вы играете с ограничением карты, радиус подготовки просто совпадает с ним, и вопрос закрыт.
• Нужны ли конкретные биомы и структуры? Иногда ради одного редкого биома приходится расширять зону, но тогда выгоднее подготовить отдельный участок вокруг него, а не раздувать всю карту.
• Насколько долго будет жить мир? Сезонная карта на пару месяцев нуждается в меньшем запасе, чем долгий мир, который собираются разрабатывать год.

Хорошая стратегия — идти от центра слоями. Подготовьте область вокруг точки появления и ближайших мест строительства с запасом, откройте сервер, понаблюдайте, куда на самом деле ходят игроки, и при необходимости дошлите ещё одно кольцо. Дополнительная генерация потом ничему не мешает: уже созданные чанки сохраняются, а расширение просто добавляет новую территорию. Лучше недоподготовить и расширить, чем создать огромный мир, половину которого никто не увидит.

Для расчёта запаса полезна простая привычка. Прикиньте, как далеко игроки обычно уходят от центра пешком и верхом, и добавьте расстояние, которое покрывает видимая дистанция сервера. Игрок на краю подготовленной области всё равно «видит» чанки вокруг себя, и если граница вплотную к краю, сервер начнёт создавать недостающие кусочки прямо при подходе. Запас по краю избавляет от этого эффекта.

Как выглядит задание в Chunky

Для самой подготовки в этом материале разбирается плагин Chunky. По его справке по командам задание описывается набором параметров: мир, форма области, центр и радиус. Радиус задаётся в блоках, если вы не указали специальную единицу измерения. Это важная мелочь: число 2 000 означает 2 000 блоков, а не чанков, и ошибка в единицах даёт разницу в шестнадцать раз по длине и в 256 раз по площади.

Отсюда прямое практическое правило: перед запуском переведите свою задумку в блоки и посчитайте площадь по формуле выше. Если получившееся число чанков вас пугает, радиус нужно уменьшать до старта, а не после того, как диск наполовину заполнен.

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

Разницу между кругом и квадратом легко прикинуть. Площадь круга радиуса R равна примерно 3,14 × R², а описанного квадрата со стороной 2R — 4 × R². Круг занимает около 78 % квадрата, то есть углы квадрата дают почти пятую часть лишних чанков. Для радиуса 1 000 это условно 15 600 чанков у квадрата против примерно 12 250 у круга. Углы стоит оставлять, только если они вам действительно нужны, например при жёсткой квадратной границе мира. Если же игроки концентрируются вокруг базы, круг убирает работу, которую никто не заметит.

Центр задания не обязан совпадать с нулевой точкой. Если база и ближайшие шахты смещены, например, на несколько сотен блоков, центр области разумно поставить рядом с ними. Параметры центра входят в описание задания наряду с миром, формой и радиусом по справке Chunky. Так радиус тратится на реальную территорию, а не на пустые участки по другую сторону от нуля.

Сначала малая область, потом большая

Главная ошибка — запустить задание на огромный радиус и ждать. Вы не узнаете, сколько это займёт, пока не измерите скорость на своём железе. Поэтому первым шагом стоит сделать пробу на маленькой области.

1. Выберите небольшой радиус, при котором число чанков невелико, но задание идёт заметное время.
2. Запустите его и засеките время работы от начала до конца.
3. Посмотрите, насколько вырос размер папки мира на диске.
4. Разделите время и объём на число созданных чанков, чтобы получить свои собственные цифры на чанк.

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

Если оценка по диску не сходится, у вас три выхода: уменьшить радиус, выбрать тариф с большим диском или вынести подготовку в другое время. Для сравнения ориентиры по тарифам MAATRIX такие: Ba — 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ и 80 ГБ; Heka — 4 vCPU, 8 ГБ и 160 ГБ; Maat — 8 vCPU, 16 ГБ и 240 ГБ; Djed — 16 vCPU, 32 ГБ и 320 ГБ. Это исходные ресурсы, а не обещание ёмкости: сколько игроков и какой радиус потянет конкретная конфигурация, показывает только ваш замер. Зато связь простая. Диск ограничивает размер подготовленного мира, а число ядер определяет, насколько удобно генерации сосуществовать с игрой.

Генератор против игроков за одни ядра

Пока идёт предгенерация, она занимает процессор и диск так же, как это делает любая интенсивная работа. Если в этот момент на сервере играют люди, две задачи конкурируют. Игровой цикл Minecraft чувствителен к задержкам: ему нужно укладываться в короткий интервал на каждый такт. Когда генератор отнимает ресурсы, такты начинают затягиваться, и игроки замечают это как лаги. То есть, подготовив мир ради избавления от подтормаживаний, можно создать такие же подтормаживания на время самой подготовки.

Причина конфликта в том, что у игрового цикла нет запаса «на потом». Если такт не уложился в отведённое время, отставание видят все сразу: блоки ломаются с задержкой, мобы дёргаются, пакеты приходят пачками. Генерация же устроена наоборот: ей всё равно, закончит ли она на минуту раньше или позже, лишь бы ядра были заняты. Когда эти две работы делят один небольшой набор vCPU, генератор способен занять ядра так плотно, что игре достаётся только остаток. Чем меньше ядер, тем заметнее эффект: на конфигурации с одним vCPU, как у тарифа Ba, подготовка и игра по сути ждут друг друга в одной очереди, а на 4–8 vCPU у них больше шансов не мешать друг другу. Сколько именно ядер нужно, покажет только замер на вашей нагрузке, а не табличное число из тарифа.

Диск добавляет вторую очередь. Подготовка постоянно записывает новые данные мира, а игра в это же время читает и сохраняет уже существующие. Поэтому ночное окно для большой работы подходит не просто «для удобства»: оно разводит две нагрузки во времени, а не заставляет их толкаться за одни и те же ресурсы.

Поэтому разумны два режима работы.

• До открытия. Мир ещё пуст, никто не играет, генерации можно отдать почти всё. Это идеальное время для большой работы.
• При онлайне. Если нужно дошлифовать мир, пока игроки заходят, задание лучше ставить на паузу или запускать в часы минимальной активности.

У Chunky для этого есть команды, описанные в той же справке: pause приостанавливает задание и сохраняет прогресс, а continue продолжает с того места, где остановились. Это значит, что подготовку можно безопасно делить на сеансы. Например, ночью идёт работа, утром перед приходом игроков вы ставите паузу, а следующей ночью продолжаете. Прогресс не теряется, и повторно создавать то же самое не придётся.

Тут легко перепутать команды, поэтому отметим различие. Команда cancel удаляет само задание, но уже созданные чанки остаются на диске. Это не откат: если вы остановили работу на середине и отменили её, подготовленная часть мира никуда не денется. Отдельная команда trim занимается противоположным: она удаляет чанки, и перед её использованием необходима резервная копия. Это не вариант «отменить генерацию», а операция по сокращению мира, и применять её стоит осознанно, понимая, что вы стираете часть карты. Если вам просто нужно остановиться, нужны pause или, в крайнем случае, cancel, но никак не trim.

Убедиться, что проблема была в генерации

Прежде чем тратить часы на подготовку, имеет смысл проверить, действительно ли лаги связаны с созданием чанков. Для этого служит профилирование. В документации Paper сказано, что профиль полезен тогда, когда исследуемая проблема воспроизводится во время записи. Иначе вы запишете спокойный сервер и ничего полезного не увидите.

Для нашей задачи это означает конкретный сценарий. Запустите запись профиля и в это время заставьте сервер делать то, на что вы жалуетесь: отправьте игрока в неисследованную область. Если в отчёте основное время уходит на создание местности, диагноз подтверждён, и предгенерация сработает. Если же время съедают сущности, плагины или что-то ещё, подготовка карты не решит проблему, и усилия лучше направить в другое место.

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

Практичный приём: сделайте две записи по одному сценарию, одну над давно освоенной территорией, другую над нетронутой. Если различие между ними велико, источник проблемы именно создание мира. Если нет, лаги живут независимо от того, куда летит игрок. Такое сравнение стоит минут десять и избавляет от нескольких часов бесполезной подготовки. Помните: как отмечено в документации Paper, профиль полезен только при воспроизведённой проблеме, поэтому оба полёта нужно выполнять во время записи.

Есть и важная оговорка по окружению. По той же документации, Paper включает профайлер spark начиная с ветки 1.21. Если вы запускаете другое ядро или более раннюю версию, наличие профайлера нужно проверять отдельно, а не считать его встроенным по умолчанию. Это та мелочь, которая экономит час, потраченный на поиск несуществующей команды.

Проверка до открытия мира

Когда подготовка закончена, остаётся убедиться, что результат соответствует замыслу. Вместо универсального списка достаточно нескольких конкретных проверок, связанных именно с генерацией.

• Размер на диске. Сравните фактический размер папки мира с оценкой, которую вы сделали по пробе. Большое расхождение говорит о том, что разные районы карты заметно отличаются по тяжести, и это полезно знать до расширения.
• Свободное место с запасом. Мир продолжит расти по мере игры: строительство и изменения тоже занимают диск. Оставьте запас, а не заполняйте его до краёв.
• Пролёт у границы. Отправьте игрока к краю подготовленной области и понаблюдайте. Если за границей сервер снова начинает создавать местность, ощутимо ли это по задержкам? Для небольшой группы это допустимо, для большой стоит сдвинуть границу.
• Повторный профиль. Если вы использовали профилирование до подготовки, повторите то же действие после и сравните отчёты. Это самое надёжное доказательство, что работа была не зря.

Если вы только настраиваете сервер и ещё не определились с самим окружением, пригодится отдельный материал о том, как установить и настроить Minecraft на VPS. Предгенерацию логично делать после того, как базовая установка уже работает и вы знаете, какая версия и какое ядро у вас запущены.

Где остановиться

Соблазн «подготовить всё» понятен, но он противоречит самой природе мира Minecraft: его размер практически не ограничен, а ваш диск, время и терпение ограничены строго. Любая подготовка — это выбор конечной области, и хорошая карта отличается не размером, а тем, насколько точно эта область совпадает с тем, где реально идёт игра.

Практичный предел выглядит так: территория, которую ваша группа реально освоит в обозримом сезоне, плюс запас по краю, чтобы подходы к границе не заставляли сервер создавать мир на ходу. Дальше — тишина и непрогруженная пустота, и пусть она остаётся такой, пока кто-нибудь действительно не полетит в ту сторону. Тогда вы увидите это по отчёту, дошлёте ещё одно кольцо чанков и сдвинете границу на столько, на сколько она понадобилась. Подготовленная карта не обязана быть бесконечной. Ей достаточно быть готовой там, где вы будете играть.