Предельная оптимизация сервера Minecraft: когда базовой уже мало
Эта статья — продолжение обычных гайдов по оптимизации сервера Майнкрафт.
Здесь мы говорим не про «поставил Paper, уменьшил view-distance и пошёл», а про предельную, почти «энтерпрайз» оптимизацию:
– тонкая настройка server.properties, spigot.yml, bukkit.yml, paper-* и purpur.yml;
– работа с ядрами Paper / Pufferfish / Purpur;
– прогрузка карты, борьба с лаг-фермами;
– флаги запуска Java и правильное железо.
Важно: если ваш сервер и так летает, TPS ~20, жалоб нет — не нужно сломя голову менять все конфиги «по гайду».
Предельная оптимизация нужна, когда:
– онлайн растёт,
– карта разрастается,
– фермы и сложные механики душат вашу машину,
– а базовые советы уже не помогают.
Содержание
- 1. Общие принципы предельной оптимизации
- 2. Что НЕ делать (и за что банит карма админа)
- 3. Выбор ядра: что брать, а что выкинуть навсегда
- 4. Прогрузка карты заранее (Chunky, worldborder)
- 5. Работа с конфигами: подход и приоритеты
- 5.1 server.properties — ключевые параметры
- 5.2 bukkit.yml — спавн, лимиты и автосейв
- 5.3 spigot.yml — сущности, взрывы, воронки
- 5.4 paper-global.yml — глобальные флаги и система чанков
- 5.5 paper-world-defaults.yml — миры, despawn и redstone
- 5.6 purpur.yml — агрессивная оптимизация геймплея
- 5.7 pufferfish.yml — DAB и таймауты сущностей
- 6. Anti-Xray и сиды: защита и уникальность мира
- 7. AFK-фермы и политика AFK-игроков
- 8. Флаги запуска сервера Minecraft (Java / G1GC)
- 9. Практический алгоритм предельной оптимизации
- 10. Краткий чек-лист по шагам
- 11. FAQ по предельной оптимизации сервера
1. Общие принципы предельной оптимизации
Главное правило: не трогай то, что и так хорошо работает.
Перед тем как менять конфиги:
- Измерьте проблему: сделайте тайминги (Paper Timings) или профилирование через Spark. Ищите, что реально ест время тиков: сущности, чанки, redstone, плагины.
- Меняйте точечно: один параметр → перезапуск → наблюдение. Не крутите всё подряд «по списку».
- Думайте про геймплей. Почти каждое «ускорение» — это удар по ванильности. Иногда игрокам важнее фермы и механики, чем +2 TPS.
- Всегда делайте бэкапы: мир + конфиги + базы плагинов. Перед экспериментами — отдельная копия.
- Не верьте слепым «пакетным» конфигаам из рандомного Телеграма. То, что летает на одном сервере, может убить ваш.
2. Что НЕ делать (и за что карма мстит админам)
2.1. Не используем слитый софт
Слитые премиум-плагины / ядра:
- часто содержат бэкдоры и вредоносный код;
- не получают обновлений и фиксов;
- убивают репутацию и безопасность сервера.
Если нет денег на платный плагин — лучше найти бесплатный аналог, чем ставить «кряк».
2.2. Не живём на старых версиях ради «лагов меньше»
Да, какие-то старые версии легче для железа, но:
- они часто дырявые по безопасности;
- игроки ждут новый контент;
- антиботы и новые плагины ориентируются на актуальные ветки.
Если нужен максимум производительности — лучше оптимизировать актуальный Paper/Purpur, чем сидеть на заброшенном форке ради призрачных плюсов.
2.3. Не используем датапаки с функциями вместо плагинов
Большинство датапаков писались под одиночку. На сервере они:
- плохо масштабируются под онлайн;
- часто нагружают тики;
- сложно дебажатся.
Для серверной логики почти всегда лучше плагин, а не датапак с кучей функций.
2.4. Не берём «дурные» хостинги
Дёшево ≠ выгодно. Плохой хостинг убьёт все ваши оптимизации:
- слабое железо, забитые диски, зашитый CPU;
- нет защиты от DDoS;
- нестабильная сеть.
Если есть выбор «хорошее ядро на плохом железе» или «нормальное ядро на адекватном VPS» — выигрывает второе.
2.5. Не трогаем экспериментальные / заброшенные форки
Что НЕ использовать (как основное ядро):
- Yatopia
- Airplane (старый)
- Patina
- Mirai
- Sugarcane
- JettPack
- Fusion
Это либо заброшенные, либо экспериментальные форки, которые могут вести себя непредсказуемо, ломать плагины и миры.
3. Выбор ядра: что брать, а что выкинуть навсегда
Что использовать в 2025 году
- Paper — стандартизованный форк Spigot, хорошая производительность и стабильность, море гайдов.
- Pufferfish — форк Paper с дополнительными оптимизациями (DAB, entity_timeouts и пр.).
- Purpur — форк Paper/Pufferfish с огромным количеством геймплейных и производительных настроек; идеален для «предельной» настройки.
Рекомендация:
- Небольшой / средний сервер — Paper или Purpur.
- Высокий онлайн, жёсткая оптимизация — Pufferfish или Purpur с включёнными pufferfish-патчами.
4. Прогрузка карты заранее (Chunky, worldborder)
Генерация чанков «на лету» — один из главных убийц TPS и диска, особенно на 1.18+.
Лучшее, что можно сделать для производительности:
- задать игрокам разумный worldborder;
- заранее прогрузить карту внутри этого круга;
- запретить бесконечный «раннинг в никуда» в поисках новых чанков.
Шаги по прогрузке (на примере Chunky)
1. Ставим плагин Chunky.
2. Настраиваем радиус:
Код:
/chunky radius <радиус_в_блоках_в_каждую_сторону>3. Выбираем мир:
Код:
/chunky world <название_мира>4. Ставим worldborder (ванильный):
Код:
/worldborder set <радиус_в_блоках_×2>5. При желании ставим более красивый барьер через ChunkyBorder.
6. Запускаем прогрузку:
Код:
/chunky startПеред этим обязательно:
- оцените место на диске (используйте калькулятор типа World Size Calculator);
- делайте прогрузку в «мертвое» время, когда почти нет онлайна.
5. Работа с конфигами: подход и приоритеты
Золотое правило: открыли конфиг — сначала читаем комментарии, потом меняем.
Общий порядок:
1. server.properties — базовые радиусы, сеть, idle-timeout.
2. bukkit.yml — спавн мобов, автосейвы.
3. spigot.yml — активность сущностей, воронки, взрывы.
4. paper-global.yml и paper-world-defaults.yml — глубокая оптимизация мира.
5. purpur.yml — куча дополнительных тумблеров.
6. pufferfish.yml — DAB и тонкая работа с сущностями.
Меняйте значения постепенно, проверяя, как это влияет на:
– TPS и MSPT (в Spark/Timings),
– поведение ферм и игроков,
– жалобы в чате.
---
5.1 Важные настройки server.properties
Некоторые ключевые параметры:
- network-compression-threshold: 128 / 256 / 512
– Меньше порог = больше сжатия = больше нагрузка на CPU, легче слабым клиентам.
– Больше порог = меньше нагрузка на CPU, больше трафик.
– Для большинства серверов подойдёт 256–512. - enforce-secure-profile=false
– Отключает модерацию/репорты чата (1.19.1+).
– Для полной вырубки уведомлений имеет смысл поставить плагин типа AntiPopup. - entity-broadcast-range-percentage=75–100
– Насколько далеко игрок «видит» сущности.
– Чем ниже, тем меньше пакетов → легче серверу и сети, но хуже визуально. - max-tick-time=-1
– Ванильный watchdog, который гасит сервер при больших лагах.
– На Paper/Purpur есть свой watchdog; часто этот параметр можно выключить (-1), но делать это лучше осознанно. - use-native-transport=true
– Включает оптимизированный сетевой стек под Linux.
– На Linux — true, на других системах — лучше оставить false. - view-distance: 2–4
– Сколько чанков вокруг игрока прогружается и тикает.
– Мощное влияние на производительность и на геймплей. - simulation-distance: 4–6
– Чанки, где «жизнь идёт» (мобы, фермы и т.д.).
– Слишком маленькие значения ломают фермы, слишком большие — душат сервер. - idle-timeout: 10–20
– Время, после которого AFK-игрок считается бездействующим.
– Можно кикать AFK или комбинировать с AFK-настройками Purpur. - allow-flight: true
– Встроенный «античит» от полёта лучше выключить и использовать нормальный плагин. - snooper-enabled: false
– Старый сбор телеметрии (в новых версиях уже неактуален). - sync-chunk-writes=false
– Асинхронная запись чанков. В Paper/Purpur обычно уже настроено; меняем только если осознаём последствия.
5.2 Важные настройки bukkit.yml
Лимиты спавна сущностей
Код:
spawn-limits:
monsters: 20
animals: 8
water-animals: 3
water-ambient: 1
axolotls: 3
water-underground-creature: 3
ambient: 1Это глобальные лимиты спавна по группам мобов.
Чем меньше значения — тем меньше мобов, тем проще серверу, но тем пустее мир.
Частота спавна
Код:
ticks-per:
animal-spawns: 400
monster-spawns: 10
water-spawns: 600
...Время в тиках между попытками спавна.
Меньше — чаще спавн, больше — реже. Тут нужно балансировать геймплей и нагрузку.
Автосейв
Код:
autosave: 6000 / 16000Как часто мир сохраняется. Сильно трогать не стоит:
- слишком редко — можно потерять прогресс при падении;
- слишком часто — лаги от постоянных записей.
Другие полезные настройки
- query-plugins: false — немного повышает безопасность, скрывая список плагинов.
- period-in-ticks: 300 — как часто выгружать неактивные чанки из памяти.
- Блок ticks-per + spawn-limits вместе задают «характер» мира: много мобов и нагрузка выше, мало мобов — проще серверу, но скучнее игрокам.
5.3 Оптимизация spigot.yml
mob-spawn-range: 3–4
Радиус в чанках, где могут спавниться мобы относительно игрока.
Сильный рычаг влияния на нагрузку и сложности игры.
hanging-tick-frequency: 250
Частота проверки декора (картины, рамки и т.п.).
Больше — меньше нагрузка, чуть больше визуальных артефактов.
merge-radius
Код:
merge-radius:
item: 4.5
exp: 8.75Радиус, в котором предметы и опыт объединяются.
Увеличение радиуса резко уменьшает число сущностей на полу — хороший буст к TPS.
netty-threads: ~1/4 ядер
Например, на 8 логических ядрах → 2–4 потока.
Не стоит ставить слишком много — лишнее только создаст конкуренцию потоков.
Удаление стрел/трезубцев
Код:
arrow-despawn-rate: 300
trident-despawn-rate: 600Чем быстрее исчезают стрелы и трезубцы, тем меньше мусора в мире.
Воронки
Код:
hopper-amount: 3–9
hopper-transfer: 8–24
hopper-check: 8–24Полностью определяют работу воронок:
- меньше amount / чаще transfer/check — чуть ближе к ваниле, но тяжелее серверу;
- больше значения — воронки медленнее, но сильно облегчают тики.
Другие важные параметры
- restart-on-crash: false — лучше использовать внешний скрипт/панель для автоперезапуска.
- save-user-cache-on-stop-only: true — уменьшает лишние операции записи во время работы.
- nerf-spawner-mobs: true — убирает AI у мобов из спавнеров, сильно полезно для гигантских ферм.
- log-villager-deaths / log-named-deaths: false — экономит место в логах.
- max-tnt-per-tick — ограничивает количество TNT, обрабатываемых за тик (важно для анархий/креатива).
- max-tick-time: tile/entity — лимиты времени обработки тайлов и сущностей, ещё один предохранитель от фризов.
entity-activation-range
Один из самых влиятельных блоков:
Код:
entity-activation-range:
animals: 10
monsters: 12
raiders: 12
misc: 4
water: 4
villagers: 8
flying-monsters: 24
...Это расстояния, на которых сущности считаются «активными».
Снижение значений даёт огромный прирост производительности, но может ломать фермы и поведение мобов.
Трогать аккуратно, по чуть-чуть.
5.4 Важные настройки paper-global.yml
timings.enabled / verbose: false
Paper-тайминги полезны для диагностики, но постоянный сбор — лишняя нагрузка.
Обычно:
- timings: enabled: false
- включаем и снимаем отчёт только, когда нужно.
Для постоянного профилинга лучше использовать Spark.
max-joins-per-tick: 1
Ограничивает количество подключений в тик. Отличная защита от волны заходов/ботов.
Чуть растёт очередь входа, но TPS живее всех живых.
Прочее
- use-rgb-for-named-text-colors — даёт цветной вывод в консоль.
- fix-entity-position-desync: true — лечит рассинхрон позиций сущностей.
- use-dimension-type-for-custom-spawners / use-alternative-luck-formula — тонкие настройки генерации/лут-таблиц; трогаем только, если понимаем эффект.
chunk-system
Параметры вроде:
Код:
chunk-system:
gen-parallelism: default
io-threads: -1
worker-threads: -1– -1 обычно означает «подобрать автоматически (половина/часть ядер)».
– при желании можно вручную указать worker-threads чуть меньше, чем количество доступных ядер, оставляя ядро-другое системе.
5.5 paper-world-defaults.yml — мир, despawn и редстоун
despawn-ranges
Код:
despawn-ranges:
ambient:
hard: 56
soft: 30
monster:
hard: 56
soft: 30
...Расстояния, на которых сущности пропадают.
Чем ближе к игроку они despawn’ятся, тем меньше висит «мусора» в дальних чанках.
keep-spawn-loaded: false
Отключает постоянную прогрузку спавна.
Если у вас нет ферм/механик, завязанных на спавн-чанки — это хороший бонус к производительности.
max-entity-collisions: 2
Сколько столкновений сущность может обработать за тик.
Снижение значения уменьшает лаги от скоплений мобов и предметов.
max-auto-save-chunks-per-tick: 8+
Максимум чанков, сохраняемых за тик.
На большом онлайне можно чуть поднять, чтобы разгрузить длительные фризы при сохранениях.
Ещё полезные параметры
- parrots-are-unaffected-by-player-movement — косметика, но уменьшает «дергания» попугаев.
- zombies-target-turtle-eggs: false — защита ферм черепах.
- disable-end-credits: true — убирает лишний экран титров.
- fix-items-merging-through-walls: true — чинит глупый баг с предметами.
- prevent-moving-into-unloaded-chunks: true — не даёт игрокам «продавить» генерацию чанков спринтом/элитрами.
- hopper.* — крупный блок оптимизаций воронок (cooldown-when-full, disable-move-event, ignore-occluding-blocks).
- armor-stands.tick / do-collision-entity-lookups: false — сильный удар по лаг-машинам на стойках.
5.6 purpur.yml — агрессивная оптимизация геймплея
Purpur добавляет огромное количество тумблеров. Несколько заметных:
- use-alternate-keepalive: true
– Делает жизнь лучше игрокам с плохим интернетом (меньше ложных киков). Несовместим с некоторыми прокси/сервисами. - dont-send-useless-entity-packets: true
– Меньше сетевого мусора. - disable-mushroom-updates / disable-note-block-updates / disable-chorus-plant-updates: true
– Полезно, если игроки не строят редстоун-машины на этих блоках или вы используете кастомные ресурспаки. - max-joins-per-second
– Ещё один уровень защиты от бот-флуда. - lagging-threshold: 17.0
– Ниже какого TPS Purpur считает сервер лагающим и включает дополнительные оптимизации. - observer.disable-clock: true
– Вырубает простые «часики» на наблюдателях. Сильно режет потенциал лаг-машин, но не понравится редстоун-маньякам. - entities-can-use-portals: false
– Запрещает мобам использовать порталы; защищает от chunk-loader’ов на порталах. - arrow.movement-resets-despawn-counter: false
– Стрела не «обновляет» таймер исчезновения в полёте; меньше вечных стрел в мире. - invulnerable-while-accepting-resource-pack: true
– Защищает игроков, пока они грузят ресурспак. - sleep-ignore-nearby-mobs: true
– Позволяет ложиться спать даже при мобах рядом; удобно на выживалках. - armorstand.*
– Набор настроек, которые практически убивают возможность строить лаг-машины на стойках для брони (движение, коллизии и т.п.). - villager.*
– Настройки «мозгов» жителей (brain-ticks, lobotomize, spawn-iron-golem), позволяющие держать огромные деревни без убийства TPS. - logger.suppress-...: true
– Чистит консоль от тонн бесполезных предупреждений. - seed.structure.*
– Отдельные сиды для структур (шахты, клады). Плюс к уникальности мира и защите от «запомненных» сидов. - AFK-блок (idle-timeout.*) — подробная политика AFK: кикать/не кикать, тикать/не тикать сущности рядом, считать ли AFK спящими и т.п.
Purpur — идеальное место, чтобы отключить самые тяжёлые/эксплуатируемые механики, если они мешают серверу жить.
5.7 pufferfish.yml — DAB и таймауты сущностей
Pufferfish уже из коробки довольно агрессивно оптимизирован. Меняем здесь только если:
– понимаем, что делаем,
– видим в профилировщике явную проблему с сущностями/снарядами.
Ключевые блоки:
- entity_timeouts — ограничение времени жизни определённых сущностей:
Код:entity_timeouts: SNOWBALL: 200 EGG: 200 LLAMA_SPIT: 40 FIREBALL: 100 DRAGON_FIREBALL: 100
Защита от лаг-машин на снежках, яйцах и прочем. - max-loads-per-projectile — сколько чанков может догрузить снаряд.
– Низкие значения защищают от «стреляющих загрузчиков чанков», но могут ломать экзотические механики. - DAB (distance-based activation):
Код:start-distance: 6–8 max-tick-freq: 35–40 activation-dist-mod: 7
DAB уменьшает частоту тика далеких от игрока сущностей.
Это мощный инструмент, но любые изменения нужно проверять на фермах и механиках.
6. Anti-Xray и сиды: защита и уникальность мира
Anti-Xray от Paper/Purpur
Анти-xray — штука не только про «борьбу с читерами», но и про нагрузку:
- правильная настройка режима (обфускация vs engine);
- списков блоков, которые маскируются;
- радиуса действия.
Если включить его слишком агрессивно, можно:
– убить FPS клиентам со слабыми ПК;
– добавить нагрузку на CPU.
Поэтому:
- внимательно читаем комментарии к разделу anti-xray в paper-/purpur-конфиге;
- включаем только то, что действительно нужно на вашем типе сервера;
- тестируем на нескольких игроках с разным железом.
Индивидуальные сиды структур
Через spigot.yml и purpur.yml можно задать отдельные сиды для генерации:
- шахт;
- кладов;
- других структур.
Плюс:
– защита от «запомненных» сидов с других серверов;
– сложнее предсказать расположение структур с помощью сайтов/утилит.
7. AFK-фермы и политика AFK-игроков
AFK-фермы — вечная боль админа: игроки их любят, сервер — ненавидит.
Подход зависит от вашего проекта:
- RP/ваниль — AFK почти не нужны, можно кикать людей через idle-timeout.
- Фермо-/техно-сервер — AFK неизбежны, но их нужно грамотно ограничивать.
Примерный набор настроек:
- idle-timeout в server.properties — время до статуса AFK (в минутах).
- AFK-блок в Purpur (примерная структура):
Код:idle-timeout: kick-if-idle: false tick-nearby-entities: false count-as-sleeping: false update-tab-list: false mobs-target: false
Пояснения:
– kick-if-idle — кикать ли игрока после AFK;
– tick-nearby-entities — тикаются ли рядом сущности (фермы);
– count-as-sleeping — считаются ли AFK «спящими» для пропуска ночи;
– update-tab-list — обновлять ли статус в TAB;
– mobs-target — могут ли мобы агриться на AFK.
Простая и рабочая схема:
– AFK-игроки не кикаются, но рядом с ними ничего не тикает;
– AFK не считаются спящими, не ломают ночь;
– мобы их не убивают (чтобы не теряли вещи из-за лагов);
– фермы, требующие активного участия, поощряются больше, чем «поставил птичку и ушёл».
8. Флаги запуска сервера Minecraft (Java / G1GC)
Флаги запуска — это настройки JVM: управление памятью, сборкой мусора и стабильностью.
8.1 Общая логика настройки JVM
Несколько базовых правил:
- Не давайте Java всю оперативку.
Обычно Xmx = 50–75% от общей RAM сервера, остальное — системе и другим процессам (БД, панель, прокси). - Xms должен равняться Xmx.
Тогда куча сразу выделяется полностью, JVM не фрагментирует память в процессе и работает стабильнее. - Используем G1GC.
Старые сборщики (Parallel, CMS) для Minecraft не дают преимуществ на современных версиях Java. - Не городим свои флаги поверх «рандомного набора».
Берём проверенный набор (Aikar flags) и при необходимости аккуратно дорабатываем.
8.2 Пример скрипта запуска с G1GC
Код:
#!/usr/bin/env bash
while true; do
java -Xms8192M -Xmx8192M \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC \
-XX:+AlwaysPreTouch \
-XX:G1HeapWastePercent=5 \
-XX:G1MixedGCCountTarget=4 \
-XX:InitiatingHeapOccupancyPercent=15 \
-XX:G1MixedGCLiveThresholdPercent=90 \
-XX:G1RSetUpdatingPauseTimePercent=5 \
-XX:SurvivorRatio=32 \
-XX:+PerfDisableSharedMem \
-XX:MaxTenuringThreshold=1 \
-Dusing.aikars.flags=https://mcflags.emc.gs \
-Daikars.new.flags=true \
-XX:G1NewSizePercent=30 \
-XX:G1MaxNewSizePercent=40 \
-XX:G1HeapRegionSize=8M \
-XX:G1ReservePercent=20 \
-Dfile.encoding=UTF-8 \
-jar server.jar
echo Restarting in 5 seconds...
echo Press CTRL + C to cancel.
sleep 5
done8.3 Расшифровка основных Java-флагов
| Флаг | Что делает |
|---|---|
| -Xms8192M / -Xmx8192M | Начальный и максимальный размер кучи (heap). Делая их равными, мы сразу выделяем фиксированный объём памяти, уменьшая фрагментацию и дергания от динамического расширения кучи. |
| -XX:+UseG1GC | Включает сборщик мусора G1GC, оптимизированный для больших куч и долгоживущих приложений вроде Minecraft. Делит память на регионы и очищает их частично, снижая длинные паузы. |
| -XX:+ParallelRefProcEnabled | Включает параллельную обработку «сложных» ссылок (Soft/Weak/Phantom, Finalizer). Ускоряет сборку мусора на многопроцессорных системах. |
| -XX:MaxGCPauseMillis=200 | Желаемое максимальное время паузы GC в миллисекундах. Не жёсткий лимит, а цель для JVM: она старается подбирать размер регионов и частоту сборок так, чтобы укладываться в это значение. |
| -XX:+UnlockExperimentalVMOptions | Разблокирует экспериментальные опции JVM, которые в обычном режиме недоступны, в том числе некоторые G1GC-тюнинги. |
| -XX:+DisableExplicitGC | Игнорирует вызовы System.gc() из кода плагинов/ядра. Защитный флаг от «дурных» плагинов, которые дергают полную сборку мусора в самый неподходящий момент. |
| -XX:+AlwaysPreTouch | Прогревает все страницы памяти при старте JVM: сразу резервирует и «трогает» всю кучу. Это делает запуск чуть дольше, но убирает микрофризы от ленивого выделения страниц позднее. |
| -XX:G1HeapWastePercent=5 | Допустимый процент «мусорной» фрагментации кучи перед началом смешанной (mixed) сборки. Меньшее значение → чаще и раньше запускаются смешанные сборки, уменьшая фрагментацию. |
| -XX:G1MixedGCCountTarget=4 | Цель по количеству смешанных циклов сборки мусора после марк-фазы. Влияет на то, как быстро G1 вычищает старое поколение. |
| -XX:InitiatingHeapOccupancyPercent=15 | Процент заполнения кучи, при котором G1 начинает concurrent-marking (фоновую разметку живых объектов). Более низкое значение запускает GC заранее, чтобы избежать резких скачков использования памяти. |
| -XX:G1MixedGCLiveThresholdPercent=90 | Максимальный процент «живых» данных в регионе, чтобы этот регион попал в mixed-сборку. Чем выше значение, тем меньше регионов считается подходящими для очистки. |
| -XX:G1RSetUpdatingPauseTimePercent=5 | Процент времени пауз GC, который можно тратить на обновление RSet (remembered set). Небольшое значение помогает ограничить, сколько времени GC «тратит» на внутренние структуры. |
| -XX:SurvivorRatio=32 | Соотношение между Eden и Survivor-памятью в молодом поколении. Чем больше число, тем меньше Survivor-область, тем быстрее объекты перемещаются в старое поколение. |
| -XX:+PerfDisableSharedMem | Отключает использование shared memory для PerfData (всякие JMX/monitoring структуры). Чуть уменьшает накладные расходы и потенциальные проблемы с правами. |
| -XX:MaxTenuringThreshold=1 | Порог «старения» объектов. После 1 «пережитой» сборки мусора объект перемещается из молодого поколения в старое. Полезно для паттерна нагрузки Minecraft, где много короткоживущих объектов. |
| -Dusing.aikars.flags=... | Просто маркер (system property) для того, что используются флаги Aikar. Непрямая настройка, но помогает понять в логах, какой набор флагов применён. |
| -Daikars.new.flags=true | Ещё один маркер, включающий «новую» версию набора флагов Aikar. Влияет на то, какие именно параметры и комбинации используются. |
| -XX:G1NewSizePercent=30 | Минимальный процент кучи, который будет отведён под молодое поколение (new generation). Важен для нагрузки с большим количеством короткоживущих объектов. |
| -XX:G1MaxNewSizePercent=40 | Максимальный процент кучи под молодое поколение. В паре с предыдущим флагом ограничивает диапазон размеров young gen. |
| -XX:G1HeapRegionSize=8M | Размер региона G1. Куча делится на регионы фиксированного размера (например, 8 МБ). Для больших куч и Minecraft это хорошее типовое значение. |
| -XX:G1ReservePercent=20 | Процент кучи, который резервируется как «запас» для предотвращения полного заполнения. Помогает избегать резких, тяжёлых сборок, когда память почти забита. |
| -Dfile.encoding=UTF-8 | Фиксирует кодировку по умолчанию как UTF-8. Защищает от странностей с логами и файлами на разных системах. |
9. Практический алгоритм предельной оптимизации
Чтобы не утонуть в сотнях параметров, держите чёткий порядок:
- Соберите метрики
Запустите Spark/Timings, посмотрите, где тратится время: сущности, чанки, плагины, redstone. - Почините «очевидное»
Уберите сломанные плагины, оптимизируйте/запретите явные лаг-машины, ограничьте откровенно безумные фермы. - Прогрузите карту и ограничьте мир
Chunky + worldborder — огромный вклад в стабильность. - Настройте server.properties
view-distance / simulation-distance / entity-broadcast-range / idle-timeout. - Оптимизируйте bukkit.yml и spigot.yml
Лимиты спавна, merge-radius, entity-activation-range, воронки. - Доведите до ума paper-* и purpur.yml
DAB, despawn-ranges, hopper/armor-stands/redstone, villager/AFK-логика. - Аккуратно троньте pufferfish.yml
Если и после всего остального карта/сущности душат сервер — включайте тяжёлую артиллерию. - Установите адекватные флаги запуска
G1GC, фиксированный объём памяти, автоперезапуск при краше. - Закрепите результат
Бэкапы, документация изменений (что и зачем меняли), и только потом — дальнейшие эксперименты.
10. Краткий чек-лист по шагам
| Шаг | Действие |
|---|---|
| 1 | Сделать бэкап мира, плагинов и всех конфигов. |
| 2 | Снять профилировку (Spark/Timings), понять, где именно лаги. |
| 3 | Перейти на Paper/Pufferfish/Purpur, если ещё не перешли. |
| 4 | Прогрузить карту через Chunky, поставить worldborder. |
| 5 | Настроить server.properties (view-distance, simulation-distance, idle-timeout и т.п.). |
| 6 | Оптимизировать bukkit.yml и spigot.yml: спавн мобов, merge-radius, entity-activation-range. |
| 7 | Тонко настроить paper-global.yml и paper-world-defaults.yml. |
| 8 | Включить/настроить нужные тумблеры в purpur.yml. |
| 9 | При необходимости поджать сущности через pufferfish.yml. |
| 10 | Выставить флаги запуска JVM (G1GC, память, автоперезапуск). |
| 11 | Починить AFK-политику и фермы (idle-timeout + Purpur AFK-блок). |
| 12 | Снова снять метрики и сравнить результат с исходным. |
11. FAQ по предельной оптимизации сервера
Нужно ли мне всё это, если сервер на 20 человек и TPS 19.9?
Нет. В таком случае достаточно базовой оптимизации. Предельная оптимизация — для проектов, где:
– онлайн стабильно высокий,
– есть тяжёлые фермы,
– и действительно есть проблемы с производительностью.
Можно ли просто взять «готовые конфиги» и не думать?
Очень нежелательно. Чужие конфиги писались под чужое железо и чужой геймплей.
Минимум — внимательно перечитайте все изменённые параметры и поймите, что именно они делают.
Как понять, что я «перегнул» с оптимизацией?
Признаки:
- ломаются фермы и механики без очевидной причины;
- игроки жалуются, что мобы «тупят» или «пропадают на глазах»;
- TPS есть, а ощущается «мёртвый» мир.
Если TPS хороший, но игрокам скучно и всё «не живёт» — вы переборщили с entity-activation-range, despawn-ranges или DAB.
Стоит ли трогать pufferfish.yml, если я не уверен?
Лучше не трогать. Pufferfish уже из коробки даёт хороший прирост, а более жёсткие настройки нужно вводить только после анализа профилировки.
Есть ли «идеальный» набор значений для всех серверов?
Нет. Характер нагрузки:
– мини-игры;
– анархия;
– ваниль;
– техно-проекты;
— радикально отличается. То, что идеально для мини-игр, может убить ванильный сервер.
С чего начать, если хочется «максимума», но страшно?
С базовых шагов:
1. Переход на Paper/Purpur.
2. Прогрузка карты.
3. server.properties + bukkit/spigot (без экстремальных значений).
4. Флаги запуска JVM.
А уже потом — аккуратные правки paper-/purpur-/pufferfish-конфигов по одному параметру за раз.
Как понять, что флаги Java настроены адекватно?
- Сервер не упирается в OOM, не падает по памяти.
- Нет регулярных длинных фризов на GC (по логам и ощущениям).
- MSPT остаётся в разумных пределах даже под нагрузкой.
- При этом остаётся запас RAM под систему и другие процессы.
Если всё так — не нужно «дотюнивать» флаги ради флагов.
