Низкий TPS и лаги на Minecraft-сервере

MAATRIX GAMES

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

Шаг 1: смотрим /tps и понимаем цифры

Первым делом — не гадать, а посмотреть на реальную метрику. На Paper, Spigot и большинстве их форков команда /tps встроена и работает сразу из консоли или в чате с правами оператора:

/tps

Она покажет три числа — среднее TPS за последние 5 секунд, 1 минуту и 5 минут. Идеал — стабильные 19.5-20 (движок Minecraft жёстко считает 20 тиков в секунду, по 50 мс на тик). Разовая просадка до 15-17 на пару секунд во время взрыва или массового боя — это нормально и не повод для паники. А вот если пятиминутное значение устойчиво ниже 18 — это уже системная проблема, а не случайный всплеск.

Если у тебя ядро на голом Forge или Fabric без Paper-совместимости — команды /tps из коробки может не быть, тогда нужен профайлер вроде spark (о нём чуть ниже), он умеет то же самое и больше.

Второй быстрый способ подтвердить проблему — залезть в лог сервера (logs/latest.log) и поискать строку:

Can't keep up! Is the server overloaded?

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

Типичные причины: от частых к редким

Если диагностика подтвердила устойчивую просадку, вот с чего стоит проверять по убыванию частоты — в таком порядке чаще всего и находится виновник:

1. Перегруженные редстоун-фермы и автоматизированные постройки. Большие редстоун-машины, автоматические сортировщики, фермы на таймерах, промышленные цепочки в модпаках (Create, Applied Energistics и подобные) — каждый компонент считается каждый тик. Одна плотная ферма способна съедать заметный кусок бюджета тика сама по себе, особенно если она работает круглосуточно, а не только когда игрок рядом.
2. Слишком высокий view-distance/simulation-distance для мощности тарифа. Дефолтное значение 10 в ванильном сервере рассчитано с запасом, а не под конкретный тариф — на слабой конфигурации или при большом онлайне это часто избыточно.
3. Утечка мобов и сущностей на карте. Фермы мобов без сборщика дропа, забытые стойки для лута, накопленные за месяцы дропнутые предметы — сервер обсчитывает каждую сущность каждый тик, и счётчик на активном сервере без чистки легко доходит до тысяч.
4. Тяжёлые или устаревшие плагины и моды. Плохо написанный плагин может съедать несоразмерно много времени тика относительно того, что он реально делает, а заброшенный мод на старом API — источник и лагов, и крашей.

Если тема глубже, чем экспресс-диагностика — есть отдельная подробная статья про оптимизацию модов и TPS на Minecraft-сервере с флагами JVM, лимитами сущностей в spigot.yml и разбором оптимизационных модов. Здесь — именно быстрые первые шаги, там — глубокая настройка.

Шаг 2: spark — находим точного виновника за пару минут

Не трогай конфиги вслепую, пока не увидел, кто конкретно ест тик. spark — профайлер производительности, который ставится и как плагин на Paper/Spigot, и как мод на Forge/Fabric, и показывает дерево вызовов с процентом времени тика на каждый источник — конкретную ферму, конкретный мод, конкретный чанк.

Базовый сценарий на активном сервере, когда лаги уже происходят:

/spark profiler start
# подожди 60-120 секунд, пока лагает
/spark profiler stop

После остановки spark выдаёт ссылку на веб-отчёт. Там видно не догадку, а цифру — условно, 35% времени тика уходит на обсчёт одной конкретной автофермы в одном чанке, а не на весь список установленных модов сразу. Это экономит часы: вместо «отключу-ка я половину плагинов на всякий случай» ты сразу знаешь, что чинить.

Если нужен просто быстрый снимок без полного профилирования — /spark tps покажет то же самое, что /tps, но и на модовых серверах без Paper.

Шаг 3: снижаем view-distance — самый быстрый рычаг

Если профайлер показал, что нагрузка размазана по всей карте, а не сконцентрирована в одном месте — почти всегда виноват радиус прогрузки. Правится одной правкой server.properties, без единого мода и без перезапуска с полной пересборкой:

view-distance=8
simulation-distance=6

Два параметра — не одно и то же. view-distance — сколько чанков видит клиент вокруг себя, влияет на визуал. simulation-distance — сколько чанков сервер реально тикает: считает физику, спавнит мобов, обсчитывает редстоун. Именно второй параметр напрямую бьёт по TPS, и его в первую очередь стоит снижать.

Площадь прогружаемой зоны растёт как квадрат радиуса — снижение с 10 до 6 это не «на 40% меньше», а почти вдвое меньше обсчитываемой площади. Большинство игроков физически не замечают разницу между 8 и 10 чанками симуляции, а сервер получает заметный запас. Подробный разбор с примерами и балансом между производительностью и ощущениями игроков — в статье про view distance и другие настройки анти-лага.

Меняй по одному значению за раз и сверяйся с /tps или /spark tps до и после — иначе не поймёшь, какая именно правка дала эффект.

Шаг 4: чистим лишних мобов и сущности

Если spark или простой визуальный осмотр карты показывает скопление сущностей — время убирать мусор. Самый быстрый способ разово почистить дропнутые предметы:

/kill @e[type=item]

Это уберёт весь дроп на земле по всему миру — полезно после долгой фарм-сессии без сборщика. Если нужно почистить конкретных мобов, а не всех подряд (например, только зомби и скелетов, оставив прирученных животных и именных мобов нетронутыми):

/kill @e[type=zombie]
/kill @e[type=skeleton,distance=..50]

Селектор distance=..N ограничивает радиус от точки выполнения команды — полезно, если чистишь мусор рядом с базой, а не всю карту разом. Будь аккуратен с фильтром type=!player без уточнений — под него могут попасть специально выращенные фермы мобов, которые игроки держат осознанно; убивать их «для оптимизации» без предупреждения — верный способ поссориться с комьюнити.

Для регулярной, а не разовой чистки на Paper/Spigot есть встроенные лимиты в spigot.yml:

world-settings:
  default:
    entity-activation-range:
      animals: 32
      monsters: 32
      misc: 16

entity-activation-range определяет, на каком расстоянии от игрока сущность вообще «просыпается» для полного обсчёта — сущности за пределами радиуса обсчитываются куда дешевле. Это не разовая чистка, а постоянный автоматический рычаг.

Шаг 5: проверяем плагины и моды

Если после снижения view-distance и чистки сущностей TPS всё ещё просаживается, а spark указывает не на конкретную ферму, а на плагин или мод — проверяй по одному. Отключи подозрительный плагин (или временно закомментируй мод в списке загрузки), перезапусти сервер и сравни /tps за тот же промежуток активности. Заодно глянь лог на старте — повторяющиеся ошибки или зацикленные варнинги от одного и того же плагина каждую секунду часто прямо указывают на виновника.

Если только начинаешь разбираться с плагинами на Paper/Spigot и не знаешь, с чего начать безопасную сборку — есть отдельная статья про плагины Bukkit и Spigot: с чего начать. Правило простое: чем меньше лишних плагинов висит без дела, тем меньше поверхность для скрытых утечек производительности.

Когда дело не в настройках, а в ресурсах сервера

Здесь стоит быть честным. Если ты уже:

• снизил view-distance и simulation-distance до разумных значений;
• почистил накопленных мобов и дропнутые предметы;
• проверил плагины и моды по одному и не нашёл явного виновника;
• а spark показывает, что нагрузка размазана по всей активности сервера, а не концентрируется в одном источнике,

— это значит, что сервер физически упирается в потолок выделенного CPU. Minecraft почти полностью работает в один поток: обсчёт мира не распараллеливается между ядрами так, как это происходит, скажем, в базах данных. Поэтому если на сервере 30-40+ игроков одновременно с активным строительством и фермами — иногда единственное честное решение это тариф с более быстрым процессором (важнее частота ядра, чем просто объём RAM). Проверить загрузку можно через htop по SSH или через график CPU/RAM в личном кабинете хостинга, если панель это умеет — у большинства современных хостингов игровых серверов такой график есть без необходимости лезть в консоль.

Частые вопросы