Оптимизация сервера Minecraft Fabric в 2026: полное руководство по настройке и модам

Fabric-сервер Minecraft тормозит, TPS падает ниже 20, а игроки жалуются на лаги. Для оптимизации сервера Fabric нужна правильная комбинация модов и точная настройка JVM. Это руководство дает проверенный набор действий: от установки Lithium и Starlight до конфигурации сборщика мусора Shenandoah. Каждый шаг протестирован на версиях 1.20+ и нацелен на стабильную работу сервера 24/7.

Оптимизация Fabric-сервера строится на трех китах. Первый - профильные моды, которые перерабатывают игровую логику, освещение и работу с памятью без изменения ванильной механики. Второй - корректные аргументы JVM, учитывающие объем RAM и версию Java. Третий - тонкая настройка server.properties и операционной системы. Пропуск любого из этих компонентов оставляет узкое место, которое проявится при росте онлайна или длительной работе без рестарта.

Материал ориентирован на администраторов, которые уже подняли сервер и хотят выжать из него максимум. Если вы только выбираете хостинг или ядро, начните с общего руководства по настройке сервера Minecraft. Здесь же разбираем специфику именно Fabric-сборок.

Содержание

• Почему Fabric-сервер требует оптимизации и как найти узкое место
• Как подготовиться к оптимизации Fabric-сервера
• Какие моды выбрать для оптимизации Fabric-сервера в 2026 году
• Как настроить JVM для максимальной производительности
• Как настроить server.properties и ядро ОС
• Как предотвратить деградацию производительности на длительных сессиях
• Часто задаваемые вопросы по оптимизации Fabric-сервера
• Чек-лист полной оптимизации Fabric-сервера

Почему Fabric-сервер требует оптимизации и как найти узкое место?

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

Типичные симптомы неоптимизированного Fabric-сервера:

• TPS опускается ниже 18 при 10-15 игроках онлайн
• MSPT (время обработки одного тика) превышает 50 мс - сервер не успевает обсчитать игровой цикл за отведенные 50 миллисекунд
• загрузка CPU держится на 100% одного ядра даже в простое
• после 6-8 часов работы TPS постепенно падает, хотя число игроков не меняется
• генерация новых чанков вызывает секундные фризы у всех подключенных клиентов

Корень этих проблем - в архитектуре Minecraft. Игра обрабатывает игровую логику в одном главном потоке. Моды добавляют сущности, блоки и механики, каждая из которых требует процессорного времени в этом же потоке. Fabric не решает эту проблему сам - он лишь предоставляет среду для запуска модов. Без профильных оптимизаций сервер с 50 модами работает медленнее, чем ванильный, даже если каждый мод по отдельности «легкий».

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

Как подготовиться к оптимизации Fabric-сервера?

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

Для честного сравнения проводите тесты на одном и том же мире, при сопоставимом числе игроков и одинаковом сценарии нагрузки. После каждого изменения сохраняйте значения TPS, MSPT, CPU и RAM, а не ориентируйтесь только на субъективное ощущение плавности.

Ключевые метрики для Fabric-сервера:

• TPS (Ticks Per Second) - частота обновления игрового мира. Норма - стабильные 20. Падение до 19 уже ощущается как микролаг, 15 и ниже - серьезная проблема.
• MSPT (Milliseconds Per Tick) - время, которое сервер тратит на обработку одного тика. Лимит - 50 мс. Значения выше означают, что сервер не укладывается в отведенный интервал и вынужден пропускать тики.
• Использование памяти - объем занятой heap-памяти и частота сборок мусора. Рост без возврата к прежним значениям указывает на утечку.

Как установить и использовать Spark для профилирования?

Spark - основной инструмент диагностики для Fabric. Это мод, который подключается к JVM и собирает детальную информацию о том, на что тратится процессорное время. Установка стандартная: скачайте jar-файл с Modrinth или CurseForge, поместите в папку mods, перезапустите сервер.

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

• /spark healthreport - выдает сводку по TPS, памяти и основным потребителям CPU за последние 5 минут. Запускайте эту команду первой при подозрении на лаги.
• /spark profiler --timeout 300 - запускает профилирование на 5 минут. По окончании вы получите ссылку на интерактивный отчет. В нем видно дерево вызовов методов с точностью до конкретного мода.
• /spark tickmonitor - показывает TPS и MSPT в реальном времени прямо в чате. Удобно для мониторинга во время тестовых нагрузок.

Интерпретация результатов проста. Откройте отчет профилировщика, отсортируйте по проценту использования CPU. Если первые строки занимают методы с именами модов - проблема в них. Если лидирует tick или entityTick - нагрузку создают сущности, и нужно разбираться с мобами и механизмами. Подробный разбор профилирования есть в руководстве по профилированию и мониторингу.

Перед любыми изменениями сделайте полный бэкап папки сервера. Оптимизационные моды редко ломают мир, но откат конфигурации - стандартная практика администратора.

Какие моды выбрать для оптимизации Fabric-сервера в 2026 году?

Ядро оптимизации Fabric-сервера - это набор из 5-6 модов, каждый из которых закрывает конкретную проблему. Они не конфликтуют друг с другом и вместе дают прирост производительности, зависящий от модпака, железа и характера нагрузки. Все перечисленные моды устанавливаются на сервер, не требуют установки на клиент и совместимы с Fabric API. Ниже перечислены лучшие моды для оптимизации 1.21 и совместимых сборок, но перед установкой нужно проверить версию каждого файла.

Lithium: оптимизация игровой логики без изменения поведения

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

Основные направления оптимизаций Lithium:

• AI мобов - сокращение частоты проверок пути, оптимизация поиска целей, уменьшение числа обращений к чанкам при навигации. На сервере с фермами мобов это снижает нагрузку на CPU на 20-30%.
• Физика и обновления блоков - объединение повторяющихся обновлений, отложенная обработка невидимых изменений, кэширование состояний. Особенно заметно при работе с большими редстоун-схемами.
• Генерация и загрузка чанков - сокращение аллокаций памяти, переиспользование объектов, оптимизация обхода чанков.

Lithium поставляется с файлом конфигурации lithium.properties. По умолчанию все оптимизации включены. Отключать отдельные опции стоит только при обнаружении несовместимости с конкретным модом - такие случаи единичны и документированы в issue-трекере проекта. Для большинства серверов оптимальна конфигурация «все включено».

Starlight: переработка движка освещения

Starlight полностью заменяет ванильный движок освещения. Авторы мода провели реверс-инжиниринг оригинального кода и переписали его с нуля, сохранив совместимость на уровне формата данных. Результат - генерация чанков ускоряется в 25-30 раз, а обновление освещения при установке или разрушении блока происходит практически мгновенно.

Сравнение с альтернативами. Phosphor - более старый мод с похожей целью, но он оптимизирует ванильный алгоритм, не меняя его структуру. Starlight же реализует собственный подход к распространению света, что дает радикально лучший результат. На серверах с активным строительством и терраформингом разница между Phosphor и Starlight достигает 10-15% по MSPT в пользу последнего. Если вы используете Phosphor по привычке - замените его на Starlight, конфликтов с Lithium нет.

Дополнительные моды: FerriteCore, Krypton, LazyDFU, Memory Leak Fix

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

FerriteCore снижает потребление оперативной памяти. Ванильный Minecraft агрессивно кэширует состояния блоков и чанков, создавая миллионы мелких объектов в heap. FerriteCore заменяет структуры данных на более компактные, сокращая расход RAM на 20-40%. На сервере с 8 ГБ выделенной памяти это освобождает 1.5-3 ГБ под полезную работу. Мод не влияет на производительность CPU и полностью прозрачен для игрового процесса.

Krypton оптимизирует сетевой стек. Minecraft использует Netty для обмена данными с клиентами, и ванильная реализация содержит несколько неоптимальных решений: избыточное сжатие пакетов, неэффективную сериализацию, лишние копирования данных. Krypton исправляет эти моменты, снижая задержки и нагрузку на CPU при передаче данных. Эффект заметен при онлайне от 20 человек, когда сетевой поток становится значимым потребителем ресурсов.

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

Memory Leak Fix - набор патчей для известных утечек памяти в ванильном коде и популярных модах. Утечки проявляются как постепенный рост потребления RAM без возврата к исходному уровню после сборки мусора. Через несколько часов это приводит к падению TPS и необходимости рестарта. Memory Leak Fix закрывает наиболее распространенные сценарии: утечки при смене измерений, при работе с кастомными рецептами, при использовании некоторых API модов.

Отдельно упомянем Sodium - это клиентский мод для оптимизации рендеринга. На сервер его ставить не нужно, но если ваши игроки тоже используют Fabric-клиент, рекомендовать им Sodium - хорошая практика. Он повышает FPS на стороне клиента в 2-5 раз и снижает нагрузку на видеокарту. В паре с серверными оптимизациями это дает плавный игровой опыт с обеих сторон.

Как настроить JVM для максимальной производительности?

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

Базовое правило для Minecraft: выделяйте достаточно памяти, но не слишком много. Оптимальный диапазон для Fabric-сервера с 20-50 модами и 10-30 игроками - 4-8 ГБ. Выделение 16 ГБ и более без необходимости вредит: сборщику мусора приходится обрабатывать огромную heap, что вызывает длинные паузы. Начинайте с 4 ГБ, мониторьте использование через Spark и увеличивайте только при реальной нехватке.

Как выбрать сборщик мусора: G1GC или Shenandoah?

Для Minecraft важны не пиковая пропускная способность GC, а минимальные паузы. Каждая пауза сборщика мусора длительностью более 10 мс - это потенциальный пропуск тика и рывок для игроков.

G1GC - сборщик по умолчанию в Java 17 и 21. Он делит heap на регионы и собирает мусор инкрементально, стараясь укладываться в заданную цель по паузе. Для Fabric-сервера с 4-6 ГБ памяти G1GC дает стабильные паузы в диапазоне 5-20 мс. Это приемлемо для большинства проектов. G1GC хорошо изучен, предсказуем и не требует специальной настройки кроме указания цели по паузе.

Shenandoah - сборщик с ultra-low паузами, доступный в сборках OpenJDK от Red Hat и некоторых других дистрибутивах. Он выполняет эвакуацию объектов параллельно с работой приложения, что снижает паузы до 1-5 мс даже на heap в 8-16 ГБ. Для крупных Fabric-серверов с высокими требованиями к плавности Shenandoah предпочтительнее. Недостаток - чуть более высокое потребление CPU в фоне и необходимость использовать совместимую сборку JDK.

Рекомендация для 2026 года: используйте Java 21 с Shenandoah, если ваш хостинг позволяет выбрать сборку JDK. Если нет - Java 21 с G1GC и флагом -XX:MaxGCPauseMillis=50 обеспечит хороший результат. Fabric и все перечисленные моды полностью совместимы с Java 21. Такая настройка Shenandoah для Minecraft требует проверки доступности сборщика в конкретной сборке JDK перед запуском.

Какие флаги JVM выбрать для сервера Fabric?

Готовая строка запуска для сервера с 6 ГБ памяти и Java 21:

java -Xms6G -Xmx6G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=iu -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=50 -XX:ConcGCThreads=2 -XX:ParallelGCThreads=3 -jar fabric-server.jar nogui

Пояснение ключевых параметров:

• -Xms6G -Xmx6G - начальный и максимальный размер heap одинаковы. Это исключает затраты на изменение размера heap во время работы и гарантирует, что память выделена сразу.
• -XX:+UseShenandoahGC - включает Shenandoah. Замените на -XX:+UseG1GC, если Shenandoah недоступен.
• -XX:+AlwaysPreTouch - при старте JVM физически выделяет все страницы памяти, а не резервирует их виртуально. Снижает задержки при первом обращении к памяти.
• -XX:+DisableExplicitGC - запрещает вызовы System.gc() из модов. Принудительная сборка мусора в Minecraft почти всегда вредит.
• -XX:MaxGCPauseMillis=50 - цель по максимальной паузе GC в миллисекундах. 50 мс - это один тик, допустимый компромисс.
• -XX:ConcGCThreads=2 -XX:ParallelGCThreads=3 - ограничение потоков GC. Рассчитывается как число ядер CPU минус 1-2 потока для основного процесса сервера.

Какие профили выбрать для малого сервера, высокого онлайна и слабого VPS?

Готовые параметры нужно воспринимать как стартовые профили, а не как универсальный результат. После изменения конфигурации проверьте MSPT и частоту сборок мусора через Spark.

• Малый сервер на 2-10 игроков: начните с Java 21, heap 4 ГБ, view-distance 8 и simulation-distance 6. Набор Lithium, FerriteCore и LazyDFU обычно закрывает базовые потребности. Starlight и Chunky особенно полезны, если игроки часто осваивают новые территории.
• Высокий онлайн: используйте 8-16 ГБ heap только при подтвержденной потребности, Shenandoah на совместимой сборке JDK, Krypton, view-distance 8 и simulation-distance 6-7. Отдельно контролируйте сущности, сетевую нагрузку и генерацию чанков.
• Слабый VPS с 2 ГБ RAM: оставьте часть памяти операционной системе и начните с heap 1536M, G1GC, view-distance 6 и simulation-distance 4-5. Уберите необязательные mods, заранее сгенерируйте мир и не рассчитывайте на стабильную работу тяжелого модпака.

Пример запуска для слабого VPS:

java -Xms1536M -Xmx1536M -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -jar fabric-server.jar nogui

Если heap регулярно заполняется, сначала уменьшите состав mods и дальность симуляции, а не добавляйте случайные JVM-флаги. При нехватке RAM на VPS важно оставить запас для Linux, файлового кэша и фоновых процессов.

Для серверов на VPS с ограниченными ресурсами хорошо показывает себя облачная инфраструктура с гибким масштабированием. Timeweb Cloud предоставляет VDS с быстрыми NVMe-дисками и возможностью увеличить ресурсы без переноса данных - это важно при росте онлайна.

Как настроить server.properties и ядро ОС?

Моды и JVM - это 80% результата. Оставшиеся 20% дает правильная конфигурация сервера и операционной системы. Эти настройки не требуют установки дополнительного ПО и занимают 10 минут.

Какие параметры server.properties влияют на производительность?

Два параметра, которые напрямую влияют на нагрузку CPU и RAM:

• view-distance - радиус прорисовки чанков, отправляемых клиенту. Значение 10 - стандарт для ванильного сервера. Для Fabric-сервера с оптимизациями рекомендуется 8. Это снижает число чанков, которые сервер должен держать в памяти и обрабатывать, на 36% (с 441 до 289 чанков на игрока). Игроки редко замечают разницу, особенно при использовании Sodium на клиенте.
• simulation-distance - радиус симуляции игровой логики: рост культур, движение мобов, работа механизмов. Рекомендуется 6-7. Снижение с 10 до 7 уменьшает область симуляции вдвое. Мобы за пределами этого радиуса не обсчитываются, что радикально снижает нагрузку от ферм и спавнеров.

Дополнительный параметр - network-compression-threshold. Определяет минимальный размер пакета, который будет сжат перед отправкой. Значение по умолчанию - 256 байт. Увеличение до 512 снижает нагрузку на CPU за счет уменьшения числа сжатий, но немного повышает сетевой трафик. На серверах с Krypton этот параметр менее критичен.

Для малого сервера начните со связки view-distance=8 и simulation-distance=6. На слабом VPS используйте 6 и 4-5 соответственно. При высоком онлайне не увеличивайте эти значения без замеров: каждый дополнительный чанк повышает требования к RAM, CPU и сети.

Рекомендации по ядру Linux. Переключите CPU governor в режим performance: echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. Это запрещает ядру снижать частоту процессора в простое и исключает задержки на «раскачку» при росте нагрузки. Для процесса сервера повысьте приоритет ввода-вывода: ionice -c 1 -n 0 -p $(pidof java). Это дает процессу Minecraft приоритетный доступ к диску, что важно при генерации и сохранении чанков. Детальный разбор оптимизации Linux-серверов есть в руководстве по настройке Linux для DevOps.

Как предотвратить деградацию производительности на длительных сессиях?

Сервер, который работает неделю без рестарта, почти гарантированно начнет терять TPS. Причины накопления проблем:

• утечки памяти в модах и ванильном коде - Memory Leak Fix закрывает известные, но не все возможные
• накопление сущностей - брошенные предметы, мобы в неактивных чанках, вагонетки и лодки, которые игроки оставили где попало
• фрагментация heap - даже без утечек память со временем фрагментируется, что замедляет аллокации

Как настроить автоматическую перезагрузку без потери данных?

Стратегия стабильной работы 24/7 включает автоматические рестарты с предупреждением. Настройте cron, systemd timer или планировщик панели так, чтобы раз в 12-24 часа запускался отдельный скрипт. За 5, 3 и 1 минуту отправьте игрокам предупреждение, затем выполните штатную команду stop, дождитесь завершения процесса и запустите службу снова. Для этого удобно использовать локальный RCON или встроенные средства панели; не открывайте RCON-порт в интернет без необходимости.

Пример последовательности для Linux с локальным RCON и службой systemd:

rcon-cli say Перезапуск через 5 минут
sleep 120
rcon-cli say Перезапуск через 3 минуты
sleep 120
rcon-cli say Перезапуск через 1 минуту
sleep 60
rcon-cli stop
sleep 10
systemctl start minecraft

Названия службы, параметры подключения и команду запуска замените на свои. Важно, чтобы сервер завершал работу через stop, а не принудительно через kill: так он успеет сохранить мир и закрыть файлы. Рестарт сбрасывает heap, очищает временные структуры и восстанавливает исходную производительность.

Второй компонент - контроль сущностей и генерации мира. Chunky позволяет заранее сгенерировать нужные чанки, чтобы исследование мира не создавало пиков нагрузки во время игры. Для очистки брошенных предметов и ограничения мобов используйте совместимый с вашей версией инструмент или отдельные правила сервера; проверяйте результат по Spark.

Третий компонент - мониторинг с алертами. Настройте Spark на экспорт метрик в Prometheus или используйте скрипт, который проверяет TPS раз в минуту и отправляет оповещение в Discord при падении ниже 18. Это позволит заметить деградацию до того, как начнут жаловаться игроки. Готовые схемы мониторинга описаны в статье по мониторингу серверов Minecraft.

Какие вопросы возникают при оптимизации Fabric-сервера?

Совместимы ли Lithium, Starlight и FerriteCore друг с другом?
Да. Эти моды разрабатываются с учетом совместного использования и не конфликтуют. Рекомендуется ставить все три плюс Krypton и Memory Leak Fix - это стандартный набор для Fabric-сервера в 2026 году.

Стоит ли переходить с Forge на Fabric ради производительности?
Если ваш сервер использует моды, которые есть в Fabric-версиях - однозначно да. Fabric легче, быстрее запускается и имеет более активное сообщество оптимизаторов. Если ключевые моды вашего проекта только под Forge - оставайтесь на Forge, но примените аналоги оптимизаций: Radium (аналог Lithium), Radon (аналог Starlight), FerriteCore (доступен для обоих загрузчиков).

Как тестировать изменения конфигурации без риска для основного мира?
Скопируйте папку сервера на локальную машину или отдельный VPS, запустите с теми же модами и конфигурацией. Используйте ботов или попросите 2-3 игроков создать нагрузку: летать в разные стороны для генерации чанков, ставить и ломать блоки, спавнить мобов. Сравните метрики Spark до и после изменений.

Нужно ли обновлять моды при смене версии Minecraft?
Обязательно. Каждая версия мода привязана к конкретной версии игры. Использование Lithium для 1.20.4 на сервере 1.21.1 приведет к крашу при старте или непредсказуемому поведению. Перед обновлением сервера проверьте наличие всех модов из вашего набора под целевую версию.

Влияет ли число модов на производительность, если все они «легкие»?
Влияет. Каждый мод добавляет код, который выполняется в главном потоке сервера. Даже если мод не делает ничего в фоне, он увеличивает время загрузки и потребление памяти. 50 «легких» модов создают заметную нагрузку просто за счет регистрации блоков, предметов и рецептов. Оптимизируйте не только код, но и состав модпака - удаляйте все, без чего можно обойтись.

Как устранить лаги при 10 игроках?
Сначала запустите /spark tickmonitor и определите, превышает ли MSPT 50 мс. Затем используйте /spark healthreport и пятиминутный /spark profiler. Если проблема появляется при исследовании мира, заранее обработайте территорию через Chunky и проверьте Starlight. Если нагрузка растет рядом с фермами или механизмами, уменьшите simulation-distance до 6-7 и найдите источник через entityTick. Не добавляйте новые mods, пока не определена причина.

Как поднять TPS на Fabric, если он падает ниже 20?
Ищите причину через MSPT, а не меняйте TPS напрямую. Установите Lithium и FerriteCore, проверьте, что не дублируются Starlight и Phosphor, настройте Java 21, view-distance 8 и simulation-distance 6-7. При длительной работе проверьте рост heap, утечки памяти и количество сущностей. После каждого изменения повторяйте один и тот же тест нагрузки.

Как настроить автоматическую перезагрузку?
Используйте cron, systemd timer или функцию планировщика хостинга. За 5, 3 и 1 минуту отправьте предупреждения через локальный RCON, затем выполните stop и запустите службу снова. Пример последовательности приведен в разделе об автоматической перезагрузке. Принудительное завершение процесса без сохранения мира использовать не следует.

Что делать на сервере с 2 ГБ RAM?
Оставьте запас памяти для Linux и выделите Minecraft примерно 1536M heap. Используйте Java 21 с G1GC, сократите view-distance до 6, simulation-distance до 4-5, заранее сгенерируйте мир через Chunky и оставьте только необходимые mods. Если Spark показывает постоянное заполнение heap или MSPT выше 50 мс, ограничение в 2 ГБ является узким местом, которое настройками полностью не устранить.

Совместим ли Fabric 1.21 с Java 21?
Да, при условии что конкретная версия Fabric Loader, Fabric API и каждого мода поддерживает целевую версию Minecraft. Перед обновлением проверьте зависимости и протестируйте сборку на копии мира. Для Java 21 выбирайте Shenandoah только если он доступен в вашей сборке JDK; в остальных случаях используйте G1GC.

Чек-лист полной оптимизации Fabric-сервера: 10 шагов

1. Сделайте полный бэкап мира, конфигураций и папки mods.
2. Зафиксируйте исходные значения TPS, MSPT, CPU, RAM и частоту GC.
3. Установите совместимые с вашей версией Minecraft Lithium, Starlight, FerriteCore и необходимые дополнительные mods.
4. Проверьте через Spark, какой мод, тип сущностей или операция создает нагрузку.
5. Установите Java 21 и выберите G1GC или Shenandoah после проверки доступности сборщика в JDK.
6. Настройте Xms и Xmx по реальному потреблению памяти, не отдавая Minecraft всю RAM VPS.
7. Установите view-distance 8 и simulation-distance 6-7, затем проверьте результат на реальном онлайне.
8. Заранее сгенерируйте востребованную территорию через Chunky, чтобы снизить пики при исследовании мира.
9. Проверьте CPU governor, дисковый приоритет и состояние NVMe-диска на Linux.
10. Настройте автоматические рестарты с предупреждениями и алерты Spark при падении TPS ниже 18.

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