Fabric-сервер Minecraft тормозит, TPS падает ниже 20, а игроки жалуются на лаги. Решение - в правильной комбинации модов и точной настройке JVM. Это руководство дает проверенный набор действий: от установки Lithium и Starlight до конфигурации сборщика мусора Shenandoah. Каждый шаг протестирован на версиях 1.20+ и нацелен на стабильную работу сервера 24/7.
Оптимизация Fabric-сервера строится на трех китах. Первый - профильные моды, которые перерабатывают игровую логику, освещение и работу с памятью без изменения ванильной механики. Второй - корректные аргументы JVM, учитывающие объем RAM и версию Java. Третий - тонкая настройка server.properties и операционной системы. Пропуск любого из этих компонентов оставляет узкое место, которое проявится при росте онлайна или длительной работе без рестарта.
Материал ориентирован на администраторов, которые уже подняли сервер и хотят выжать из него максимум. Если вы только выбираете хостинг или ядро, начните с общего руководства по настройке сервера Minecraft. Здесь же разбираем специфику именно Fabric-сборок.
Почему Fabric-сервер требует оптимизации: основные проблемы
Fabric заслуженно считается легковесным модлоадером. Его ядро минимально вмешивается в код игры, что дает высокую скорость загрузки и низкое потребление ресурсов на старте. Проблемы начинаются позже - их создают моды и сам игровой мир.
Типичные симптомы неоптимизированного Fabric-сервера:
- TPS опускается ниже 18 при 10-15 игроках онлайн
- MSPT (время обработки одного тика) превышает 50 мс - сервер не успевает обсчитать игровой цикл за отведенные 50 миллисекунд
- загрузка CPU держится на 100% одного ядра даже в простое
- после 6-8 часов работы TPS постепенно падает, хотя число игроков не меняется
- генерация новых чанков вызывает секундные фризы у всех подключенных клиентов
Корень этих проблем - в архитектуре Minecraft. Игра обрабатывает игровую логику в одном главном потоке. Моды добавляют сущности, блоки и механики, каждая из которых требует процессорного времени в этом же потоке. Fabric не решает эту проблему сам - он лишь предоставляет среду для запуска модов. Без профильных оптимизаций сервер с 50 модами работает медленнее, чем ванильный, даже если каждый мод по отдельности «легкий».
Особая статья - освещение. Ванильный движок освещения выполняет избыточные пересчеты при каждом изменении блока. На сервере с активной застройкой это создает постоянную фоновую нагрузку. Starlight решает эту проблему радикально, но об этом позже.
Подготовка к оптимизации: что нужно знать перед началом
Оптимизация без замеров - стрельба вслепую. Прежде чем менять конфигурацию, зафиксируйте текущие метрики. Это даст точку отсчета и покажет, какие именно изменения принесли эффект.
Ключевые метрики для 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 модов, каждый из которых закрывает конкретную проблему. Они не конфликтуют друг с другом и вместе дают прирост производительности в 2-4 раза по сравнению с сервером без оптимизаций. Все перечисленные моды устанавливаются на сервер, не требуют установки на клиент и совместимы с Fabric API.
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.
Оптимальные флаги 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 с ограниченными ресурсами хорошо показывает себя облачная инфраструктура с гибким масштабированием. 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 этот параметр менее критичен.
Рекомендации по ядру 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 включает три компонента. Первый - автоматические рестарты с предупреждением. Настройте скрипт, который раз в 12-24 часа оповещает игроков о перезагрузке за 5, 3 и 1 минуту, затем корректно останавливает и запускает сервер. Это сбрасывает heap, очищает временные структуры и восстанавливает исходную производительность.
Второй - очистка сущностей. Fabric-моды вроде Chunky позволяют задать лимиты на число мобов и предметов в чанке, автоматически удаляя избыточные. Настройте удаление брошенных предметов старше 5 минут и ограничение числа мобов одного типа в радиусе симуляции.
Третий - мониторинг с алертами. Настройте 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 «легких» модов создают заметную нагрузку просто за счет регистрации блоков, предметов и рецептов. Оптимизируйте не только код, но и состав модпака - удаляйте все, без чего можно обойтись.