Почему лагает сервер Minecraft и как починить лаги

Если ты задаёшься вопросом, почему лагает сервер майнкрафт, в 90% случаев дело в одном из шести: нехватке оперативки и сборке мусора, слабом ядре процессора, тяжёлых плагинах, мобах и фермах, медленном диске или слишком большом view-distance. Хорошая новость — почти всё это диагностируется за пару команд и чинится без переустановки мира. Разберём по порядку: как измерить лаги, найти виновника и убрать его.

Сначала разберись: это лаги сервера или твоего клиента

Прежде чем что-то чинить, важно понять, где именно проблема. «Лагает» — слишком общее слово, и игроки часто путают три разные вещи.

• Лаги сервера (server lag) — падает TPS. Мир тормозит у всех сразу: мобы дёргаются, удары не регистрируются, блоки ломаются с задержкой. Это то, что ты как админ реально можешь чинить.
• Фризы клиента (низкий FPS) — дёргается картинка только у одного игрока. Виноват его ПК, видеокарта или шейдеры, а не сервер.
• Пинг (лаг сети) — задержка между игроком и сервером. У игрока «резиновость» движения, но TPS на сервере при этом 20.0. Лечится выбором локации поближе.

Простой тест: зайди на сервер и введи /tps. Если там стабильные 20.0, а кто-то жалуется на лаги — проблема на его стороне (ПК или интернет), а не у тебя. Если TPS просел — добро пожаловать, дальше всё про тебя.

TPS и MSPT: две цифры, которые надо понимать

Сервер Minecraft работает тиками — это «кадры» игровой логики. За секунду должно проходить ровно 20 тиков, и каждый тик сервер должен успеть обработать за 50 миллисекунд или меньше (1000 мс / 20 = 50). Отсюда два ключевых показателя.

MSPT — более честный и чувствительный показатель. TPS не может превысить 20, поэтому при «здоровом» сервере он всегда показывает 20.0 и ничего не говорит о запасе прочности. А MSPT покажет правду: если тик занимает 45 мс, у тебя TPS ещё 20, но запаса почти нет — любой всплеск, и сервер начнёт захлёбываться. Поэтому ориентируйся именно на MSPT: чем он ниже и стабильнее, тем больше места для роста онлайна.

Как измерить лаги: spark, /tps и /mspt

Угадывать причину лагов — путь в никуда. Нужно измерять. На ядрах семейства Paper (включая Purpur) есть встроенные команды и профайлер.

Быстрая проверка

/tps     # средний TPS за 5с / 1мин / 5мин / 15мин
/mspt    # среднее, минимум и максимум MSPT за последние тики

/tps покажет четыре числа — мгновенное значение и средние за интервалы. Если последнее (15 мин) низкое — лаги хронические. Если просаживается только мгновенный TPS — у тебя короткие спайки, а не постоянная просадка, и искать надо разовое событие (взрыв крипера в редстоуне, прогрузка чанков новым игроком).

Профайлер spark — главный инструмент

Раньше для диагностики использовали /timings, но в современном Paper таймингс отключён и заменён на spark — это рекомендация самих разработчиков Paper. Spark делает сэмплирующий профайл главного потока и показывает, какой именно код жрёт время тика.

/spark profiler start
# ... подожди 3-5 минут под обычной нагрузкой ...
/spark profiler stop      # выдаст ссылку на отчёт

# для редких спайков — профилировать только тяжёлые тики:
/spark profiler start --only-ticks-over 60

В отчёте ты увидишь дерево вызовов: например, что 40% времени уходит на EntityLiving.tick (мобы) или на конкретный плагин. Это и есть твой виновник. Дополнительно /spark health покажет загрузку CPU и использование памяти. Не уверен, как читать flame-graph — начни с самых «толстых» веток сверху, они отъедают больше всего.

Причина 1. Нехватка RAM и сборка мусора (GC)

Самая частая и самая коварная причина лагов — не нехватка памяти сама по себе, а паузы сборщика мусора. Когда серверу мало кучи (heap), JVM постоянно запускает Garbage Collection, чтобы освободить место. Каждая такая сборка — это микро-фриз: главный поток замирает, тик растягивается, TPS падает. Внешне это выглядит как ритмичные спайки лагов каждые несколько секунд.

Парадокс в том, что слишком много RAM тоже вредит: чем больше куча, тем дольше длится одна большая сборка мусора. Поэтому цель — выделить «в самый раз» под твою сборку и онлайн. Для ваниллы и Paper на 5–10 человек обычно хватает 4–6 ГБ, средний модпак просит 8–12 ГБ, тяжёлые сборки — больше. Точный расчёт под версию, лоадер и количество игроков мы разобрали в гайде сколько RAM нужно серверу Minecraft.

Ключ к укрощению GC — правильные JVM-флаги. Aikar flags настраивают сборщик G1GC так, чтобы паузы были короткими и предсказуемыми (цель MaxGCPauseMillis=200), а память освобождалась заранее, а не в момент пика. Это бесплатный прирост стабильности — просто добавь флаги в строку запуска.

Причина 2. Слабое ядро процессора

Запомни главное про Minecraft: он почти полностью однопоточный. Вся основная игровая логика — мобы, редстоун, генерация, тики блоков — крутится в одном потоке. Это значит, что серверу важна не «многоядерность», а частота и сила одного ядра. Восьмиядерный процессор со слабыми ядрами проиграет четырёхъядерному с высокой частотой.

Вот почему сервер может лагать при куче свободной RAM: упёрся не в память, а в потолок одного ядра. MSPT растёт, потому что ядро физически не успевает обработать тик за 50 мс. Особенно это бьёт по дешёвым VPS, где стоят старые серверные процессоры с низкой частотой, да ещё и поделённые между десятком клиентов.

Причина 3. Тяжёлые плагины и моды

Каждый плагин и каждый мод выполняет код в том самом главном потоке. Один плохо написанный плагин (особенно с частыми проверками регионов, сканированием инвентарей или синхронными запросами к базе) способен в одиночку обрушить TPS. Моды опаснее плагинов: тяжёлый технический модпак добавляет тысячи новых сущностей, машин и тиков мира.

Здесь снова выручает spark: в отчёте плагины и моды видны поимённо со своей долей времени тика. Алгоритм простой:

1. Сними профайл, найди в дереве вызовов имя плагина/мода-пожирателя.
2. Отключи его, перезапусти, сравни MSPT.
3. Если стало заметно лучше — ищи замену, обнови до свежей версии или настрой интервалы его задач.

Для модпаков отдельно важны железо и память — почему, мы разобрали в подборке про хостинг для модпаков. Кстати, неважно, Forge у тебя или Fabric: оптимизирующие моды есть для обоих лоадеров, и они дают огромный выигрыш (об этом ниже).

Причина 4. Мобы, фермы и редстоун

Сущности (entities) — классический убийца TPS. Каждый моб, каждый предмет на земле, каждая рамка и вагонетка тикают каждый игровой тик. Когда на сервере накапливаются сотни мобов, огромные мобофермы и десятки активных hopper-воронок, главный поток просто не успевает всё обработать.

• Hopper-лаги. Воронки — одни из самых дорогих по тикам блоков. Сортировки на сотнях hopper-ов прожигают MSPT. Минимизируй число активных воронок, используй фильтры и водные стримы вместо длинных цепочек.
• Мобофермы. Огромные фермы с тысячами мобов в загрузке — частая причина спайков. Ограничивай высоту и используй убийство по таймеру.
• Редстоун-схемы. Тактовые генераторы и большие автоматические схемы тикают непрерывно. Один забытый clock в углу карты может тихо есть TPS месяцами.
• Накопление предметов. Дропнутые вещи, которые никто не подбирает, копятся тысячами. Настрой авто-очистку (merge-radius, лимит item-ов).

На ядрах Paper/Purpur есть тонкие лимиты в spigot.yml и paper-world-defaults.yml: mob-spawn-range, лимиты мобов на чанк, тики сущностей. Снизь их — и MSPT от мобов ощутимо упадёт.

Причина 5. Генерация чанков и диск

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

На NVMe-дисках (особенно Gen4 со скоростью чтения порядка 7 ГБ/с) эта проблема практически исчезает: чанки грузятся мгновенно, сейв мира не замечается. Если лаги совпадают именно с исследованием новых территорий или с автосохранением — присмотрись к диску хостинга.

Причина 6. Слишком большой view-distance и simulation-distance

Два параметра в server.properties напрямую умножают нагрузку:

view-distance=10          # сколько чанков видно игроку
simulation-distance=10    # в скольких чанках вокруг тикает логика

simulation-distance — особенно дорогой: чем он больше, тем в большем радиусе тикают мобы, редстоун и фермы вокруг каждого игрока. Снижение с 10 до 6–8 часто даёт заметный прирост TPS на людном сервере почти без ущерба для геймплея. view-distance влияет на сеть и генерацию — его тоже стоит держать в разумных 8–10. Полный разбор всех ключей мы собрали в статье про настройку server.properties.

Как починить: чек-лист решений

Собираем всё воедино. Идём от самого простого и бесплатного к более серьёзному:

1. Поставь Aikar flags. Самый быстрый бесплатный выигрыш против GC-спайков — готовая строка флагов в запуск.
2. Перейди на Paper или Purpur. Если ты ещё на Vanilla или Spigot — переход даёт оптимизацию сущностей, редстоуна и hopper-ов плюс десятки настроек лимитов. Сравнение в гайде Paper vs Purpur vs Vanilla.
3. Поставь оптимизирующие моды. На Fabric — Lithium (логика мира), на современном Forge/NeoForge есть его порты и аналоги. Они переписывают узкие места без изменения геймплея.
4. Сними профайл spark и убери конкретного пожирателя — плагин, мод или ферму.
5. Ограничь мобов и фермы: лимиты в конфигах, авто-очистка предметов, ревизия редстоун-схем.
6. Снизь simulation-distance до 6–8 и pre-generate мир заранее.

Когда виноват хостинг, а не ты

Иногда ты сделал всё правильно — оптимизировал плагины, поставил флаги, урезал фермы и view-distance — а MSPT всё равно высокий и не зависит от твоих действий. Тогда дело в железе хостинга. Три классических признака плохого хостинга:

Это ровно те места, на которых дешёвый хостинг экономит, а ты потом полночи читаешь spark-отчёты, не понимая, почему лагает сервер майнкрафт при идеальных конфигах.

И помни: лаги — это почти всегда решаемая задача. Начни с /mspt и spark, найди виновника по цифрам, а не на ощупь — и сервер снова заработает на честных 20 TPS. Если только начинаешь, загляни в большой гайд как создать сервер Minecraft: там разложено всё с нуля, включая правильный старт без будущих лагов.