Лаги на Minecraft сервере: причины и как их устранить

Игроки жалуются на лаги. Блоки ломаются с задержкой, мобы телепортируются, предметы не подбираются. Вы заходите в консоль, и вроде бы все нормально - память не забита, CPU не на 100%. Но лаги есть. Что происходит?

Если вы администратор Minecraft сервера и хотите разобраться, почему он тормозит - эта статья для вас. Без воды, без общих фраз. Конкретные причины, конкретные инструменты, конкретные конфиги.

Что такое TPS и почему это главная метрика

TPS - Ticks Per Second. Minecraft сервер работает в цикле: каждый тик он обрабатывает все, что происходит в мире. Движение мобов, рост растений, обновление редстоуна, обработка пакетов от игроков. В идеале за секунду происходит 20 тиков. Один тик = 50 миллисекунд.

• 20 TPS - все отлично, сервер справляется
• 18-19 TPS - незначительное проседание, игроки скорее всего не заметят
• 15-17 TPS - уже ощутимо, мобы двигаются рывками
• 10-14 TPS - серьезные лаги, играть некомфортно
• Ниже 10 TPS - сервер еле дышит

Проверить текущий TPS можно командой /tps (Spigot/Paper) или через spark.

Важно понимать: TPS не может быть выше 20. Если у вас 20.0 TPS, это не значит, что сервер простаивает. Это значит, что он успевает обработать тик за 50 мс или быстрее. Чтобы понять реальную нагрузку, нужно смотреть MSPT - milliseconds per tick.

/spark tps
/spark health

MSPT в 30 мс при 20 TPS означает, что у вас есть запас в 20 мс. MSPT в 48 мс - тоже 20 TPS, но вы на грани. Еще чуть-чуть нагрузки, и TPS начнет падать.

Spark: ваш главный инструмент диагностики

Забудьте про встроенный timings в Paper. Он устарел и дает гораздо меньше информации. Ставьте spark - это профайлер, который покажет, что именно жрет ресурсы.

Установка

Скачайте jar-файл с spark.lucko.me и положите в папку plugins/. Перезагрузите сервер.

Базовое использование

/spark profiler start     -- начать запись профиля

Подождите 2-5 минут, пока сервер работает в обычном режиме. Потом:

/spark profiler stop      -- остановить и получить ссылку

Spark выдаст ссылку на отчет. Откройте его в браузере. Вы увидите дерево вызовов - какие функции сколько времени занимают. Ищите самые "тяжелые" ветки.

На что обращать внимание

• Entity tick - обработка сущностей. Если тут больше 30-40% времени, у вас слишком много мобов или плохо оптимизированный плагин, который вешает логику на Entity tick
• Chunk loading/generation - генерация и загрузка чанков. Если это место номер один в профиле, генерируйте мир заранее
• Plugin обработчики - spark покажет конкретные плагины и их обработчики событий. Часто один плохо написанный плагин может убить весь сервер
• Scheduled tasks - задачи по расписанию. Синхронные задачи блокируют главный тик

Причина 1: Слишком много сущностей

Это самая частая причина лагов. Сущности (entities) - это мобы, дропнутые предметы, стрелы, рамки, вагонетки, стойки для брони. Каждая сущность обрабатывается каждый тик.

1000 коров в одном загоне? Поздравляю, у вас лаг-машина.

Диагностика

/spark tickmonitor

Или посмотрите через:

/minecraft:debug entities

Решение

В paper-global.yml (Paper 1.19+) или paper.yml (старые версии):

# paper-world-defaults.yml
entities:
  spawning:
    monster-spawn-range: 6          # дефолт 8
    creative-arrow-despawn-rate: 60
    non-player-arrow-despawn-rate: 60

В spigot.yml:

entity-activation-range:
  animals: 16          # дефолт 32
  monsters: 24         # дефолт 32
  raiders: 48
  misc: 8              # дефолт 16
  water: 8             # дефолт 16
  villagers: 16        # дефолт 32
  flying-monsters: 32  # дефолт 32
  tick-inactive-villagers: false
  wake-up-inactive:
    animals-max-per-tick: 4
    animals-every: 1200
    animals-for: 100
    monsters-max-per-tick: 8
    monsters-every: 400
    monsters-for: 100

Entity activation range определяет, на каком расстоянии от игрока сущности получают полный тик. За пределами этого радиуса они тикаются реже - экономия огромная.

Дроп предметов

Лежащие на земле предметы - тоже сущности. Настройте despawn:

# spigot.yml
item-despawn-rate: 3000   # дефолт 6000 (5 минут), ставим 2.5 минуты

Поставьте плагин ClearLagg или напишите простой скрипт, который чистит дроп каждые 5 минут. Предупреждайте игроков за 30 секунд.

Причина 2: Загрузка и генерация чанков

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

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

Используйте Chunky для прегенерации:

/chunky radius 5000
/chunky start

Оставьте на ночь. Прегенерация карты 5000 блоков от спавна займет несколько часов, но после этого новым игрокам не придется ждать генерации.

view-distance и simulation-distance

Это самые мощные рычаги оптимизации. В server.properties:

view-distance=7
simulation-distance=4

view-distance - сколько чанков вокруг игрока отправляются клиенту. Дефолт 10, но для большинства серверов 7-8 более чем достаточно.

simulation-distance - сколько чанков вокруг игрока реально тикаются (мобы двигаются, редстоун работает, растения растут). Это критичная настройка. Снижение с 10 до 4-5 радикально уменьшает нагрузку.

Важно: simulation-distance должен быть меньше или равен view-distance. Игроки будут видеть чанки, но в дальних чанках ничего не будет двигаться. Для большинства это приемлемо.

Причина 3: Редстоун

Автоматические фермы на редстоуне - боль каждого сервера. Один бесконечный тактовый генератор может просадить TPS всему серверу.

Лимиты в Paper

# paper-global.yml
chunk-system:
  gen-parallelism: default

# paper-world-defaults.yml
redstone-implementation: ALTERNATE_CURRENT

ALTERNATE_CURRENT - альтернативная реализация обновлений редстоуна, значительно быстрее ванильной. Некоторые очень сложные схемы могут сломаться, но для 99% использования это отлично.

Лимит на поршни и хопперы

# paper-world-defaults.yml
hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-above: false

Хопперы - один из самых дорогих блоков по производительности. cooldown-when-full: true значительно снижает нагрузку от полных хопперов.

Причина 4: Плагины

Плохо написанные плагины - вторая по частоте причина лагов после сущностей. Вот типичные проблемы:

• Синхронные запросы к базе данных. Плагин делает SQL запрос в главном потоке, и пока он ждет ответа, весь сервер стоит. Это убийца TPS. Ставьте только плагины от проверенных разработчиков
• Тяжелые обработчики событий. Плагин на PlayerMoveEvent, который каждый тик проверяет что-то сложное для каждого игрока
• Утечки памяти. Плагин создает объекты, но не удаляет их. Со временем GC начинает паниковать

Как найти проблемный плагин

Spark покажет это напрямую в профиле. Но можно и проще - отключайте плагины по одному (методом деления пополам) и смотрите на TPS.

Если вы подозреваете конкретный плагин:

/spark profiler start --only-ticks-over 50

Это запишет профиль только тех тиков, которые заняли больше 50 мс (то есть вызвали просадку TPS). В отчете будет видно, что именно тормозит.

Причина 5: Сборщик мусора (GC)

Java использует сборщик мусора для управления памятью. Когда GC запускается, он может на мгновение приостановить весь сервер. Если у вас выделено 16 ГБ RAM, а GC настроен плохо, паузы могут быть 200-500 мс. Это 4-10 потерянных тиков за раз.

Флаги Aikar

Aikar (разработчик Paper) составил набор JVM флагов, оптимизированных для Minecraft. Используйте их:

Для серверов с 12 ГБ RAM и меньше:

java -Xms10G -Xmx10G -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:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar --nogui

Ключевые моменты:

• -Xms и -Xmx одинаковые - это важно. Java не будет тратить время на изменение размера кучи
• -XX:+UseG1GC - сборщик G1, оптимальный для Minecraft
• -XX:MaxGCPauseMillis=200 - целевая пауза GC не больше 200 мс
• -XX:G1NewSizePercent=30 и G1MaxNewSizePercent=40 - Minecraft создает много короткоживущих объектов, поэтому Young Generation увеличен

Сколько RAM выделять

Частая ошибка - выделять слишком много RAM. 32 ГБ для сервера на 50 игроков - это перебор. Чем больше куча, тем дольше GC пауза.

Ориентиры:

• Ваниль/Paper до 20 игроков: 4-6 ГБ
• Paper 20-50 игроков: 6-10 ГБ
• Paper 50-100 игроков с плагинами: 10-14 ГБ
• Forge с модами: зависит от модпака, но начинайте с 8 ГБ

Paper и Purpur: что крутить

Если вы еще на Spigot - переходите на Paper. Если на Paper - посмотрите на Purpur. Каждый из них добавляет оптимизации, которых нет в ванили.

paper-global.yml

chunk-system:
  gen-parallelism: default
  io-threads: 4
  worker-threads: 4

async-chunks:
  threads: 4

paper-world-defaults.yml

entities:
  spawning:
    per-player-mob-spawns: true
    alt-item-despawn-rate:
      enabled: true
      items:
        cobblestone: 300
        netherrack: 300
        sand: 300
        gravel: 300
        dirt: 300
        short_grass: 300
        kelp: 300
        bamboo: 300

environment:
  treasure-maps:
    enabled: true
    find-already-discovered:
      loot-tables: true
      villager-trade: true
  optimize-explosions: true

tick-rates:
  mob-spawner: 2
  sensor:
    villager:
      secondarypoisensor: 80
  behavior:
    villager:
      validatenearbypoi: -1

per-player-mob-spawns: true - вместо глобального лимита мобов, лимит считается на игрока. Один игрок с гигантской фермой не заберет весь лимит мобов сервера.

alt-item-despawn-rate - мусорные блоки (камень, земля) исчезают быстрее. Игроки не заметят, а сущностей на сервере будет меньше.

optimize-explosions: true - оптимизированный алгоритм взрывов. Обязательно включайте.

server.properties дополнительно

network-compression-threshold=256
max-tick-time=-1

network-compression-threshold=256 - сжимать пакеты больше 256 байт. Дефолт тоже 256, но убедитесь, что это значение стоит.

max-tick-time=-1 - отключает watchdog, который убивает сервер при долгом тике. На продакшене это спорная настройка, но она предотвратит аварийные перезагрузки при кратковременных лагах.

Когда лаги - это не лаги, а атака

Бывает ситуация: вы все оптимизировали, TPS стабильные 20, но игроки все равно жалуются на лаги. Или наоборот - TPS внезапно падает до 5, хотя ничего не изменилось.

Несколько признаков, что это не обычные лаги:

• Резкое падение TPS без видимой причины - никто не зашел, никакой новый плагин не ставился, а TPS упал
• Сетевые таймауты - игроки не могут подключиться или вылетают с ошибкой "Timed out"
• Высокая нагрузка на сеть при нормальной нагрузке на CPU
• Массовые подключения - в логах десятки или сотни попыток подключения в секунду

Это может быть DDoS или бот-атака. Сетевая атака забивает канал или перегружает сервер фейковыми подключениями, и это выглядит как лаги, хотя сам Minecraft работает нормально.

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

Чеклист оптимизации

Подведем итоги. Вот порядок действий при лагах:

1. Проверьте TPS и MSPT через /spark tps - поймите масштаб проблемы
2. Запустите spark profiler - найдите, что именно тормозит
3. Проверьте количество сущностей - самая частая причина
4. Настройте entity activation range в spigot.yml
5. Уменьшите simulation-distance до 4-5
6. Включите Paper оптимизации - optimize-explosions, per-player-mob-spawns, alt-item-despawn-rate
7. Используйте ALTERNATE_CURRENT для редстоуна
8. Примените флаги Aikar для JVM
9. Прегенерируйте мир с Chunky
10. Проверьте плагины через spark на предмет тяжелых обработчиков

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