Core Keeper: лагает при росте мира/производства

MAATRIX GAMES

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

Почему лаги приходят именно с ростом мира

Core Keeper — не статичная карта фиксированного размера с самого начала: мир генерируется и «раскрывается» по мере того, как игроки копают и исследуют новые участки вокруг Ядра. Каждый новый открытый биом — это не просто визуальный кусок карты, а дополнительный набор объектов, которые серверу нужно держать в памяти и обсчитывать: спавнеры монстров, ресурсные узлы, декорации, сундуки, а позже — ещё и постройки самих игроков.

Отдельная история — автоматизация. С добавлением конвейерных лент, генераторов и системы проводов (Automation update) у игроков появилась возможность строить полноценные фермы и производственные линии, которые работают постоянно, а не только в момент присутствия игрока рядом. Чем длиннее лента и чем больше связанных между собой механизмов в цепочке, тем больше единиц логики серверу приходится пересчитывать на каждом шаге симуляции — даже если рядом никого нет.

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

Что конкретно грузит тик: разбор по типам нагрузки

Прежде чем что-то менять в настройках или пересаживаться на тариф побольше, полезно понимать, куда именно уходит бюджет тика по мере роста мира и базы:

• Спавнеры монстров и активные мобы. Каждый открытый биом добавляет точки спавна, а мобы, которые преследуют игрока, патрулируют территорию или дерутся между собой (например, на фермах для гринда лута), требуют постоянного пересчёта поведения.
• Конвейерные ленты и генераторы. Каждый сегмент ленты, каждый переключатель на проводах и каждый генератор — отдельная единица логики, обновляемая каждый тик. Длинная разветвлённая линия через полкарты обходится серверу заметно дороже, чем компактная ферма того же назначения.
• Фермы для гринда лута. Популярная механика Core Keeper — закрытые комнаты со спавнером и системой убийства мобов на поток. Такая ферма, работающая без остановки, — постоянный источник нагрузки, а не разовый всплеск.
• Разбросанные предметы и лут на земле. После активных боёв или долгих фарм-сессий на полу может скапливаться заметное количество дропа, который сервер тоже держит в памяти как отдельные объекты, пока его не подберут или он не исчезнет по таймеру.
• Плотность построек. Обширные базы с большим количеством размещённых объектов (сундуки, мебель, декор, механизмы) увеличивают число сущностей, которые нужно синхронизировать между игроками — особенно заметно при пятерых-шестерых одновременно подключённых.

Публичной документации о распределении вычислений дедикейтед-сервера Core Keeper между потоками процессора немного, поэтому гадать не будем — но общий принцип, знакомый по другим песочницам с автоматизацией, работает и здесь: чем меньше отдельных активных объектов на карте при том же результате, тем дешевле тик.

Как увидеть проблему, а не гадать

У Core Keeper Server, в отличие от некоторых других игр, нет встроенного бенчмарка или консольной команды для точного измерения стоимости тика — поэтому диагностика опирается на системные метрики хоста и субъективные симптомы в игре.

Первым делом смотрим на загрузку CPU и памяти самого процесса сервера:

top -p $(pgrep -d',' CoreKeeperServer)

Или через htop, если он установлен — там сразу видно, упирается ли конкретный процесс в одно ядро (частый признак того, что дело в основном цикле симуляции, а не в нехватке параллельных ресурсов) или нагрузка размазана по нескольким.

Проверить, не подъедает ли память сама по себе рост исследованной карты, помогает простое наблюдение в динамике — например, снимок раз в несколько часов:

ps -o pid,%cpu,%mem,rss,cmd -p $(pgrep CoreKeeperServer)

Стабильный рост %mem и rss без плато по мере исследования новых биомов — ожидаемое поведение, а вот резкий скачок в короткий промежуток времени обычно совпадает с массовым открытием новой области карты или крупной стройкой.

В игре ориентируйтесь на субъективные, но надёжные признаки: рывки при перемещении персонажа, задержка между действием (например, вставили предмет на ленту) и видимым результатом, «зависания» при бое с большой группой мобов. Если симптомы совпадают по времени с моментом, когда несколько игроков одновременно активны в разных концах карты — вы, скорее всего, упёрлись в бюджет тика, а не в сетевые проблемы. Общие принципы того, как отличать просадку серверной симуляции от проблем сети или клиента, разобраны в статье про мониторинг TPS и лагов на игровом сервере.

Автосейв и дисковая нагрузка при росте мира

Файл сохранения мира Core Keeper растёт вместе с исследованной картой и постройками — это нормально, но у роста есть обратная сторона: чем крупнее сейв, тем дольше и тяжелее для диска сама операция записи. Как уже разбиралось в статье про проблему с сохранением в Core Keeper, у выделенного сервера нет широко задокументированного интерфейса для ручной настройки интервала внутреннего автосохранения или принудительного форс-сейва по команде — сервер сам решает, когда писать данные на диск.

На небольшом мире это почти незаметно. Но когда сохранение весит уже сотни мегабайт, момент записи может ощутимо просесть по I/O параллельно с симуляцией — особенно на тарифах с медленным диском или при параллельной нагрузке (например, идёт ещё и внешний бэкап по крону).

Что реально можно сделать, раз внутренний интервал автосейва не настраивается напрямую:

• Разносите внешние бэкапы по времени с пиковой активностью игроков. Если у вас настроена cron-задача с архивированием папки сохранений (см. статью про проблему с сохранением), старайтесь не запускать её в часы, когда на сервере одновременно вся компания — совместите два источника дисковой нагрузки, и просадка будет заметнее.
• Снижайте приоритет внешнего бэкапа для диска и CPU, чтобы он не соревновался с процессом сервера за ресурсы:

ionice -c2 -n7 nice -n19 tar -czf ~/backups/coreworld-$(date +%Y%m%d-%H%M).tar.gz -C /home/coreserver/coreserver/saves .

• Держите папку сохранений на быстром хранилище. Если хостинг предлагает выбор между обычным и NVMe-диском под данные — для растущего мира Core Keeper разница в скорости записи ощущается сильнее, чем кажется на старте, когда сейв ещё маленький.
• Следите за свободным местом заранее, а не по факту ошибки — растущий сейв плюс несколько хранимых бэкапов способны незаметно съесть весь запас диска на тарифе, рассчитанном под старт, а не под позднюю игру.

Сколько CPU и RAM закладывать по мере роста мира

Требования Core Keeper к железу растут неравномерно: память — довольно предсказуемо вместе с объёмом исследованной карты и количеством построек, а нагрузка на процессор скачками — в зависимости от того, сколько активных мобов, ферм и цепочек автоматизации работает одновременно.

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

Практические приёмы снижения нагрузки

Когда причина примерно понятна — по мониторингу CPU/RAM и совпадению просадок с конкретными моментами игры — вот с чего обычно начинают разбор конкретного мира:

• Компактные фермы вместо огромных. Одна аккуратно спроектированная ферма для гринда часто эффективнее по луту на единицу нагрузки, чем несколько раскиданных по карте — меньше активных мобов и сегментов ленты суммарно на тот же результат.
• Регулярно подбирайте или зачищайте разбросанный лут. После долгих боевых сессий или чисток дворца стоит пройтись и подобрать (или дать исчезнуть по таймеру) накопившийся на полу дроп — не оставляйте его копиться неделями.
• Пересматривайте архитектуру автоматизации по мере масштабирования. Там, где на старте хватало одной длинной ленты, на масштабе может быть выгоднее несколько коротких параллельных линий с меньшим количеством лишних сегментов — общий принцип тот же, что и в других играх с конвейерами: меньше отдельных обновляемых объектов на тот же объём производства.
• Ограничивайте SERVER_MAX_PLAYERS, если реальный состав меньше лимита. Нет смысла держать сервер настроенным на 8 слотов, если стабильно играет трое-четверо — лишние потенциальные подключения не помогают, а сам параметр стоит держать реалистичным.
• Обновляйте сервер вовремя. Разработчики регулярно выпускают патчи производительности вместе с контентными обновлениями — устаревшая версия сервера иногда лагает сильнее не из-за размера мира, а просто потому, что не содержит более поздних оптимизаций движка.
• Не держите процесс запущенным месяцами без перезапуска. Плановый штатный рестарт (не жёсткий kill, а корректная остановка — см. статью про сохранения) раз в одну-две недели помогает сбросить накопленные за время работы артефакты вроде утечек памяти, если они есть в конкретной версии.

Общие принципы подготовки сервера к росту нагрузки — не только для Core Keeper, но применимые и здесь — разобраны в статье про оптимизацию сервера под высокую нагрузку.

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