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

MAATRIX GAMES

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

Почему тик проседает именно с ростом фабрики

Satisfactory построен на Unreal Engine, и, как и большинство UE-игр с постоянно симулируемым миром, основная логика сервера крутится в одном главном потоке — том самом, что каждый игровой тик обходит все активные объекты и пересчитывает их состояние. Дополнительные ядра CPU в этой схеме почти не помогают: рендер физики, работа сети и часть подсистем могут быть частично распараллелены, но ядро логики симуляции — нет. Это общая черта многих игровых движков, не только Satisfactory: тот же принцип действует в Minecraft и в большинстве других серверов, где мир живёт "тиками", а не отдельными независимыми потоками на каждый объект.

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

Официальной жёсткой цифры "после скольки зданий начинаются лаги" Coffee Stain Studios не публикует, и любой конкретный порог сильно зависит от версии игры, железа сервера и того, как именно построена фабрика — так что не доверяйте чужим точным цифрам из форумов, у вас будет своя картина. Ориентируйтесь на собственные наблюдения: если просадки FPS и задержки взаимодействия с миром начались синхронно с очередным крупным расширением производства — это почти всегда прямая причинно-следственная связь, а не совпадение.

Что конкретно грузит тик: конвейеры, машины, дроны, поезда

Нагрузка на симуляцию складывается не из одного источника, а из нескольких:

• Конвейеры и предметы на них. Каждый предмет, физически едущий по ленте, — это объект, за которым нужно следить. Длинные ленты с высокой плотностью потока (особенно на Mk.5/Mk.6) держат на себе больше одновременно движущихся предметов, чем короткие малозагруженные линии.
• Сплиттеры и мерджеры, особенно Programmable Splitter с настроенными правилами — они не просто пропускают поток, а на каждом тике проверяют условия сортировки.
• Производственные здания. Каждый сборщик, конструктор, нефтеперерабатывающий завод, доменная печь — активный объект с собственной логикой цикла, таймерами и проверкой доступности сырья и места на выходе.
• Трубы с жидкостями и газами. Гидравлика считается отдельной, более тяжёлой подсистемой, чем твёрдые предметы на лентах — участки с интенсивной прокачкой нефти, воды или газа исторически были частым источником просадок у крупных фабрик.
• Дроны и грузовые поезда. Каждый активный дрон на маршруте и каждый состав на путях — дополнительный движущийся объект с собственной логистикой поверх и без того нагруженной сети конвейеров.
• Визуальные и декоративные элементы. Голограммы чертежей (blueprints), подсветка, декоративные постройки почти всегда дешевле производственной логики, но при счёте на тысячи объектов даже небольшая надбавка складывается в заметную сумму.

Важно не путать: часть перечисленного бьёт по FPS клиента (что видит игрок локально), а часть — по тику сервера (что пересчитывается для всех). "У меня лично лагает" и "весь сервер тормозит для всех" — разные диагнозы, и стоит сначала понять, какой из них ваш, прежде чем оптимизировать вслепую.

Автосейв: как он влияет на производительность и как его настроить

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

Настроить интервал автосохранения и связанные параметры можно через веб-интерфейс Server Manager (тот же, через который вы изначально настраивали сервер — подробнее в инструкции по установке Dedicated Server Satisfactory), в разделе настроек мира. Там задаётся:

• периодичность автосейва — по умолчанию не самая редкая, и на очень крупной фабрике имеет смысл увеличить интервал, чтобы не спотыкаться о фриз каждые несколько минут;
• число хранимых бэкапов сохранений — не путайте с интервалом: слишком большое число хранимых копий на крупном мире может ощутимо съедать место на диске, особенно если у вас тариф с ограниченным SSD.

Компромисс здесь честный: реже сохраняем — меньше просадок в моменте, но больше рискуем прогрессом при падении сервера или крахе процесса между сохранениями. Универсального "правильного" значения нет, это баланс между удобством игры и терпимым риском для конкретной группы игроков. Разумный подход — не убирать автосейв совсем и не растягивать интервал до часа, а подобрать значение, при котором фриз случается заметно реже, но откат в случае сбоя остаётся приемлемым (условно — не более одной активной сессии постройки).

Дополнительно не забывайте про ручные бэкапы папки с сохранениями за пределами штатного автосейва — если сервер работает на VPS, простой cron-джоб с копированием SaveGames/server/ на отдельный диск или во внешнее хранилище закроет сценарий, когда автосейв записал уже повреждённый файл поверх рабочего.

CPU и RAM: сколько закладывать на разных этапах роста

Официальный минимум для Dedicated Server Satisfactory — около 6 ГБ RAM, но это стартовая цифра под раннюю игру, а не под то, что у вас будет через полсотни часов. Ниже — ориентировочная раскладка по этапам роста фабрики, именно ориентировочная: точные цифры зависят от того, насколько плотно вы строите, сколько модов стоит и сколько игроков одновременно активно строят, а не просто присутствуют на карте.

Ключевой вывод из таблицы: на поздних этапах важнее взять тариф с более высокой частотой ядра, чем просто больше ядер или больше RAM про запас. Это тот же принцип, что разобран в общей методике сколько ядер CPU нужно под стабильный тикрейт сервера — Satisfactory попадает сюда даже более выраженно из-за плотности объектов на квадратный метр карты.

Нехватка RAM и упор в CPU выглядят по-разному: нехватка памяти обычно даёт резкий краш процесса или OOM в логе, а упор в CPU — постепенное нарастание задержки без падения сервера как такового. Если сервер не падает, но "тупит" всё сильнее по мере роста фабрики — это почти всегда про CPU, и добавление памяти проблему не решит.

Практические приёмы: снижаем нагрузку, не снося фабрику

Не всегда ответ — "стройте меньше" или "покупайте топовый тариф". Есть рабочие приёмы, снижающие нагрузку без потери прогресса:

1. Убирайте старые тестовые/заброшенные линии. На фабрике часто годами висят экспериментальные ветки, которые никто не разбирал — чистый балласт, съедающий бюджет тика без пользы.
2. Балансируйте плотность потока на лентах. Лента, гружённая под завязку 24/7, тяжелее для симуляции, чем несколько параллельных лент с равномерным потоком.
3. Пересмотрите избыточную сортировку. Programmable Splitter с длинным списком правил стоит дороже простого Splitter — используйте продвинутую сортировку только там, где она реально нужна.
4. Проверьте гидравлику отдельно. Если просадки коррелируют именно с нефтепереработкой или прокачкой газов — начните оптимизацию оттуда.
5. Ограничьте число одновременно активных дронов/поездов на пиковые часы, если логистика между базами не критична поминутно.
6. Снесите декоративный мусор без функции, если фризы совсем критичны — крайняя мера, но иногда честнее временного отключения половины продакшена.

Отдельно: если играете с модами, сначала исключите их как причину — заброшенный или плохо оптимизированный мод может давать больше нагрузки, чем вся ванильная фабрика вместе взятая. Как ставить и синхронизировать моды между клиентом и сервером — в статье про моды для Satisfactory через Satisfactory Mod Manager; там же — про типичные ошибки рассинхронизации версий, которые тоже иногда маскируются под "лаги", хотя на деле это отдельная проблема.

Как понять, где именно упор — прежде чем что-то менять

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

• Посмотрите на загрузку CPU и RAM по htop через SSH или через график в личном кабинете хостинга — это быстрее, чем гадать.
• Проверьте вкладку состояния в самом Server Manager — там видна занятая память и общая картина по процессу сервера.
• Загляните в лог FactoryServer.log на предмет повторяющихся предупреждений — если дело не в нехватке ресурсов, а в конкретном сбойном объекте или моде, лог часто прямо на это указывает.
• Сравните момент просадки с логом автосейва — если фриз идёт синхронно с сохранением, это отдельная и более простая в решении проблема (см. раздел выше), а не общий упор в CPU.

Общий подход к диагностике "лагает, но непонятно почему" для любых игровых серверов, включая разделение сетевых лагов от тиковых, разобран в статье про мониторинг TPS и лагов на игровом сервере — логика диагностики там применима и к Satisfactory, хотя конкретных команд вроде /tps в этой игре, конечно, нет.

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