Производительность сервера Minecraft измеряется в TPS (тиках в секунду). Норма - стабильные 20 TPS. Если показатель падает до 15 и ниже, игроки чувствуют задержки: блоки перестают разрушаться с первого раза, мобы двигаются рывками. Эта статья - набор проверенных действий для возврата 20 TPS. Мы разберем диагностику узких мест, выбор ядра, параметры server.properties, JVM-аргументы и предгенерацию мира. Каждый раздел содержит конкретные цифры и команды, которые можно применить сразу.
Главный принцип: не применять все настройки подряд. Сначала замерьте TPS и MSPT (миллисекунды на тик), найдите причину лагов и только потом вносите изменения. Инструменты для диагностики - Spark и встроенные команды ядра - описаны в первом разделе. Если вам нужен более глубокий разбор профилирования, обратитесь к руководству по профилированию и устранению лагов.
С чего начать оптимизацию: диагностика узких мест
Перед любыми изменениями зафиксируйте текущие метрики. Без этого вы не узнаете, какое действие дало эффект, а какое - нет. Две ключевые метрики: TPS и MSPT. TPS показывает, сколько игровых тиков сервер обрабатывает за секунду. MSPT - сколько миллисекунд занял последний тик. При 20 TPS один тик длится 50 мс. Если MSPT превышает 50 мс, TPS падает.
Проверьте TPS командой /tps (доступна на Paper, Purpur и их форках). Вывод покажет TPS за последние 5, 10 и 15 минут. Пример нормального вывода: TPS from last 1m, 5m, 15m: 20.0, 20.0, 20.0. Проблемный вывод: TPS from last 1m, 5m, 15m: 16.2, 17.8, 19.1. Падение в минутном интервале при нормальных 15-минутных значениях указывает на недавнюю вспышку нагрузки - например, массовую генерацию чанков или взрыв большого количества TNT.
MSPT смотрите командой /mspt. Значение ниже 40 мс - запас прочности есть. 40-50 мс - сервер на границе возможностей. Выше 50 мс - TPS уже падает. Если MSPT скачет от 20 до 80 мс, проблема в периодических тяжелых операциях - например, сборке мусора Java или загрузке чанков.
Для детального анализа установите плагин Spark. Команда /spark profiler start запускает профилировщик, который покажет, какие методы и плагины потребляют больше всего процессорного времени. Через 5-10 минут выполните /spark profiler stop и откройте ссылку на отчет. В отчете ищите методы с долей потребления CPU выше 5%. Подробная инструкция по Spark есть в нашем гайде по мониторингу серверов.
Типичные проблемные показатели: TPS падает при подключении новых игроков - вероятно, проблема в загрузке чанков. TPS падает равномерно со временем - возможна утечка памяти или накопление сущностей. MSPT резко подскакивает раз в несколько минут - смотрите настройки сборщика мусора.
Выбор ядра сервера: Paper, Purpur или Airplane?
Ядро сервера определяет, какие оптимизации доступны и насколько эффективно используется железо. Vanilla-ядро от Mojang не имеет встроенных оптимизаций и не рекомендуется для серверов с количеством игроков больше пяти. Форки решают эту проблему.
Paper - стандарт для большинства серверов
Paper - форк Spigot с сотнями встроенных патчей производительности. Он оптимизирует обработку сущностей, генерацию чанков, работу с редстоуном и спавн мобов. Paper сохраняет полную совместимость с плагинами Bukkit/Spigot. Сообщество активно обновляет ядро под новые версии Minecraft в течение нескольких дней после их выхода. Для 90% серверов Paper - оптимальный выбор. Установка сводится к замене jar-файла: скачайте последнюю сборку с официального сайта PaperMC и замените им ваш серверный jar.
Paper добавляет команду /timings - встроенный аналог Spark для быстрой диагностики. После выполнения /timings report вы получите ссылку с детализацией потребления CPU по плагинам и игровым механикам. Это первый инструмент, который стоит использовать при падении TPS на Paper-сервере.
Purpur - расширенные возможности настройки
Purpur - форк Paper с дополнительными оптимизациями и настройками. Его ключевое преимущество - файл purpur.yml, который позволяет отключать отдельные игровые механики без плагинов. Например, можно отключить спавн конкретных мобов, изменить алгоритм роста бамбука или запретить странникам Края подниматься на блоках. Каждая отключенная механика снижает нагрузку на CPU.
Purpur включает встроенную поддержку Pterodactyl - панели управления серверами. Если вы используете Pterodactyl, Purpur упрощает развертывание. Переход с Paper на Purpur безопасен: все плагины и конфигурации сохраняются. Скачайте jar с сайта PurpurMC и замените файл ядра. После первого запуска появится purpur.yml с десятками опций для тонкой настройки.
Airplane - еще один форк, ориентированный на максимальную производительность для крупных серверов (100+ игроков). Он оптимизирует обработку сущностей и сетевые потоки, но развивается медленнее Paper и Purpur. Для большинства проектов разница между Purpur и Airplane незаметна, а совместимость с плагинами у Purpur выше.
Рекомендация: начните с Paper. Если нужно отключать конкретные механики или вы используете Pterodactyl - переходите на Purpur. Airplane рассматривайте только при онлайне выше 100 игроков и после тестирования совместимости с вашими плагинами.
Тонкая настройка server.properties
Файл server.properties содержит параметры, напрямую влияющие на нагрузку CPU и сетевой трафик. Три настройки критичны для производительности: simulation-distance, view-distance и network-compression-threshold.
Симуляционная дистанция (simulation-distance) и дистанция обзора (view-distance)
View-distance определяет радиус отправки чанков игроку - то, что он видит. Simulation-distance - радиус, в котором сервер обрабатывает поведение сущностей: движение мобов, рост растений, работу механизмов. Это разные параметры, и simulation-distance сильнее влияет на TPS, потому что обработка сущностей требует CPU.
При simulation-distance=10 сервер обрабатывает сущности в радиусе 10 чанков вокруг каждого игрока. Это 441 чанк на игрока. При simulation-distance=6 - 169 чанков. Разница в нагрузке почти трехкратная. Для серверов выживания с 20-30 игроками устанавливайте simulation-distance=6 или 8. Для мини-игр и PvP-арен, где важна реакция, а не симуляция мира - 4 или 5. View-distance можно оставить на 8-10: отправка чанков нагружает сеть и память, но не процессор так сильно, как симуляция.
Пример конфигурации для сервера выживания на 30 игроков:
view-distance=10
simulation-distance=6Для мини-игр (BedWars, SkyWars) с 50+ игроками:
view-distance=8
simulation-distance=4Сетевое сжатие (network-compression-threshold)
Этот параметр определяет минимальный размер пакета в байтах, который сервер будет сжимать перед отправкой игроку. Сжатие снижает сетевой трафик, но нагружает процессор. При значении 0 сервер сжимает все пакеты - максимальная нагрузка на CPU. При значении -1 сжатие отключено - максимальный трафик, но нулевая нагрузка на CPU от сжатия.
Значение 256 - компромисс для большинства серверов. Пакеты меньше 256 байт (движение игрока, небольшие изменения блоков) не сжимаются. Пакеты больше 256 байт (загрузка чанков, обновления инвентаря) сжимаются, экономя трафик. Если у вас мощный процессор и ограниченный канал - уменьшите до 128. Если процессор слабый, а канал широкий - увеличьте до 512 или отключите сжатие (-1).
Рекомендуемое значение для старта: network-compression-threshold=256. Изменяйте только после замеров нагрузки на CPU и сеть.
JVM-аргументы: настройка памяти и сборщика мусора
Java Virtual Machine обрабатывает весь код сервера. Неправильные аргументы запуска JVM - частая причина лагов даже на мощном железе. Два критичных параметра: объем выделяемой памяти и алгоритм сборки мусора.
Правило выделения RAM: не более 10-12 ГБ на сервер Minecraft. При больших объемах сборщик мусора G1GC начинает работать дольше, вызывая заметные паузы. Если серверу требуется больше 12 ГБ, проблема в оптимизации, а не в нехватке памяти. Для 20-30 игроков достаточно 4-6 ГБ. Для 50+ - 8-10 ГБ. Всегда оставляйте 1-2 ГБ операционной системе: на машине с 16 ГБ выделяйте серверу не более 14 ГБ.
Использование Aikar's Flags Generator
Aikar's Flags - набор JVM-аргументов, разработанный администратором крупных серверов Айкаром. Они оптимизируют работу G1GC, настраивают размеры поколений памяти и устанавливают разумные таймауты. Генератор доступен онлайн: вы указываете объем RAM, тип сервера и версию Java, получаете готовую строку аргументов.
Пример сгенерированных флагов для сервера с 8 ГБ RAM и Java 21:
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:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -jar server.jar noguiСкопируйте вывод генератора в ваш стартовый скрипт. Убедитесь, что -Xms и -Xmx равны - это предотвращает ресайзинг кучи, который вызывает дополнительные паузы. Флаги обновляются под новые версии Java: для Java 21 используются одни параметры, для Java 17 - другие. Генератор учитывает это автоматически.
Ручная настройка для продвинутых пользователей
Ключевые параметры G1GC, которые стоит понимать:
-Xmsи-Xmx- начальный и максимальный размер кучи. Всегда устанавливайте одинаковыми.MaxGCPauseMillis=200- целевая максимальная пауза сборки мусора в миллисекундах. 200 мс - разумный баланс: сборщик старается не превышать это время, но при значении ниже 100 мс он будет запускаться чаще и потреблять больше CPU.InitiatingHeapOccupancyPercent=15- процент заполнения кучи, при котором запускается сборка мусора. Низкое значение (15 вместо стандартных 45) заставляет сборщик начинать работу раньше, уменьшая длительность пауз.G1NewSizePercent=30иG1MaxNewSizePercent=40- размер молодого поколения. Minecraft создает много короткоживущих объектов, поэтому молодое поколение должно быть достаточно большим.
Не используйте случайные флаги из интернета. Аргументы для Java 8 не работают на Java 21 и могут ухудшить производительность. Если не хотите разбираться в деталях - используйте Aikar's Flags Generator, это проверенное решение.
Предгенерация мира: снижаем нагрузку при исследовании
Генерация новых чанков в реальном времени - одна из самых тяжелых операций для сервера. Когда игрок летит на элитрах или бежит по новым территориям, сервер вынужден генерировать десятки чанков в секунду. TPS падает, MSPT зашкаливает. Решение - предгенерация: вы заранее создаете все чанки в заданном радиусе, и при исследовании игроками сервер только загружает готовые данные с диска.
Использование плагина Chunky
Chunky - плагин для Paper и Purpur, который предгенерирует мир в фоне, не мешая игре. Установите плагин, поместив jar-файл в папку plugins, и перезапустите сервер.
Базовая последовательность команд:
chunky world world
chunky radius 5000
chunky startПервая команда выбирает мир для предгенерации (обычно «world»). Вторая устанавливает радиус в блоках - 5000 блоков создаст квадрат 10000×10000, достаточно для большинства серверов выживания. Третья запускает процесс. Проверяйте прогресс командой chunky progress. Для радиуса 5000 на современном процессоре процесс занимает 2-4 часа.
Важные параметры:
chunky shape square- квадратная форма (по умолчанию), быстрее для предгенерации.chunky shape circle- круглая форма, естественнее для игрового мира.chunky center 0 0- установка центра предгенерации (по умолчанию 0,0 - спавн).
Альтернатива Chunky - плагин WorldBorder. Он также предгенерирует чанки, но дополнительно устанавливает физическую границу мира, за которую игроки не могут выйти. Команда для предгенерации с WorldBorder: wb world fill 1000 208 1, где 1000 - радиус, 208 - частота проверки чанков, 1 - количество потоков. Процесс идет медленнее, чем в Chunky, но граница мира может быть полезна для контроля размера карты.
Предгенерация особенно важна для серверов с модами, где генерация одного чанка может занимать сотни миллисекунд из-за модовых структур и биомов. Если вы используете Fabric-сервер с модами, посмотрите руководство по оптимизации Fabric, где разобраны специфичные для модов настройки.
Выбор хостинга и аппаратного обеспечения
Minecraft-сервер критичен к однопоточной производительности процессора. Основной игровой цикл выполняется в одном потоке, и его скорость определяет максимальный TPS. Многоядерность помогает распределять второстепенные задачи - сетевые потоки, работу плагинов, загрузку чанков, но не ускоряет главный цикл напрямую.
Рекомендуемые процессоры на 2026 год: AMD Ryzen 9 7950X (высокая тактовая частота, 5.7 ГГц в бусте), Intel Core i9-13900K (5.8 ГГц), AMD Ryzen 7 7800X3D (большой кэш L3 ускоряет работу Java). Серверные процессоры Xeon и EPYC с низкой тактовой частотой (2.0-2.5 ГГц) хуже подходят для Minecraft, чем десктопные с частотой выше 4.5 ГГц.
Ориентиры по RAM:
- 10-20 игроков, ванильный или с легкими плагинами: 4 ГБ.
- 20-50 игроков, 20-30 плагинов: 6-8 ГБ.
- 50+ игроков, модовые сборки: 8-12 ГБ.
Дисковая подсистема: NVMe-накопитель обязателен. Загрузка и сохранение чанков - операции с произвольным доступом, и SATA SSD создает задержки при активном исследовании мира. Размер карты после предгенерации радиуса 5000 составляет 2-5 ГБ в зависимости от количества измерений. Для крупных проектов закладывайте 20-30 ГБ свободного места.
При выборе хостинг-провайдера обращайте внимание на тип виртуализации. OpenVZ и LXC делят ядро с другими контейнерами и не подходят для Minecraft из-за нестабильной производительности. KVM и выделенные серверы обеспечивают изолированные ресурсы. Если вы ищете облачную инфраструктуру с гибким масштабированием, Timeweb Cloud предоставляет VDS и выделенные серверы с подходящей для Minecraft конфигурацией.
Мониторинг и поддержание производительности
Оптимизация - не разовое действие. Нагрузка меняется с ростом онлайна, установкой новых плагинов и обновлением версий игры. Настройте постоянный мониторинг, чтобы замечать деградацию производительности до того, как ее почувствуют игроки.
Минимальный набор инструментов:
- Spark с настроенным автоматическим профилированием. Команда
/spark profiler start --timeout 600запускает 10-минутный замер и автоматически сохраняет отчет. - Встроенные команды
/tpsи/msptдля быстрой проверки при подозрениях на лаги. - Timings от Paper (
/timings report) для анализа потребления CPU плагинами.
Настройте алерты при падении TPS. Плагины вроде Plan или интеграция Spark с Discord-вебхуками отправляют уведомления, когда TPS опускается ниже заданного порога (например, 18). Это позволяет реагировать на проблемы проактивно. Подробная настройка мониторинга и интеграция с Prometheus и Zabbix описаны в руководстве по профилированию и мониторингу.
Раз в месяц проводите ревизию: проверяйте отчеты Spark за длительный период, ищите плагины с растущим потреблением CPU, анализируйте количество сущностей в мире. Скопление брошенных предметов, бесконтрольное размножение мобов на фермах, забытые механизмы - все это постепенно снижает TPS. Профилактика дешевле экстренной оптимизации в час пик.
Применяйте настройки из этого руководства последовательно: диагностика, выбор ядра, параметры server.properties, JVM-аргументы, предгенерация. После каждого изменения замеряйте TPS и MSPT. Документируйте, какое действие дало прирост производительности - это сэкономит время при настройке следующего сервера или обновлении текущего.