Оптимизация TPS сервера Minecraft : разбираемся с падениями

Par Benjamin D. · PDG

13 сентября 2026 г. · Mis à jour le 13 сентября 2026 г. · Lecture 9 min

Содержание

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

Что такое TPS сервера Minecraft и почему он падает

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

Ключевой момент, который многие упускают: TPS и MSPT — это одно и то же, но с разных сторон. MSPT (milliseconds per tick) показывает, сколько миллисекунд реально занял тик. Пока MSPT ниже 50, TPS держится на 20. Как только MSPT переходит за 50, начинается деградация.

MSPT	TPS	Что чувствует игрок
10–25 мс	20.0	Всё гладко, запас по нагрузке большой
25–45 мс	20.0	Нормально, но пиковые события уже опасны
50–70 мс	14–20	Мобы дёргаются, редстоун «залипает»
100+ мс	~10 и ниже	Блоки отскакивают, урон проходит с задержкой

Отличайте лаги тиков от сетевой задержки

Игроки часто пишут «лаги», имея в виду совершенно разные вещи. Если ваш пинг 180 мс, но TPS 20.0 — проблема в сети и маршруте, а не в вычислениях. Если пинг 25 мс, а TPS 8 — нагружено ядро. Проверить просто: наведите курсор на индикатор задержки в списке игроков (Tab) и параллельно выполните консольную команду:

/tps
/mspt

На Paper и его форках эти команды доступны сразу. В Pterodactyl-консоли те же данные видны без входа в игру — достаточно отправить команду прямо в живую консоль панели. Если вы разворачиваете проект на инфраструктуре Fly-Serv, посмотреть графики CPU и RAM можно на той же вкладке, что удобно при поиске корреляции между просадками и пиками нагрузки.

Технические детали по конфигурации ванильных и Paper-миров мы разбираем на странице хостинг Minecraft, а также в других материалах Блог Fly-Serv.

Одноядерная частота процессора: почему Minecraft любит гигагерцы

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

Практический вывод: процессор с 32 ядрами на 2.2 ГГц даст худший TPS сервера Minecraft, чем 8 ядер на 4.5 ГГц. Поэтому для игровых машин применяют Ryzen с высокой тактовой частотой и хорошим IPC — это напрямую сокращает MSPT.

Мутуализация и «шумные соседи»

Второй фактор — распределение ядер. Если ядро физического процессора делится между множеством контейнеров, ваш тик-луп конкурирует за процессорное время с чужими нагрузками. Внешне это выглядит как случайные всплески MSPT без видимой причины: игроков мало, мобов немного, а TPS проваливается на 3–5 секунд.

Стабильные ядра — MSPT ровный, всплески совпадают с игровыми событиями (взрыв крипера, портал в Незер, работа фермы).
Перегруженная машина — всплески хаотичны, `steal time` в системе растёт, TPS «плавает» без нагрузки.

Если у вас есть SSH-доступ к машине, посмотрите на колонку st:

top -b -n 1 | head -n 5
# %Cpu(s):  12.3 us,  1.2 sy,  0.0 ni, 85.1 id,  0.4 wa,  0.0 hi,  0.0 si,  1.0 st

Значение st (steal) выше 2–3% на постоянной основе означает, что гипервизор отбирает у вас такты. Это невозможно исправить настройкой Java — вопрос решается только на уровне инфраструктуры.

Диск тоже влияет на тик

Автосохранение чанков выполняется в основном потоке (частично вынесено в Paper, но не полностью). На медленном HDD каждое сохранение региона превращается в паузу на десятки миллисекунд. NVMe-накопители убирают этот класс проблем: операции записи региона укладываются в единицы миллисекунд, и периодические провалы TPS раз в пять минут исчезают. Если вы видите ровный график с регулярными зубцами — почти всегда это autosave плюс дисковая подсистема.

RAM, сборщик мусора и флаги JVM

Больше оперативной памяти ≠ выше TPS. Это самое распространённое заблуждение. RAM определяет, сколько чанков и сущностей вы можете держать в памяти без вылетов, а на скорость обработки тика влияет косвенно — через поведение сборщика мусора (GC).

Как GC портит TPS

Когда Java собирает мусор, приложение может останавливаться (stop-the-world pause). Если пауза длится 300 мс, вы теряете 6 тиков подряд. Именно так выглядят «микрофризы» на сервере с большим heap и стандартными настройками: TPS усреднённо 19.8, но игроки жалуются на рывки.

Правило распределения памяти:

Профиль	Игроков	Разумный heap
Ванилла / Paper, выживание	до 10	3–4 ГБ
Paper + 30–50 плагинов	20–40	6–8 ГБ
Модпак Forge/Fabric (150+ модов)	10–20	8–12 ГБ
Крупный модпак с генерацией измерений	20+	12–16 ГБ

Выдавать 24 ГБ маленькому Paper-проекту контрпродуктивно: чем больше heap, тем дольше полный цикл сборки. Оставляйте также запас вне heap — Java потребляет память под metaspace, стеки потоков и буферы сети, обычно 1–1.5 ГБ сверх -Xmx.

Флаги запуска

Набор флагов Aikar для G1GC остаётся рабочим стандартом для heap от 4 до 12 ГБ. Ключевая идея — заставить GC работать чаще, но короткими паузами:

java -Xms8G -Xmx8G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true \
  -jar paper.jar nogui

Обратите внимание: -Xms равен -Xmx. Это не расточительство, а способ избежать постоянного расширения heap. Подробности по флагам и их обоснование опубликованы в Source.

В панели Pterodactyl флаги задаются через переменную JAVA_OPTS или в поле startup-команды. После правки обязательно полный рестарт — на лету JVM их не подхватит.

Версия Java

Для Minecraft 1.20.5+ требуется Java 21. Даже если у вас старая версия игры, переход на современную JVM обычно снижает MSPT на несколько миллисекунд за счёт улучшений JIT. Проверить активную версию:

java -version

Чанки, сущности и распределение нагрузки

Самая недооценённая причина, по которой проседает TPS сервера Minecraft, — количество одновременно тикающих чанков. Каждый игрок «держит» вокруг себя область, где идёт симуляция. Десять игроков в разных биомах = десять таких областей плюс загруженные чанки от порталов, вагонеток и ферм.

view-distance и simulation-distance

Это две разные вещи, и разделение появилось не зря:

view-distance — что игрок видит. Влияет на трафик и память, на тик влияет умеренно.
simulation-distance — где реально идёт симуляция: мобы, рост, редстоун. Именно это грузит CPU.

Рабочая конфигурация для выживания в server.properties:

view-distance=8
simulation-distance=5
max-tick-time=60000
network-compression-threshold=256
sync-chunk-writes=false
entity-broadcast-range-percentage=100

Снижение simulation-distance с 10 до 5 уменьшает объём симулируемых чанков более чем вчетверо. Игроки этого почти не замечают: визуально мир остаётся прежним благодаря view-distance.

Сущности: мобы, предметы, вагонетки

Тысяча дропнутых предметов на полу фермы способна съесть 15 мс за тик. Настройки Spigot помогают:

# spigot.yml
world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
    merge-radius:
      item: 3.5
      exp: 4.0
    mob-spawn-range: 4
    max-entity-collisions: 2

Параметр merge-radius объединяет лежащие предметы в стопки — прямое сокращение числа сущностей. entity-activation-range «замораживает» мобов вне радиуса: они существуют, но не выполняют ИИ каждый тик.

В paper-world-defaults.yml критичны лимиты воронок и альтернативная реализация редстоуна:

chunks:
  max-auto-save-chunks-per-tick: 8
hopper:
  disable-move-event: true
  ignore-occluded-chunks: true
misc:
  redstone-implementation: ALTERNATE_CURRENT
entities:
  spawning:
    per-player-mob-spawns: true
    despawn-ranges:
      monster:
        hard: 96
        soft: 32

ALTERNATE_CURRENT заметно дешевле ванильного алгоритма на крупных редстоун-схемах. per-player-mob-spawns распределяет лимит мобов по игрокам, вместо того чтобы один человек в пещере выжирал глобальный кап.

Предгенерация мира

Генерация новых чанков — самая дорогая операция. Игрок на элитре улетает в неизведанное, и MSPT уходит в 200+. Решение — предгенерировать карту заранее, пока никого нет онлайн, плагином Chunky:

/chunky world world
/chunky radius 5000
/chunky start

После предгенерации ставьте разумный worldborder — это одновременно ограничивает размер сохранений и защищает от бесконечного роста объёма резервных копий.

Диагностика: найти виновника, а не гадать

Без профилирования оптимизация превращается в шаманство. Инструмент номер один — spark. Он работает и на Paper, и на Fabric/Forge.

/spark profiler start --timeout 300
# играем, воспроизводим лаги
/spark profiler stop

Плагин выдаст ссылку на интерактивное дерево вызовов, где видно, какой плагин, мод или тип сущности потребляет такты. Дополнительно полезны:

/spark tps
/spark healthreport
/spark heapsummary

Типичные находки

Плагин с синхронным обращением к базе — каждый запрос блокирует тик-луп. Лечится включением асинхронного режима или переходом на локальную БД.
Автоферма на воронках — сотни InventoryMoveItemEvent в секунду. Лечится disable-move-event: true и заменой воронок на водные сборщики.
Чанклоадеры от модов — принудительно загруженные чанки тикают постоянно. Проверяйте /forceload query.
Мод с активной генерацией структур — лечится предгенерацией и ограничением границ мира.
Утечка памяти — heap растёт, GC работает всё чаще, TPS медленно деградирует за сутки. Смотрите heapsummary.

Гигиена администрирования

Оптимизация бессмысленна без базовой дисциплины. Минимальный набор:

Автоматические резервные копии перед каждым обновлением ядра или модпака, с проверкой восстановления хотя бы раз в месяц.
Надёжный пароль RCON и ограничение доступа к порту запросов.
Whitelist на приватных проектах, чтобы исключить нагрузку от случайных подключений и ботов.
Отдельные суб-пользователи в панели для модераторов вместо общего доступа к корневой учётной записи.
Регулярные обновления ядра: Paper и Fabric постоянно правят узкие места производительности.

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

Быстрый чек-лист при просадке

Симптом	Первая проверка	Действие
Зубцы каждые 5 минут	autosave + диск	`max-auto-save-chunks-per-tick`, NVMe
Микрофризы 200–400 мс	GC-паузы	Флаги Aikar, уменьшить heap
Просадка при полёте игрока	Генерация чанков	Chunky, worldborder
Стабильно низкий TPS	spark profiler	Убрать/заменить виновный плагин
Хаотичные всплески без нагрузки	`steal time`	Перенос на машину со стабильными ядрами
TPS 20, но пинг 200	Маршрут сети	Выбор локации ближе к игрокам

Конклюзия

Стабильные 20 тиков достигаются не одной волшебной настройкой, а связкой факторов: высокая однопоточная частота процессора, адекватный объём памяти с правильными флагами JVM, контроль симулируемых чанков и сущностей, предгенерация мира и регулярное профилирование через spark. Измеряйте MSPT до и после каждого изменения — так вы точно знаете, что именно дало результат, и не ломаете рабочую конфигурацию вслепую.

FAQ

Почему TPS падает только когда онлайн больше 15 человек?

Каждый игрок держит вокруг себя область симуляции. Пятнадцать человек в разных концах карты — это пятнадцать активных зон с мобами, редстоуном и ростом растений. Снизьте simulation-distance до 4–5, включите per-player-mob-spawns: true в Paper и ограничьте entity-activation-range. Если не помогло, профилируйте через /spark profiler start при полном онлайне.

Добавление оперативной памяти поднимет TPS?

Только если сервер действительно упирается в память и GC работает непрерывно. Проверьте /spark heapsummary: если heap заполнен на 95% постоянно — да, прибавка поможет. Если используется 40% — добавление RAM ничего не изменит, узкое место в однопоточной производительности процессора или в конкретном плагине.

Как понять, виноват плагин или мод, не удаляя их по одному?

Установите spark и запустите профилирование на 5 минут в момент лагов: /spark profiler start --timeout 300. Отчёт покажет дерево вызовов с процентом времени по каждому пакету классов — имя виновного плагина будет прямо в названии метода. Это быстрее и безопаснее, чем метод исключения на живом мире.