Factorio на VPS: автоматическое сохранение и большие фабрики

Сначала фабрика была скромной: пара десятков кирпичных печей, лента с медью, первая красная наука. Потом появились поезда, логистические роботы, нефтяной кластер, зелёные и синие схемы, и однажды в сохранении оказалось столько движущихся предметов, что сервер стал работать не «для игроков», а для самой фабрики. Игроков по-прежнему трое. Но каждые мгновения мира нужно просчитывать: куда сдвинулись манипуляторы, кто занял слот на ленте, где застрял поезд, сколько энергии потребили сборщики. Эта работа идёт независимо от того, кто сейчас смотрит на экран.

Поэтому вопрос «сколько друзей потянет VPS» для Factorio почти бесполезен. Полезнее другой: за какое время сервер успевает посчитать один шаг мира, что происходит в момент автосохранения и что ещё соседствует с игрой на той же машине. Разберём, как это измерять и как по результатам выбирать конфигурацию.

Два разных «тормоза»: такт мира и задержка сети

Игрокам все неприятности обычно кажутся одним словом: «лагает». Но под ним прячутся как минимум две независимые причины, и лечатся они по-разному.

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

Вторая — сетевая задержка между клиентом и сервером. Для сетевой игры используется UDP, об этом сказано в описании мультиплеера Factorio. Высокий пинг проявляется иначе: задержка между нажатием и реакцией персонажа, рывки при перемещении, запоздалое появление построек. При этом сама фабрика может считаться с нормальной скоростью. Расстояние до дата-центра влияет на это второе, но не на скорость расчёта мира.

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

Заодно напомним базовое условие: клиенты и сервер должны использовать одинаковые версии игры и модов (это следует из той же страницы мультиплеера). Нередко «не пускает на сервер» объясняется не производительностью, а рассинхроном версий. Прежде чем что-то измерять, убедитесь, что вход вообще возможен у всех.

Характер нагрузки большой фабрики

Чтобы понять, чего просить у VPS, полезно представить, из чего состоит работа сервера. Мы не будем приводить цифры производительности — они зависят от конкретного сохранения, версии и модов. Важна структура.

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

Отсюда же вытекает важная осторожность. Нельзя считать, что тариф с 8 vCPU вдвое быстрее считает фабрику, чем тариф с 4 vCPU. Дополнительные ядра полезны для другого: чтобы игре не мешали остальные процессы, чтобы система, журналирование и сетевой стек не отнимали такт у основного потока. Но линейного ускорения ждать не стоит, и именно это проверяется замером на вашем сохранении.

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

Мир без игроков: пауза и её отключение

По умолчанию игра останавливается, когда на сервере нет игроков. Параметр no-auto-pause меняет это поведение (оба факта есть на странице мультиплеера). Звучит как мелкая настройка, но для планирования ресурсов это развилка.

Если пауза работает, то ночью, когда все спят, сервер почти ничего не считает. Фабрика стоит вместе со всем игровым временем: ничего не добывается и не производится. Нагрузка на VPS возникает только в часы игры, а значит, соседние задачи на той же машине могут занимать процессор без конфликта в нерабочее время.

Если пауза отключена, фабрика работает круглосуточно, и сервер непрерывно считает мир. Для тех, кто любит заходить утром и видеть накопленные ресурсы, это приятно. Но тогда нагрузка постоянна, и любые сторонние процессы будут конкурировать с игрой в любое время суток. Отключая автопаузу, вы фактически заказываете у VPS непрерывную смену.

Есть и скрытая связь с автосохранением: сервер сохраняет мир не только по таймеру, но и при выходе, а автосохранения делает во время работы. Это тоже следует из описания headless-режима на странице мультиплеера. Значит, режим без пауз — это ещё и регулярные сохранения даже тогда, когда никого нет, и диск получает свою периодическую нагрузку круглосуточно.

Обычная игра и момент сохранения

Теперь о главном для этой статьи. Большую часть времени сервер просто считает шаги мира. Но периодически ему нужно записать состояние на диск, и у крупной фабрики файл сохранения тоже крупный. В этот момент нагрузка меняется: к вычислению добавляется сериализация данных и запись.

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

Здесь пригодится NVMe-накопитель: в публичном предложении VPS MAATRIX указаны NVMe и процессоры AMD EPYC. Быстрый диск сокращает время записи, но не отменяет саму необходимость сериализации. То есть диск помогает с «хвостом» сохранения, а процессор и память — с повседневным тактом. Хороший тест разделяет эти вклады.

Отдельно подумайте о частоте автосохранений. Редкое сохранение означает меньше заминок, но больше потерянного прогресса при сбое. Частое — меньше потерь, но больше пиков. Правильного числа в вакууме нет: его выбирают по тому, сколько времени занимает одно сохранение вашей фабрики и сколько работы вы готовы потерять. Если сохранение занимает заметную долю секунды и игроки это чувствуют, интервал лучше увеличить; если оно проходит незаметно, интервал можно сократить.

Один учебный профиль нагрузки

Чтобы замеры не казались абстракцией, возьмём условный профиль. Это не реальный случай и не результат испытаний, а удобная схема для рассуждений.

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

Как разложить такой профиль на измеряемые части:

1. Базовая линия. Запускаем сервер на этом сохранении без посторонних процессов и записываем, как идёт игровое время в спокойный период: с игроками и без них.
2. Момент сохранения. Следим за поведением мира в течение автосохранения: есть ли заметная заминка, сколько она длится, повторяется ли каждый раз.
3. Подключение клиента. Присоединяем нового игрока и смотрим, насколько долго он входит и что в это время происходит с миром у остальных. Вход загружает мир целиком, и этот эпизод тоже стоит отдельной строки.
4. Соседние задачи. Включаем ночной архиватор и панель, повторяем измерения и сравниваем с базовой линией.
5. Память. Наблюдаем занятую память на всех этапах и проверяем, не начинается ли выгрузка на диск.

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

Когда на VPS живёт не только Factorio

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

Возьмём наш условный профиль. Ночной архиватор сжимает файлы сохранений. Сжатие требует процессорного времени и чтения с диска. Если оно совпадает по времени с автосохранением или с работой мира без паузы, обе нагрузки сталкиваются: игре могут достаться не все такты, а диск будет делить очередь между записью сохранения и чтением архиватора. Это не обязательно катастрофа, но именно такое наложение стоит искать в замерах.

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

Тут и проявляется роль количества vCPU. Дополнительные ядра полезны не тем, что ускоряют расчёт мира, а тем, что дают соседним задачам место, где они не мешают основному потоку игры. Но это мягкая выгода, которую нужно подтверждать замером: если после добавления ядер разница с базовой линией почти исчезла, значит, ядер хватает; если нет — причина может быть в диске, памяти или самой скорости ядра.

Когда ресурсов не хватает под несколько ролей, часто разумнее разделить их: игру оставить на отдельной машине, а вспомогательные сервисы вынести на другую. Но имейте в виду, что отдельный VPS — это не гарантия отказоустойчивости: он просто убирает конкуренцию за ресурсы, не делая саму игру защищённой от сбоев. Если рядом по духу задачи автоматизации, например работа с API, можно посмотреть наш материал об автоматическом добавлении пользователей VPN через API: подобные сервисы удобнее держать отдельно от игрового процесса.

Запуск и моды: что нужно знать до измерений

Замеры имеют смысл только если сервер запускается на нужном сохранении. На странице параметров запуска описано, что --start-server получает файл сохранения, а --start-server-load-latest выбирает последнее. Для тестов это удобно по-разному: указание конкретного файла даёт повторяемость, потому что вы каждый раз стартуете с одной и той же точки, а загрузка последнего — повседневный режим, при котором сохранение меняется.

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

Отдельная тема — моды. Параметр --sync-mods синхронизирует моды с сохранением, и для загрузки модов требуется соответствующая авторизация (см. ту же страницу параметров запуска). Для вашего теста это значит следующее: набор модов нужно считать частью профиля нагрузки. Мод, добавляющий множество объектов или регулярные скрипты, может изменить стоимость такта. Сравнивая тарифы, всегда фиксируйте одинаковый набор модов, иначе вы будете сравнивать не серверы, а разные игры.

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

Как перевести замеры в выбор тарифа

В публичном предложении MAATRIX перечислены тарифы Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Эти ресурсы — отправная точка для теста, а не обещание, что на каком-то из них поместится определённая фабрика или определённое число игроков.

Логика выбора, исходя из того, что мы разобрали, выглядит так.

Если фабрика небольшая и без посторонних задач

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

Если фабрика крупная и сохранение заметно ощущается

Здесь полезно сравнить два соседних тарифа на одном и том же сохранении. Если переход на следующую ступень почти не меняет такт мира, значит, вы упираетесь в скорость одного потока, а не в ресурсы машины, и платить за вдвое больше ядер бессмысленно. Если же изменилась память и пропали признаки выгрузки, виновата была RAM.

Если на машине живут и другие задачи

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

Если игроки живут далеко от сервера

Локация меняет сетевую задержку, а не скорость расчёта. В публичном предложении перечислены UK, US, RU и FR; выбирайте так, чтобы пинг у большинства игроков был приемлемым, и отдельно проверяйте, что скорость мира от этого не зависит. Точное наличие вариантов уточняйте в форме заказа.

Практически удобно начинать с небольшого тарифа и переходить выше, когда замеры показывают конкретный упор. Для этого у VPS есть root-доступ, а по описанию в предложении VPS создаётся автоматически через пару минут после оплаты, так что тестовая конфигурация не требует долгого ожидания. Учтите только, что автоматические резервные копии мы не обещаем: файлы сохранений лучше копировать самостоятельно.

Что делать, если мир всё равно замедляется

Допустим, замеры показали, что такт не укладывается даже на мощном тарифе. Это важный результат, а не повод покупать ещё больше ядер. Он означает, что узкое место — сама фабрика или набор модов. Тогда есть два пути: изменить то, что в мире нагружает сервер, или принять более медленное игровое время. Полного курса оптимизации здесь давать не будем, но порядок рассуждений таков: сначала найдите, что вносит основную нагрузку, потом решайте, стоит ли оно того. Часто выясняется, что один гигантский участок с ботами или огромный перекрёсток дорог тратит больше такта, чем вся остальная база вместе.

Здесь тоже полезна дисциплина: меняйте по одному параметру и сравнивайте с базовой линией. Если изменили сразу тариф, количество модов и интервал автосохранения, вы уже не поймёте, что сработало.

Замерьте собственную фабрику

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

Тогда выбор конфигурации превратится из гадания в сравнение двух столбцов, а следующая запись в журнале «фабрика выросла» будет значить не «пора покупать мощнее», а «пора снова измерить».