NVMe против обычного SSD для игрового сервера

MAATRIX GAMES

Сервер вроде бы не грузит ни CPU, ни RAM — а раз в несколько минут все игроки одновременно ловят подвисание на секунду-две, ровно в момент, когда в логах пишет Saving world. Это почти всегда диск, а не процессор: автосейв на большом мире Minecraft или ARK — это не "записать пару килобайт", а разом перезаписать сотни файлов чанков или сериализовать десятки тысяч объектов на карте. Разберём, чем NVMe реально отличается от обычного SATA SSD применительно к игровым серверам, где эта разница ощущается на практике, а где вы просто переплатите за цифры в характеристиках, которые сервер никогда не выберет полностью.

В чём физическая разница между NVMe и SATA SSD

SATA SSD — это твердотельный накопитель, который всё равно упирается в интерфейс SATA III с потолком около 550-600 МБ/с последовательного чтения/записи, потому что протокол проектировался ещё под механические диски и не был рассчитан на скорости флеш-памяти. NVMe-накопитель подключается напрямую к шине PCIe и обходит это ограничение — линейная скорость может быть 2000-7000+ МБ/с в зависимости от поколения (PCIe 3.0/4.0/5.0) и модели, то есть в разы, а иногда на порядок выше.

Но для игрового сервера последовательная скорость — не самое важное. Сервер не читает и не пишет диск одним большим потоком, он делает тысячи мелких случайных операций: чтение отдельного региона чанка, запись изменённого куска мира, запись строки в лог. Здесь решает не МБ/с, а IOPS (операций ввода-вывода в секунду) и задержка (latency) одной операции.

• SATA SSD: задержка порядка десятков-сотен микросекунд плюс накладные расходы протокола AHCI, который изначально проектировался под механические диски, а не под очереди на тысячи одновременных команд.
• NVMe: протокол спроектирован специально под флеш-память, поддерживает десятки тысяч очередей команд параллельно, задержка кратно ниже, особенно под смешанной нагрузкой чтение+запись одновременно — именно то, что происходит на сервере в момент автосейва при живом онлайне.

Разница ощущается не в "скачал файл на 10% быстрее", а в отзывчивости под нагрузкой: сколько всего в секунду сервер способен прочитать/записать мелкими кусками, не подвешивая при этом обработку сетевых пакетов и игровой тик.

Что вообще происходит на диске игрового сервера

Прежде чем сравнивать цифры, стоит понимать, какие именно операции нагружают диск на типичном игровом сервере:

• Автосейв мира. Периодическая (обычно раз в 5-15 минут) запись изменённых частей мира — самая тяжёлая регулярная операция.
• Загрузка чанков/регионов при передвижении игроков. Каждый раз, когда игрок идёт в непосещённую или выгруженную область, сервер читает файлы с диска.
• Бэкапы. Полная или инкрементальная копия мира — редкая, но тяжёлая по объёму операция.
• База данных плагинов/модов. Экономика, права, кланы, античит — многие плагины пишут в SQLite или MySQL при каждом действии игрока, это постоянный поток мелких транзакций.
• Логи. Сами по себе лёгкие, но при высоком онлайне и debug-логировании дают заметный поток мелких записей.
• Загрузка мода/плагина/карты при старте или ресте сервера. Разовая, но объёмная операция чтения.

Ключевой вывод: игровой сервер — это в первую очередь нагрузка мелкими случайными операциями, а не большими последовательными файлами. Поэтому разница между HDD и любым SSD драматическая (это вообще другой класс), а вот разница между SATA SSD и NVMe заметная, но не революционная, и сильно зависит от конкретного кейса.

Minecraft: где диск решает, а где нет

Minecraft хранит мир в регионах — файлах .mca (Anvil-формат) размером 32×32 чанка каждый, в папке world/region/ (и отдельно world/DIM-1/region/ для Нижнего мира, world/DIM1/region/ для Края). Каждый раз, когда игрок заходит в новую область, сервер читает нужный .mca-файл целиком или частично; при изменении блока регион помечается "грязным" и переписывается при следующем автосейве.

Интервал автосейва задаётся в server.properties:

# в тиках, 20 тиков = 1 секунда, значение по умолчанию 6000 = 5 минут

а фактическая частота на Paper/Spigot дополнительно управляется через spigot.yml. На большом обжитом мире (с активным view-distance 10-12+) автосейв может переписывать сотни .mca-файлов за раз — и тут разница между SATA SSD и NVMe становится ощутимой физически: на SATA игроки чаще ловят короткий "фриз" именно в момент сохранения, потому что диск занят записью и одновременно должен обслуживать чтение новых чанков от передвигающихся игроков.

Признаки, что узкое место именно диск, а не CPU: пауза в логе вокруг строки Saving world или [ChunkIoExecutor], /tps (Paper) проседает не постоянно, а именно в момент сейва, и iostat -x 1 на хосте показывает всплеск %util до 90-100% в тот же интервал.

Если у вас модовая сборка (Forge/Fabric) с десятками структурных модов и тяжёлыми мирами — I/O-нагрузка растёт заметно сильнее, чем на ванильном Paper, потому что моды часто держат свои данные отдельными файлами или в базе. Подробнее про разницу в требованиях разобрано в статье производительность: modded против vanilla сервера, а если сервер уже подвисает и непонятно, диск это или CPU — смотрите низкий TPS и лаги на Minecraft-сервере.

ARK: Survival Evolved/Ascended — самый требовательный к диску кейс

ARK — пожалуй, игра, где разница SATA/NVMe заметнее всего среди популярных проектов в каталоге. Причина в механике сохранения: ARK не хранит мир регионами, как Minecraft, а периодически сериализует весь прогресс карты в один файл сохранения (.ark, плюс отдельно профили игроков и племён) — все постройки, приручённых существ, инвентари. На обжитой карте с большим количеством строений (особенно с модами вроде S+) файл сохранения может разрастись до сотен мегабайт и даже единиц гигабайт, и каждый автосейв — не инкрементальная запись изменений, а перезапись значительной части этого состояния целиком.

На SATA SSD с активным кластером из нескольких карт (ARK Cluster, когда серверы делят общий пул персонажей и предметов через -clusterid) моменты сейва на всех картах могут ощутимо просаживать отзывчивость — рывки, задержка при взаимодействии с инвентарём, лаги приручённых существ.

Практические ориентиры: на небольшой карте с онлайном до 10-15 игроков и умеренной застройкой SATA SSD вполне справляется — файл сохранения маленький, автосейв быстрый. На обжитой карте (много построек, десятки прирученных существ, активный клан), онлайне 20+ и особенно с модами на структуры NVMe снижает длительность и заметность автосейва в разы. Кластер из нескольких карт эффект умножает: каждая карта сохраняется по своему расписанию, и на SATA эти операции могут накладываться друг на друга.

Как поднять сервер и настроить автосейв — в статье как поднять сервер ARK: Survival Evolved. Часть проблем в кластерной конфигурации, которые списывают на сеть между картами, на деле упирается именно в диск.

Rust, CS2 и другие: короче автосейв, но свои нюансы

• Rust. Карта сохраняется реже, чем в ARK (интервал через server.saveinterval, обычно раз в несколько минут), но карта размера 4000-4500 может занимать сотни мегабайт вместе со всеми постройками игроков. На позднем вайпе (перед еженедельной перегенерацией) с активным крафтом — та же логика, что в ARK: NVMe заметно сокращает время сейва на крупных картах.
• CS2. Диск важен в первую очередь на старте и при загрузке карт — особенно кастомных Workshop-карт, которые сервер скачивает и распаковывает. Во время самого матча I/O-нагрузка минимальна (античит и статистика — это в основном сеть), так что разница SATA/NVMe почти не влияет на геймплей, зато ускоряет ресты сервера и подгрузку карт в ротации.
• 7 Days to Die. Сохранение мира с учётом разрушаемости ландшафта даёт заметный I/O-всплеск на blood moon и последующем автосейве — похожая логика на Minecraft, только объём изменений на волне орды выше.
• FiveM. Основная нагрузка — не файловая система мира, а база данных фреймворка (ESX/QBCore): инвентари, гаражи, экономика. Решает не столько тип диска под саму игру, сколько то, на каком накопителе крутится MySQL — запросы от активных ролплей-скриптов выигрывают от NVMe заметнее, чем сама игра.

Когда разница реально ощутима, а когда SATA SSD достаточно

Сводная таблица по сценариям — ориентир, а не точная граница, потому что многое зависит от конкретной сборки, числа модов/плагинов и настроек автосейва:

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

Как проверить свой случай, а не гадать по таблице

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

1. Замерьте, где происходит просадка. На Linux-хосте с SSH — iostat -x 1 5 во время автосейва покажет %util и await; если %util уходит к 90-100% и await резко растёт именно в момент сейва — это диск.
2. На Minecraft сопоставьте время просадки /tps с меткой Saving world в консоли/логе.
3. Проверьте размер мира: du -sh world/ для Minecraft, размер файла сохранения в Saved/SavedArks/ для ARK. Если мир вырос за месяцы до нескольких гигабайт — вероятность упереться в диск растёт вместе с ним.
4. Если несколько апгрейдов RAM/CPU не помогли, а фризы всё равно случаются строго по расписанию автосейва — это почти наверняка диск.
5. При выборе тарифа полезно свериться с какой тариф выбрать под конкретную игру — там разбор требований к RAM/CPU, который стоит смотреть вместе с типом диска.

Если SSH недоступен, косвенный признак тот же: посмотрите, совпадает ли по времени просадка FPS/пинга у игроков с интервалом автосейва — совпадение почти всегда указывает на диск.

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