Сколько RAM нужно для Minecraft сервера

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

Базовые требования: ванилла vs моды

Minecraft-сервер на чистой ваниле в 1.20+ при старте съедает около 1-1.5 GB оперативной памяти. Это без единого игрока - просто загрузка мира, спавн-чанки, базовые системы.

Paper/Spigot оптимизируют потребление и при тех же условиях укладываются в 800 MB - 1.2 GB. Разница не огромная, но она растёт с нагрузкой.

Forge с 30-50 модами стартует от 2-3 GB. Тяжёлые модпаки типа All the Mods 9 или FTB Revelation легко просят 4-6 GB только на старт. Fabric где-то посередине - стартовое потребление ближе к Paper, но с модами вроде Create или Sodium нагрузка растёт ощутимо.

Первое правило: считайте от стартового потребления, а не от нуля. Сервер, которому нужно 2 GB на старт, при 20 игроках потребует совсем другие цифры, чем тот, что стартует с 800 MB.

Расчёт RAM на игрока

Универсальной формулы нет, но есть проверенные приблизительные значения.

Для Paper/Spigot:

Каждый игрок добавляет примерно 50-80 MB к потреблению
Загруженные чанки - основной потребитель, примерно 10-15 MB на чанк в памяти
Стандартная view-distance=10 означает 441 чанк на игрока (21x21)
При view-distance=6 это всего 169 чанков - разница почти в 3 раза

Для Forge/Fabric с модами:

На игрока уходит от 100 до 300 MB в зависимости от модпака
Моды с собственными мирами (RFTools Dimensions, Compact Machines) могут резко увеличить потребление
Тайл-энтити от технических модов (Applied Energistics, Mekanism) очень прожорливы

Таблица рекомендаций

Игроков	Paper/Spigot	Forge (лёгкий)	Forge (тяжёлый)	Fabric + моды
1-5	2-3 GB	4-5 GB	6-8 GB	3-4 GB
5-15	3-5 GB	5-7 GB	8-10 GB	4-6 GB
15-30	5-7 GB	7-10 GB	10-14 GB	6-8 GB
30-50	7-10 GB	10-14 GB	14-18 GB	8-12 GB
50-100	10-14 GB	-	-	12-16 GB
100+	14-20 GB	-	-	-

Forge с тяжёлыми модпаками плохо масштабируется выше 30 игроков. Это не ограничение RAM - это однопоточность Java. Но об этом дальше.

Эти цифры - для стандартных настроек. Если вы урезали view-distance до 6, отключили entity-tracking для мобов за пределами 48 блоков и настроили Paper на агрессивную выгрузку чанков - можно уменьшить на 20-30%.

Почему больше RAM - не всегда лучше

Многие думают: "куплю 32 GB, выделю все под сервер, будет летать". На практике это создаёт проблему хуже, чем нехватка памяти - долгие паузы сборщика мусора.

Java использует garbage collector (GC) для очистки неиспользуемой памяти. При стандартном G1GC, который используется в Minecraft, сборщик периодически проходит по всей выделенной памяти и удаляет объекты, на которые никто не ссылается.

Чем больше куча (heap) - тем дольше этот проход. При 32 GB major GC может занимать 2-5 секунд. В это время сервер замирает. TPS падает. Игроки видят лаги. Всё стоит, пока GC не закончит работу.

При 8-12 GB GC-паузы обычно укладываются в 50-150 мс - игроки даже не замечают. Это ключевой момент: лучше иметь достаточно памяти, чем избыточно много.

Правило: выделяйте на 15-25% больше, чем реально потребляет сервер под пиковой нагрузкой. Не в 2-3 раза больше.

Флаги Aikar: что это и зачем

Aikar (разработчик Paper) составил набор JVM-флагов, которые оптимизируют работу G1GC конкретно под Minecraft-серверы. Это не магия - это настройка параметров сборщика мусора под специфику нагрузки.

Для серверов с 8 GB и меньше:

java -Xms8G -Xmx8G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Для серверов с 12 GB и больше:

java -Xms12G -Xmx12G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=40 \
  -XX:G1MaxNewSizePercent=50 \
  -XX:G1HeapRegionSize=16M \
  -XX:G1ReservePercent=15 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=20 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Что делают ключевые флаги:

-Xms и -Xmx одинаковые - выделяет всю память сразу. JVM не тратит ресурсы на расширение кучи
G1NewSizePercent=40 - увеличивает молодое поколение. Minecraft создаёт множество короткоживущих объектов (пакеты, тики, координаты), и большой young gen позволяет собирать их дешево
G1HeapRegionSize=16M - увеличенные регионы для больших куч. Уменьшает overhead на управление
MaxGCPauseMillis=200 - целевое время паузы. GC будет стараться укладываться, но это не гарантия
InitiatingHeapOccupancyPercent=20 - начинать фоновую сборку рано, чтобы не доводить до emergency collection
AlwaysPreTouch - при старте физически выделить всю память. Убирает задержки при первом обращении к страницам

Важно: -Xms и -Xmx должны быть одинаковыми. Если поставить -Xms2G -Xmx8G, JVM будет постоянно изменять размер кучи, что вызывает дополнительные задержки.

Paper vs Forge vs Fabric: потребление памяти

Paper/Spigot/Purpur

Самые экономные. Paper агрессивно оптимизирует чанки, сущности и тайлы. Ключевые настройки, влияющие на RAM:

paper.yml > max-auto-save-chunks-per-tick - ограничивает одновременное сохранение
spigot.yml > view-distance - главный рычаг управления памятью
paper.yml > delay-chunk-unloads-by - как быстро выгружать неиспользуемые чанки

При правильной настройке Paper в 6 GB нормально обслуживает 30 игроков.

Forge

Forge-серверы едят больше памяти из-за модов. Каждый мод добавляет свои классы, регистры, тайл-энтити. Некоторые конкретные примеры:

Applied Energistics 2 с большой ME-сетью - до 500 MB дополнительно
Mekanism с полной цепочкой производства - 200-400 MB
Создание нестандартных измерений (RFTools) - до 1 GB на измерение
Dynmap/BlueMap - 500 MB-2 GB в зависимости от отрендеренной области

Fabric

Fabric сам по себе легковесный - по сути это загрузчик модов. Потребление зависит целиком от установленных модов. Lithium и Starlight уменьшают потребление. Create и технические моды увеличивают. В среднем Fabric на 15-25% экономнее Forge при сопоставимом наборе модов.

Swap и OOM-killer

Swap

Swap (файл подкачки) - это дисковое пространство, которое система использует как "запасную" память. Для Minecraft-сервера swap - это катастрофа. Когда JVM начинает использовать swap, производительность падает в 100-1000 раз по сравнению с RAM.

Рекомендации:

Не полагайтесь на swap как на источник памяти для сервера
Держите swap для системных процессов, но настройте swappiness:

# Текущее значение
cat /proc/sys/vm/swappiness

# Установить низкий swappiness (предпочитать RAM, а не swap)
sudo sysctl vm.swappiness=10

# Сохранить при перезагрузке
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

При swappiness=10 система будет использовать swap только в крайнем случае. Это значит, что Java-процесс останется в RAM, а не уедет на диск.

OOM-killer

Когда системе совсем не хватает памяти, ядро Linux запускает OOM-killer, который убивает процесс с наибольшим потреблением RAM. Обычно это ваш Minecraft-сервер.

Признаки работы OOM-killer:

# Проверить, убивался ли процесс
dmesg | grep -i "out of memory"
dmesg | grep -i "oom-kill"

# Посмотреть текущий OOM-score процесса
cat /proc/$(pidof java)/oom_score

Защита от OOM:

Не выделяйте серверу больше 80% доступной RAM на машине
Оставьте 1-2 GB для системы, дискового кэша и прочих процессов
Если на VPS 8 GB - выделяйте серверу максимум 6 GB

Пример: VPS с 16 GB RAM. Система и базовые сервисы съедают ~1 GB. Дисковый кэш просит ~1-2 GB. Итого под Minecraft можно отдать 12-13 GB.

Мониторинг RAM через spark

spark - это профайлер для Minecraft серверов, который показывает реальное использование памяти в деталях. Установите его как плагин (Paper) или мод (Forge/Fabric).

Базовые команды:

/spark health         - общая информация о сервере
/spark heapdump       - полный дамп кучи для анализа
/spark heapsummary    - краткая сводка по использованию памяти
/spark gc             - статистика сборщика мусора

На что обращать внимание:

Частота GC: если minor GC происходит каждые 2-3 секунды - всё нормально. Если major GC чаще, чем раз в минуту - памяти мало или young gen слишком маленький.

Время GC-пауз: minor GC должен укладываться в 10-50 мс. Major GC - в 100-300 мс. Если major GC занимает больше 500 мс - куча слишком большая или настройки GC не оптимальные.

Heap usage после GC: если после major GC используется больше 80% кучи - памяти реально не хватает. Пора увеличивать или оптимизировать.

Топ потребителей: heapsummary покажет, какие объекты занимают больше всего места. Часто это чанки, Entity, TileEntity или данные плагинов/модов.

Автоматический мониторинг:

/spark health --memory

Эта команда показывает текущее потребление, пиковое за сессию и среднее. Записывайте показания при пиковом онлайне - это и есть ваш реальный ориентир для выделения RAM.

Когда нужно больше CPU, а не RAM

Это частая ошибка: сервер лагает, администратор добавляет RAM, но ничего не меняется. Потому что проблема была в процессоре.

Minecraft-сервер однопоточный в основном тиковом цикле. Один тик = 50 мс (20 TPS). Если тик не успевает за 50 мс - TPS падает. И RAM тут ни при чём.

Симптомы нехватки CPU:

TPS ниже 20, но RAM используется на 50-60%
spark profiler показывает, что основное время - в entityTick, chunkTick или pluginTick
Добавление RAM не влияет на TPS

Симптомы нехватки RAM:

Частые и долгие GC-паузы
TPS периодически проседает до 0-5 на секунду-две, потом восстанавливается
spark gc показывает major GC каждые 10-30 секунд
Сервер крашится с OutOfMemoryError

Что делать, если проблема в CPU:

Перейти на хостинг с более быстрым одноядерным процессором (тактовая частота важнее количества ядер)
Уменьшить view-distance (это снижает и нагрузку CPU, и RAM)
Оптимизировать плагины/моды - некоторые безбожно тяжёлые в тиковом цикле
Использовать Paper/Purpur вместо Spigot - многие операции вынесены в асинхронные потоки

Практические советы

Начните с малого. Поставьте 4 GB, понаблюдайте через spark неделю. Увеличивайте на 2 GB, если нужно
-Xms = -Xmx. Всегда. Без исключений
Не забывайте про систему. JVM - не единственный процесс на машине
View-distance - самый мощный рычаг. Уменьшение с 10 до 7 экономит до 40% RAM
Pregenerate мир. Генерация чанков в реальном времени - дорогая операция и по CPU, и по RAM
Перезапускайте раз в сутки. Java-серверы имеют тенденцию к утечкам памяти через плагины. Ежедневный рестарт в 5 утра при минимальном онлайне - норма
Мониторьте, не гадайте. spark бесплатный. Используйте его