Сколько RAM нужно серверу Minecraft?

Честный короткий ответ: 2 ГБ тянут ванильный сервер или Paper максимум для пяти друзей, 4 ГБ хватает небольшому публичному серверу на десять-двадцать человек, 6 ГБ - лёгкому модпаку или тридцати игрокам на Paper, 8-10 ГБ - серьёзному модпаку для небольшой группы, а за пределами примерно 12 ГБ вы почти всегда решаете не ту задачу не тем ресурсом. Память - самое простое, что можно купить, и наименее вероятное, что сломано. Эта статья объясняет, из чего складывается это число, где находятся две настройки, которые его двигают, и как за пять минут выяснить, узкое ли место в памяти или вы собираетесь платить зря.

Что сервер Minecraft держит в памяти#

Сервер Minecraft не загружает мир целиком. Он загружает те части мира, возле которых кто-то стоит, а остальное выбрасывает. Поэтому память растёт вместе с тем, сколько мира находится в оперативной памяти одновременно, а это примерно число игроков, умноженное на область, которую каждый из них держит загруженной, и почти не зависит от того, насколько велик мир на диске. Мир в 40 ГБ с тремя игроками онлайн обходится дёшево. Мир в 2 ГБ с тридцатью игроками, разбросанными по четырём измерениям, - нет.

Внутри кучи Java больше всего потребляют:

• Загруженные чанки. Чанк - это столбец блоков 16 на 16 от дна мира до предела высоты, хранимый как палитры состояний блоков плюс данные освещения. При view-distance=10 один игрок держит загруженным квадрат 21 на 21 чанк, то есть 441 чанк. При 8 это 289. При 6 - 169.
• Сущности и блочные сущности. Мобы, выпавшие предметы, вагонетки, стойки для брони и каждый сундук, воронка, табличка и шалкер в загруженном чанке. Здесь и бьют фермы и базы-барахольщики: чанк с 400 воронками стоит гораздо дороже пустого.
• Данные игроков и инвентари, которые невелики, плюс сетевые буферы за каждым подключением, которые при тридцати игроках уже не пустяк.
• Состояние плагинов и модов. Кэши регионов, деревья прав, очереди журналов блоков, кэш тайлов веб-карты, граф поиска пути. Некоторые плагины держат больше, чем мир.

Вне кучи самой JVM нужна память, которую настройка кучи не покрывает: metaspace для загруженных классов, кэш JIT-кода, один зарезервированный стек на поток и прямые байтовые буферы Netty. Сервер с тремястами модов может отдать одному только metaspace от 400 до 600 МБ. Этот зазор между «кучей» и «тем, что нужно контейнеру» - самая частая ошибка при подборе размера, и ему посвящён отдельный раздел ниже.

RAM по числу игроков и типу сервера#

Это рабочие числа для настроенного сервера, а не оставленного на значениях по умолчанию, с view-distance 8 и simulation-distance 6. Добавьте ступень, если у вас веб-карта, тяжёлый журнал блоков или три измерения, которыми люди действительно пользуются.

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

Куча, контейнер и зазор, который нужно оставить#

Если вы запускаете сервер сами, кучу задают двумя флагами:

$ java -Xms3G -Xmx3G -jar paper.jar --nogui

-Xmx - максимальная куча. -Xms - начальная куча, и давний совет для Minecraft - выставлять их равными, чтобы JVM не тратила время на рост и сжатие кучи, которую всё равно заполнит. На хостинге с панелью эту строку вы не набираете: значение - это поле на вкладке Startup, а команду собирает панель.

Ловушка - выставить -Xmx равным всему лимиту контейнера. На тарифе 4 ГБ -Xmx4G сообщает Java, что она может использовать каждый байт контейнера, а потом metaspace, стеки потоков и буферы Netty выводят процесс за лимит. Что будет дальше, зависит от хостера, и это никогда не чистая ошибка Java: ядро останавливает процесс, лог просто обрывается, и читать нечего - краш-репорта нет. Оставляйте запас:

Грубо: оставляйте 25% или 512 МБ, что больше, и склоняйтесь к большему на сильно модифицированном сервере, потому что metaspace растёт с числом модов, а не с числом игроков.

Дальность прорисовки и дальность симуляции#

Начиная с 1.18 в server.properties две настройки дистанции, и путаница между ними тратит и деньги, и время тика.

view-distance=8simulation-distance=6entity-broadcast-range-percentage=100network-compression-threshold=256max-tick-time=60000

Размеры определяют первые две:

• `view-distance` (по умолчанию 10) - на сколько чанков от каждого игрока сервер держит загруженными и отправляет клиенту. Это рычаг памяти и трафика. Переход с 10 на 8 сокращает загруженный квадрат на игрока с 441 чанка до 289, то есть на 34%, и в выживании почти никто этого не замечает.
• `simulation-distance` (по умолчанию 10) - на каком расстоянии чанки действительно тикают: мобы двигаются, растут посевы, работает редстоун, воронки тянут предметы. Это рычаг CPU. Большинство серверов спокойно живут с 6, а фермы за этим радиусом просто замирают, пока кто-нибудь не вернётся.

Пара 10 и 10 по умолчанию щедра для мира размером с одного игрока и расточительна для сервера. Стандартная настройка - view-distance=8 при simulation-distance=6: игроки видят приличный горизонт, а сервер симулирует только то, что достаточно близко, чтобы иметь значение. Paper умеет задавать обе для каждого мира отдельно в config/paper-world-defaults.yml, и так вы даёте лобби дистанцию 4, а миру выживания 8. Оптимизация Paper охватывает остальные эти файлы, а каждый ключ `server.properties` - те, что пропущены здесь.

Есть ещё один параметр, помогающий загруженному серверу без затрат памяти: entity-broadcast-range-percentage. При значении по умолчанию 100 сервер сообщает каждому клиенту о сущностях на всей его дальности прорисовки. Снижение до 50 примерно вдвое сокращает исходящие пакеты сущностей, а на публичном сервере с сорока игроками это важнее лишнего гигабайта кучи.

Почему большая куча перестаёт помогать#

Java не использует память, которую у неё не просили, поэтому простаивающий сервер на тарифе 14 ГБ работает не лучше того же сервера на 6 ГБ. Хуже того, большая куча делает каждую сборку мусора дольше, а не короче, потому что обходить надо больше. Сервер Paper на двадцать игроков, которому дали 16 ГБ, обычно показывает тот же средний tick rate, что и тот же сервер на 6 ГБ, но заметно хуже подвисает, когда работает сборщик.

Есть реальный порог, о котором нужно знать. Ниже примерно 12 ГБ G1 (сборщик по умолчанию, под который настроен стандартный набор флагов сообщества) ведёт себя хорошо с целевой паузой 200 мс. Выше него настройка меняется: широко используемый набор флагов предлагает поднять G1NewSizePercent и G1HeapRegionSize для больших куч, а некоторые крупные серверы с модами переходят на Shenandoah или поколенческий ZGC на Java 21. Это не повод покупать большую кучу, которая вам не нужна; это предупреждение, что большая куча - проект по настройке, а не покупка. В флаги JVM и версии Java лежат сами наборы флагов.

Поэтому неприятное правило: если сервер подтормаживает, а график памяти лежит заметно ниже лимита, дело не в памяти, и добавление её ничего не изменит. У вас проблема с CPU, с настройкой дистанции, с генерацией чанков или с одним плохо ведущим себя плагином. CPU и RAM для игровых серверов - общая версия этого довода; почему падает TPS - версия для Minecraft.

Как доказать, что проблема в памяти#

Пять минут доказательств лучше вечера догадок. По порядку:

1. Смотрите на график памяти, пока люди играют. Здоровый сервер Java рисует пилу: растёт, срабатывает сборщик, падает обратно. Если она растёт до лимита и остаётся плоской у потолка, вам не хватает. Если она достигает 60% и там остаётся, не хватает не вам.
2. Запустите профилировщик. Стандарт - spark: /spark profiler start, поиграйте несколько минут, /spark profiler stop и откройте напечатанную ссылку. Он называет плагин, мод или систему, которые съедают тик. /spark health печатает TPS и память вместе, а /spark heapsummary показывает, какие классы держат кучу, - если на первом месте собственный кэш плагина, вы нашли ответ, и это не повышение тарифа.
3. Читайте MSPT, а не TPS. На Paper /mspt показывает миллисекунды на тик. В тике 50 мс. На 45 мс вы в одной ферме сущностей от заметного лага, пока TPS всё ещё показывает 20.0, поэтому MSPT предупреждает раньше.
4. Уменьшите `view-distance` на два и перезапустите. Бесплатно, обратимо и это самый большой рычаг на загруженном сервере. Если это помогло, у вас была проблема с дистанцией, а не с памятью.
5. Смотрите на сборщик мусора, а не на среднее. Сервер с 20 TPS и трёхсекундным зависанием раз в десять минут страдает от сборки мусора - обычно из-за раздутой кучи или плагина, который активно выделяет память в цикле. /spark gcmonitor показывает паузы по мере их появления.

Модпаки меняют арифметику#

Модпак - это нагрузка другого рода, и советы выше смещаются тремя конкретными способами.

Загрузка классов - это настоящая память. Триста модов - это десятки тысяч классов, а metaspace лежит вне кучи. Поэтому модпак, который «должен уместиться в 6 ГБ», умирает на контейнере 6 ГБ с -Xmx6G: куча была в порядке, а процесс всё равно вышел за лимит. Дайте тому же паку -Xmx4500M на том же тарифе, и он часто работает.

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

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

Практические цифры для модов: 30-80 модов на Fabric с обычным набором для производительности спокойно работают в 6 ГБ. Пак с 150+ модов на Forge или NeoForge требует 8-10 ГБ. Пак «всё и сразу» эпохи 1.12 с сотнями машин требует 10 ГБ и Java 8, что само по себе ловушка, - смотрите Minecraft с модами без падений: там матрица версий Java и разбор краш-репорта, который на самом деле про память.

Что происходит, когда вы упираетесь в лимит#

Есть три разных отказа, и выглядят они совершенно по-разному, поэтому научитесь их различать:

• `java.lang.OutOfMemoryError: Java heap space`. JVM запросила место в собственной куче и не получила его. Вы получаете трассировку стека, обычно краш-репорт, а часто и сервер, который какое-то время ковыляет. Поднимите -Xmx, если есть место под лимитом контейнера; иначе повышайте тариф или снижайте нагрузку.
• `OutOfMemoryError: Metaspace` или `GC overhead limit exceeded`. Первое - давление от загрузки классов, второе означает, что сборщик работает постоянно и почти ничего не освобождает. Оба обычно значат, что модпак на размер меньше своего тарифа.
• Лог просто обрывается. Ни исключения, ни краш-репорта. Процесс остановили снаружи, потому что контейнер превысил лимит памяти. На RE:NODE это сделано намеренно: на лимите сервер останавливается и чисто перезапускается, а не остаётся в подкачке, потому что сервер Minecraft в подкачке хуже перезапускающегося. Цена - всё, что мир не успел сохранить, поэтому важны короткий интервал автосохранения и настоящие бэкапы. Наблюдатель за падениями также замечает повторные перезапуски: три за час выводят предупреждение на странице сервера и автоматически открывают тикет, и это обычно первый момент, когда кто-то понимает, что -Xmx был выставлен на весь тариф.

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

FAQ#

Хватит ли 2 ГБ для сервера Minecraft?

Для примерно пяти игроков на vanilla или Paper с view-distance=8 - да, с запасом. Поставьте -Xmx около 1500M, чтобы память вне кучи тоже уместилась, держите список плагинов коротким и не запускайте на нём веб-карту. Для любого модпака 2 ГБ недостаточно.

Нужно ли больше RAM для большего мира?

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

Должны ли -Xms и -Xmx быть одинаковыми?

На выделенном игровом сервере да. Куча всё равно заполняется примерно до одного уровня в каждой сессии, поэтому позволять JVM её растить и сжимать - лишняя работа. Равные значения ещё и облегчают чтение графика памяти, потому что тогда ровная линия у потолка что-то значит.

Почему сервер использует всю RAM, которую я ему даю?

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

Значит ли больше плагинов больше RAM?

Меньше, чем принято думать. Типичный плагин стоит несколько мегабайт на классы и то, что он кэширует. По-настоящему плагины стоят времени основного потока, а оно проявляется в tick rate, а не в памяти. Исключения, которые действительно съедают кучу, - веб-карты, журналы блоков с большими очередями в памяти и всё, что кэширует регионы или данные чанков.

Сколько RAM нужно серверу с модами на одного игрока?

Это неверный вопрос для модов. Собственный вес пака - классы модов, реестры, генерация мира - доминирует, и платить за него приходится, будь онлайн один человек или восемь. Сначала подбирайте размер под пак, а потом добавляйте примерно 250-500 МБ на каждого одновременного игрока сверх первых нескольких.