Как оптимизировать сервер Minecraft, не сломав фермы

Снизить simulation-distance — не то же самое, что снизить view-distance. Первый параметр меняет область вокруг игрока, которую сервер симулирует; второй определяет, сколько данных о ландшафте отправляется игрокам. Далёкий пейзаж может оставаться видимым, хотя ферма там уже ведёт себя не так, как ожидает её владелец.

Это различие важнее, чем поиск конфигурации с пометкой «оптимизированная». Сервер, который стал тише, мало что выигрывает, если жители перестали обновлять товары или привычное AFK-место перестало работать. Цель — убрать работу, без которой сообщество может обойтись, а затем проверить, что нужный вам игровой процесс по-прежнему работает.

Это руководство посвящено современным серверам Minecraft Java Edition. Настройки дальности применимы к Vanilla, Spigot и Paper; команды плагинов и параметры YAML обозначены отдельно. Это не универсальный рецепт для Bedrock, сборок модов или Folia. Сверяйте документацию с точной версией вашего сервера: актуальные материалы могут описывать более новые релизы, а значения по умолчанию и структура файлов не остаются неизменными.

1. Измерьте проблему в тот момент, когда она возникает

Запишите версию Minecraft, серверное ПО и его сборку, число игроков и то, чем занимаются игроки, когда возникает замедление. Оживлённый торговый зал и группа, исследующая новую местность, создают разную нагрузку. Профилирование пустого сервера не объяснит ни то, ни другое; документация Paper прямо требует, чтобы проблема проявлялась во время сбора данных.

В Paper spark входит в комплект начиная с версии 1.21. В Spigot сначала установите совместимый автономный плагин spark; перечисленные ниже команды не встроены в немодифицированный сервер Vanilla.

Выполните их в игре, имея необходимые права:

code

/spark tps
/spark profiler start --timeout 600

Команда профилировщика ведёт запись в течение десяти минут и возвращает URL отчёта. Сохраните этот отчёт вместе с конфигурацией и заметками о нагрузке.

При обычной частоте тиков Minecraft стремится к 20 TPS, то есть на каждый тик отводится 50 миллисекунд. MSPT показывает, сколько длятся тики, поэтому выявляет нагрузку, которую одно значение TPS может скрыть. Сравнивайте медиану и 95-й процентиль MSPT: последний помогает обнаружить повторяющиеся медленные тики, но может пропустить редкие всплески. Проверяйте и максимум, а не считайте здоровый процентиль доказательством того, что ничего не зависало.

При периодических проблемах монитор тиков spark может отмечать тики, превышающие этот бюджет:

code

/spark tickmonitor --threshold-tick 50

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

2. Сделайте резервную копию и определите, какие настройки действительно применяются

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

Используйте текстовый редактор, сохраняйте отступы YAML и меняйте что-то одно за эксперимент. После этого запустите сервер как обычно и изучите стартовый лог на предмет ошибок конфигурации. Не используйте /reload или горячую загрузку плагинов как обходной путь; перезагрузка плагинов может оставить зависимости и состояние несогласованными.

Для Vanilla начните с server.properties. Для Spigot и Paper дополнительно изучите spigot.yml: настройки дальности для отдельных миров могут переопределять файл properties.

Этот фрагмент показывает наследование, а не пресет производительности:

yaml

world-settings:
  default:
    view-distance: default
    simulation-distance: default

Здесь default указывает этим параметрам использовать значения из server.properties. Добавьте ключи в существующий раздел; не заменяйте весь файл и не добавляйте второй блок world-settings. Проверьте и разделы именованных миров, потому что значение для конкретного мира может переопределить общий параметр.

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

3. Разделите видимость ландшафта и симуляцию

Обе дальности измеряются в чанках вокруг игрока, а не в блоках и не в диаметре.

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

Упрощённая синяя зона видимости и меньшая янтарная зона симуляции вокруг одного и того же игрока. Действуют и другие правила загрузки и близости.

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

Попробуйте изменить одну дальность

Предположим, ваш server.properties содержит:

properties

view-distance=10
simulation-distance=10

Если профиль указывает на работу тиков по загруженным областям, один из экспериментов — оставить view distance без изменений и немного уменьшить simulation distance:

properties

view-distance=10
simulation-distance=8

Эти числа приведены для иллюстрации, это не универсальные значения по умолчанию и не проверенный пресет SharpHeberg. Если ваше текущее значение view distance отличается, не трогайте его. Корректно перезапустите сервер, воспроизведите исходную нагрузку и соберите ещё один отчёт, прежде чем снижать значения дальше.

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

Simulation distance — не полный свод правил для ферм. Тикеты чанков, удерживающие чанки загруженными по определённым причинам, и требования к близости игрока различаются в зависимости от механики и версии. «Загружен» не гарантирует, что спавн, рост культур, сущности и блок-сущности ведут себя одинаково. Проверяйте требования именно вашей фермы, а не предполагайте, что одно значение дальности гарантирует её работу.

У естественного спавна и исчезновения мобов есть и собственные правила дальности; дополнительные настройки дают mob-spawn-range в Spigot и параметры despawn в Paper. Если после эксперимента ферма перестала работать, сначала верните прежнюю дальность. Не спешите компенсировать это изменением нескольких настроек спавна.

4. На Spigot или Paper изучите работу сущностей, прежде чем сокращать радиусы

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

Две похожие по названию настройки spigot.yml выполняют разные задачи:

Параметр	Единица	Что контролирует
`entity-activation-range`	Блоки	Насколько близко к игрокам должны быть сущности, чтобы тикать в обычном режиме; за пределами радиуса поведение замедляется.
`entity-tracking-range`	Блоки	На каком расстоянии сущности отправляются игрокам, что влияет на момент их появления в поле зрения.

Это настройки сущностей, а не описанные выше дальности в чанках. Меньший радиус отслеживания может привести к резкому появлению мобов; это не равнозначно снижению нагрузки на их ИИ.

Изменения активации требуют особой осторожности рядом с железными фермами и жителями. В материалах сообщества описаны сломанные фермы и проблемы с обновлением товаров, вызванные слишком агрессивными изменениями активации или неактивных жителей. Не трогайте эти настройки, если профилирование не оправдывает компромисс, а затем тестируйте затронутую категорию сущностей, а не копируйте готовый пресет целиком.

Та же осторожность нужна для nerf-spawner-mobs, тайминга воронок и изменений слияния предметов: они меняют поведение, а не просто потребление ресурсов. Не урезайте лимиты мобов повсеместно и не устанавливайте плановое удаление сущностей в качестве первой реакции на лаги.

5. Воспринимайте настройки Paper как зависящие от версии

У Paper есть дополнительные уровни конфигурации. Его описанная в документации структура включает config/paper-global.yml для глобальных настроек и config/paper-world-defaults.yml для общих настроек миров. Файл paper-world.yml конкретного мира может переопределять эти значения по умолчанию.

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

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

Указанный справочник spigot.yml поддерживается Paper и включает поведение, специфичное для Paper. Не считайте, что каждый описанный в нём вложенный параметр существует или ведёт себя одинаково в чистом Spigot. Прежде чем добавлять ключ, изучите сгенерированную конфигурацию для вашей реализации и версии.

6. Выходите за рамки настроек дальности вслед за профилем

Изучите работу плагинов

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

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

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

Предварительно генерируйте мир, только если проблема в генерации

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

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

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

7. Проверьте игровой процесс, прежде чем оставить изменение

Повторите исходную нагрузку при сопоставимом числе и распределении игроков. Храните вместе отчёты spark до и после, разницу в конфигурации и заметки. Повторите сравнение, если условия заметно изменились.

Затем протестируйте сервер так, как им пользуются игроки:

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

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

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

Рекомендуем также: Реальная стоимость производительного сервера Minecraft в 2025 году. Любые цены в той более старой статье следует считать историческими, а не актуальными тарифами.