Это случилось в пятницу вечером.
Сервер работал три месяца. Онлайн потихоньку рос — 40, 80, 120 человек. Мы запустили новый ивент, разослали анонс, и в пятницу народ повалил. 180 игроков одновременно. Я сидел и радовался, глядя на TabList.
А потом TPS упал до девяти.
Не резко — постепенно, как будто кто-то медленно душит сервер подушкой. Сначала начали появляться небольшие фризы. Потом лаги стали заметными. Потом игроки начали писать в чат всё более недовольные сообщения. К полуночи онлайн упал до 40 — люди просто ушли.
Я провёл за диагностикой всю ночь. И знаете что выяснилось? Виноваты оказались плагины, которые я сам же и поставил — честно, из лучших побуждений.
Вот они, мои «добросовестные убийцы».
Место первое: ClearLagg — лекарство, которое хуже болезни
ClearLagg стоит почти на каждом втором выживальческом сервере. Логика простая: много мобов и дропа — лаги. ClearLagg их чистит — лаги уходят. Всё честно.
Проблема в том, как именно он это делает.
Когда ClearLagg запускает очистку, он в один момент удаляет тысячи энтити. Серверу нужно это обработать — обновить состояние мира, разослать пакеты всем игрокам, пересчитать нагрузку. В момент очистки TPS проваливается — иногда до 8–10 тиков. Потом восстанавливается. Потом снова падает. Потом снова восстанавливается.
Игроки это чувствуют как ритмичные фризы каждые N минут — именно тогда, когда ClearLagg работает по расписанию.
У нас это расписание было каждые 3 минуты. С 180 игроками каждые три минуты сервер умирал на 10 секунд.
Что делать вместо этого: настройте ограничения на спавн мобов через spigot.yml и bukkit.yml — параметры mob-spawn-range, max-entity-cramming, entity-activation-range. Это работает превентивно, без периодических судорог. А ещё лучше — поставьте Spark и посмотрите, какие конкретно энтити жрут ресурсы, прежде чем ставить что-то «от лагов».
Место второе: CoreProtect — тихий пожиратель I/O
CoreProtect — это логгер действий. Каждый поставленный блок, каждый сломанный, каждый контейнер, каждая команда — всё пишется в базу данных. Незаменимая вещь для расследования гриферства.
Но у него есть неприятная особенность, которую никто не читает в документации: по умолчанию CoreProtect пишет логи синхронно, в основном потоке сервера. Это значит, что каждый раз, когда 30 игроков одновременно копают, строят или взаимодействуют с сундуками — сервер ждёт, пока все эти записи улягутся в базу.
На маленьком сервере это незаметно. На большом — это несколько лишних миллисекунд на каждый тик. А когда тик должен укладываться в 50 мс, «несколько лишних миллисекунд» означают, что тик уже не успевает, и TPS начинает проседать.
В нашем случае CoreProtect вёл лог на медленном HDD (не NVMe), и при пиковом онлайне операции записи выстраивались в очередь.
Что делать: перенесите базу CoreProtect на быстрый диск (NVMe). Включите асинхронный режим записи в конфиге — параметр use-async-logging. И настройте регулярную очистку старых записей — иначе база распухнет до нескольких гигабайт и запросы станут медленнее.
Место третье: Dynmap — карта, которая рендерит мир прямо во время игры
Dynmap — это красиво. Живая карта сервера в браузере, игроки видят друг друга в реальном времени, можно даже чат вывести. Все хотят Dynmap.
Проблема в том, что генерация тайлов для карты — это очень тяжёлая операция. Dynmap должен «сфотографировать» каждый чанк с нужного угла, просчитать освещение, сохранить картинку. По умолчанию он делает это постоянно — по мере того, как игроки исследуют мир и изменяют блоки.
Когда у вас 180 активных игроков, которые строят и копают в разных частях карты — Dynmap пытается рендерить сотни изменившихся тайлов одновременно. Это убивает и процессор, и диск.
Что делать: в конфиге Dynmap установите tiles-per-tick в минимальное значение (1–2), а рендеринг ограничьте ночным временем через renderinterval. Ещё лучше — запускайте полный ре-рендер только вручную командой /dynmap fullrender в период минимального онлайна.
Место четвёртое: античиты с агрессивной проверкой пакетов
Это самый обидный пункт. Античит ставишь, чтобы сервер был честным. А получаешь дополнительную нагрузку на и без того загруженный сервер.
Некоторые античиты — особенно старые версии NCP (NoCheatPlus) и ряд платных решений — работают так: они перехватывают каждый входящий пакет от каждого игрока и прогоняют его через цепочку проверок. На 20 игроках это незаметно. На 100+ игроках, которые постоянно двигаются, прыгают, атакуют — это сотни тысяч проверок в секунду.
Мы запускали Spark во время пикового онлайна и видели, как античит занимал 15–20% времени главного потока. Это не проблема железа — это проблема алгоритма.
Что делать: выбирайте античиты, которые явно написаны как асинхронные — Grim Anticheat, например, построен с учётом производительности. Отключайте проверки, которые вам не нужны: если у вас сервер без PvP, зачем держать включёнными все combat-чеки? Читайте конфиги, не оставляйте всё на дефолтах.
Место пятое: плагины с MySQL и синхронными запросами
Это уже тема для более технических читателей, но игнорировать её нельзя.
Многие плагины умеют работать с MySQL — хранить данные игроков в базе данных. Это правильно: это надёжнее, чем файлы, и позволяет иметь несколько серверов на одной базе.
Но некоторые плагины делают запросы к базе данных прямо в главном потоке сервера — синхронно. Это значит: игрок заходит на сервер → плагин спрашивает базу «а что у него в инвентаре?» → сервер стоит и ждёт ответа → только после этого игрок появляется в мире.
Если база находится на том же сервере и отвечает быстро — это 5–10 мс, незаметно. Если база на другом хосте, сеть нагружена, запрос обрабатывается долго — сервер ждёт по 100–500 мс на каждый вход. При 20 одновременных входах это катастрофа.
Что делать: в первую очередь — проверьте, поддерживает ли плагин асинхронную работу с БД. Это должно быть написано в документации. Если нет — ищите аналоги. Используйте connection pool (HikariCP — стандарт де-факто). И всегда держите базу данных на том же физическом сервере или максимально близко к нему.
Место шестое: WorldGuard с тысячами регионов
WorldGuard — абсолютно необходимый плагин для любого выживальческого сервера. Привата нет — сервер умирает от гриферства. Это факт.
Но вот что происходит, когда у вас 10 000 регионов.
Каждый раз, когда игрок двигается, WorldGuard проверяет, не вошёл ли он в новый регион или не вышел ли из старого. Для этого ему нужно проверить список всех регионов в текущем чанке — и сопоставить их с позицией игрока. Чем больше регионов, тем медленнее эта проверка.
На 50 игроках, каждый из которых делает несколько шагов в секунду — это десятки тысяч проверок в минуту. При плотной застройке, где регионы перекрываются — нагрузка растёт экспоненциально.
Что делать: установите плагин FAWE (Fast Async WorldEdit) — он значительно ускоряет работу со структурами регионов. Периодически удаляйте брошенные маленькие регионы. И подумайте о переходе на Residence или GriefPrevention — они работают с регионами эффективнее при большом количестве.
Как вообще понять, что убивает ваш сервер
Прежде чем что-то трогать — поставьте Spark. Это профайлер, который показывает, какие именно части кода сколько времени занимают. Он бесплатный, не нагружает сервер и даёт точный ответ вместо гадания.
Команда /spark profiler start — подождите 5–10 минут в пиковое время — /spark profiler stop. Spark сгенерирует ссылку с визуальным отчётом, где будет видно: вот этот плагин занимает 30% времени тика, а вот этот — 2%.
Диагностика сначала, оптимизация потом. Именно в таком порядке.
Что в итоге
Все шесть плагинов из этого списка — полезные инструменты. Я не призываю их удалять. Я призываю их настраивать, а не оставлять на дефолтных значениях, которые написаны для среднестатистического маленького сервера, а не для вашего конкретного проекта.
Та ночь после провальной пятницы стоила мне нервов и части аудитории. Но зато я научился читать конфиги вместо того, чтобы читать описания плагинов.
Удачи вашим серверам — и пусть TPS держится на 20.
Если статья оказалась полезной — сохраните её, она пригодится когда в следующий раз сервер начнёт лагать в самый неподходящий момент.