Туториал Оптимизация SPIGOT - убираем лаги, стабилизируем TPS и повышаем производительность!

Disclaimer: ​

• Я не оказываю помощи в настройке и оптимизации серверов. ​
• Все изменения вы делаете на свой страх и риск. ​
• Данная статья является конечной в оптимизации сервера, если вы имеете нестабильную сборку, в конфиги ядра лезть бессмысленно.​
• Тема является сборной солянкой общедоступной на US форумах информации. ​
• Перед прочтением рекомендую ознакомится с данной статьей.​
• Да пребудет с вами сила

Оптимизация сервера​

Вот подробное руководство по оптимизации вашего сервера!
Имейте в виду, для оптимизации и стабилизации сервера стоит использовать инструмент Spigot Timings собирая статистику при максимальной нагрузке на сервер.

Информацию для статьи взял с форума Spigot


1. PaperSpigot & paper.yml
PaperSpigot представляет собой набор патчей для ядра Spigot которые существенно оптимизирует сервер и добавляет дополнительные настройки с помощью файла paper.yml.

Запустите paperspigot.jar, как вы это делаете с обычным ядром spigot.jar (собственно PaperSpigot и является ядром сервера) .
После запуска, сервера сгенерирует в корневой папке три yaml файла:

• spigot.yml
• paper.yml
• bukkit.yml

Используя эти файлы мы и будем вести настройку.

Для начала откройте paper.yml:

Следует снизить параметр despawn-ranges, если у вас слишком много мобов (в противном случае оставьте это по умолчанию).

Измените значение на true следующих параметров:

use-async-lighting
optimize-draining

Это позволит оптимизировать параметры потока жидкости и обрабатывать освещение асинхронно.

Примечание: Некоторые из этих параметров были вырезаны в paperspigot, в более поздних версиях и больше не настраиваются в конфигурационном файле (как они всегда активированы).


Если у вас на сервере совершается много действий с redstone схемами, воронками, вагонетками... еtс , снижение параметра tick-next-tick-list-cap может помочь в повышении производительности.



2. Spigot.yml & Bukkit.yml

Spigot.yml & bukkit.yml являются файлами, которые генерирует сервер Bukkit/Spigot умолчанию. Они позволяют нам настроить такие параметры как: лимит сущностей(entity), кол-во сущностей(entity) за тик, обработку мира и другое.

Откройте spigot.yml. Здесь мы сможем выжать максимум производительности из сервера. Найдите раздел "world-settings".

Во-первых, отключите анти-Xray, если вы действительно им не пользуетесь. Обычно данная функция аказывает до 5% нагрузки на сервер. Это не самый прожорливый функционал, но его отключение может дать серьезный прирост производительности.
Вы можете попробовать в качестве альтернативы более конфигурируемый анти-Xray, например.

Параметр: nerf-spawner-mobs может быть установлен на true, если ваш сервер не полагаться на агрессивных мобов, которые появляются с помощью спаунеров. Если у вас есть много спаунеров нейтральных мобов (фермы и тд) и вы редко используете спаунеры агрессивных, активация этой функции даст серьезное увеличение производительности.

entity-activation-range
Стандартные значения:(animals: 32, monsters: 32, misc: 16)
Описание: Устанавливает радиус в блоках, в пределах которых сущности будут "активными" - объекты за пределами этого диапазона будет тикать по сниженному рейту, чтобы предотвратить сервера отставание.
Я предлагаю использовать такие параметры:

Код:

entity-activation-range:
animals: 8
monsters: 10
misc: 2

Misc регулирует радиус элементов рам, картин, выброшенных предметов, шаров опыта и табличек. Я установил этому параметру значение "2", для предотвращения их движения по воде. Параметры animals: 8 monsters: 10 не означают что мобы будут выгружены, они будут активны(за один тик), но с более низким рейтом (читаем подробнее, что такое тик).

entity-tracking-range
Стандартные значения:(players: 48, animals: 48, monsters: 48, misc: 32, other: 64)

Устанавливает радиус в блоках, в пределах которых сущности будут видимыми для клиента. Субъекты за пределами этого диапазона будут невидимы и не будут обработаны железом клиента чтобы сохранить загрузку процессора и пропускную способность. Это особенно полезно для ПВП серверов, а снижение параметров для игроков исключит wallhacks и радар в некоторой степени. Misc регулирует радиус элементов рам, картин, выброшенных предметов, шаров опыта и табличек. Other устанавливает максимальный предел для всех субъектов на вашем сервере.

entity-tracking-range: не влияет на производительность сервера, но влияет производительность на стороне клиента. Я хотел бы предложить оставить его нетронутым.

Код:

entity-tracking-range:
players: 48
animals: 48
monsters: 48
misc: 32
other: 64

ticks-per:
↳ hopper-transfer
Стандартное значение: 8
Описание: Период времени в 1 тик, между тем как воронка активируется и перетянет вещи в сундук. При стандартном значении воронка активируется и перетаскивает в сундук предметы раз в 8 тиков.

↳ hopper-check (Удалено в версии 1.8.3 March, 8th 2015)
Стандартное значение: 8
Описание: Период времени в 1 тик, - за который воронка анализирует кол-во предметов вокруг нее. К примеру при значении 8, воронка будет проверять инвентарь сундука и наличие предметов вокруг нее раз в восемь тиков.

Значение по умолчанию равно 8, поэтому установка его в 24 означает, что процесс активации будет происходить в три раза реже. Что сократит общее время активности воронок. (внимание изменение данной функции может привести к неправильной работе некоторых механизмов, которые строят ваши игроки)

Я советую установить вот такие значения:

Код:

ticks-per:
hopper-transfer: 24
hopper-check: 24
hopper-amount: 3

max-entity-collisions
Стандартное значение: 8
Описание: Данный параметр устанавливает лимит сущностей в одной точке, я предлагаю установить значение 2 или даже 1.

item-despawn-rate
Стандартное значение: 6000
Описание:Данный параметр устанавливает время в тиках, по прошествии которого брошенные на землю предметы исчезнут.

При стандартном значении предметы будут исчезать через 6000:20=300 секунд. Данный параметр регулируется индивидуально для каждого сервера.

merge-radius:
↳ exp
Стандартное значение: 3.0
Описание: Устанавливает радиус в блоках, когда шарики опыта будут объединены в один стак.

↳ item
Стандартное значение: 2.5
Описание: Устанавливает радиус в блоках, когда предметы одной группы будут объединены в один стак.

Предлагаю вот такие параметры:

Код:

merge-radius:
item: 4
exp: 6

view-distance
Стандартное значение: 10
Описание:Контролирует количество блоков, которые будут загружены вокруг каждого игрока. Это значение не может быть выше , чем 15 или ниже , чем 1. Понижение это может снизить нагрузку на сервер , если у вас есть большое количество игроков онлайн.

Я советую установить данный параметр на "4", но в таком случае могут возникнуть проблемы при прогрузке блоков для креатив серверов. Все же лучше не выходить за значение "6". Данный параметр оказывает значительную нагрузку на сервер



chunks-per-tick
Стандартное значение: 650
Описание:Контролирует количество чанков, которые будут обновлены для роста культур(фермерам на заметку) за один тик . Снижение этого параметра уменьшает нагрузку на сервер и замедляет рост культур соответственно. Я предлагаю установить значение "80" что примерно в восемь раз ниже.

growth:
↳ x-модификатор
где x это = cactus, melon, pumpkin, sapling, cane, mushroom, wheat
Стандартное значение: 100
Type: Integer
Описание: Контролирует скорость роста определенной культуры.
При снижении параметра chunks-per-tick в восемь раз до 80, мы увеличим значения роста каждой культуры до "800" ( восемь раз соответственно) что даст нам стандартную скорость роста, при этом сократив кол-во обновленных чанков.

Устанавливаем параметры на:

Код:

growth:
cactus-modifier: 800
cane-modifier: 800
melon-modifier: 800
mushroom-modifier: 800
pumpkin-modifier: 800
sapling-modifier: 800
wheat-modifier: 800

Помните, что параметры chunks-per-tick и growth взаимосвязаны и если вы уменьшили кол-во обновленных чанков, при этом оставив без изменения параметр growth(100) то вы снизите скорость роста в восемь раз и наоборот.

Переходим к файлу bukkit.yml​

Параметр spawn-limits. Отвечает за общее кол-во мобов, которые будут отспаунены для одного игрока. Я предлагаю такие значения:

Код:

spawn-limits:
monsters: 50
animals: 10
water-animals: 3
ambient: 4

Я снизил параметр ambient: 4, тк. Кол-во летучишь мышей никак не влияет на геймплей.
Чем больше игроков играют на сервере, тем ниже можно опускать данные значения повышая при этом производительность сервера.

Также рекомендую установить значения параметра ticks-per:

Код:

ticks-per:
animal-spawns:400
monster-spawns: 3
autosave: 3000

В частности, я изменил monster-spawns с 1 до 3. Это интервал между событием mobSpawn , который будет определять места и порождать монстров . Если mobSpawn собирает много циклов в ваших таймингах советую увеличить данные значения!

chunk-gc это небольшая функция spigot которая отключена по умолчанию. Для включения, установите параметры:

Код:

chunk-gc:
period-in-ticks: 300
load-threshold: 300

Java и скрипт запуска​

Данный скрипт написан придерживаясь последней версии Java, если вы по какой то причине используете 7 (-) версию, добавьте к скрипту запуска параметр XX:MaxPermSize=128M .

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

Код:

java -Xmx8G -Xms8G -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=50 -XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1MixedGCLiveThresholdPercent=50 -XX:+AggressiveOpts -jar имя_ядра.jar

Описание флагов:

Спойлер: Описание флагов:

-Xmx<n>G
<n> = Максимальное значение выделенной памяти для сервера MineCraft. (Никогда не устанавливайте максимально доступный параметр, оставляйте ресурс для работы вашей системы.
-Xms<n>G
<n> =
Память, выделенная для старта сервера в гигабайтах.
Этот параметр устанавливает объем памяти, который будет выделен(занят) при старте игрового сервера. При использовании G1 сборщика мусора (а мы используем в этом скрипте именно его), параметр должен быть таким же что и Xmx.

-XX:+AlwaysPreTouch
Это говорит Java, как распределить объем памяти, которую мы задали параметром Xmx, и заполнить ее нулями, так что правильно инициализировать (экономия ресурса процессора в первые пару часов жизни сервера)

-XX:+DisableExplicitGC
Это отключает вызов GC плагинами. Мы используем собственный GC, так что давайте его отключим.

-XX:UseG1GC
Этот параметр активирует сборщик мусораG1. По умолчанию сборщик мусора не предназначены для постоянной работы. Например, веб-сервер не будет иметь никаких проблем при задержке каждые 200 мс между запросами, чтобы сделать сбор мусора. А Minecraft сервер постоянно выполняет работу. К счастью, специально для таких случаев существует G1GC. Тем не менее, мы можем настроить GC более тонко, используя некоторые флаги (которые находятся в скрипте после активации G1GC). Я советую прочитать пост Aikar's для правильного понимания того, как они работают.

 

Спасибо
Информативно, самое то

 

Полезно

 

Годно, спасибо

 

Бесполезная "оптимизация". На деле, от этих "оптимизаций" только больше лагает.
Отсюда можно взять только снижение view-distance и отключение anti-xray — это действительно помогает.
Spigot и так оптимизированное ядро, PaperSpigot тем более.
ТС забыл указать первоисточник статьи, которую он перевел с английского.
По поводу аргументов для запуска, большинство из данных аргументов уже встроены в Java 8.

 

Если указываете на бесполезность статьи приводите пожалуйста аргументы. Какой конкретно параметр вас не устраивает. Не путайте оптимизацию сервера (под железо и условия работы, которые существенно отличаются) и стабильность ядра. Данные параметры повышают производительность сервера, но так же оказывают значительное влияние на баланс игры.
Если же это исключительно ваше имхо, прошу не расписывать его в такой категоричной манере.
В шапке есть пометка откуда взята информация. Сейчас прикрепил ссылку.
Дайте пожалуйста разъяснение по поводу "флагов, большинство из которых уже встроены в Java 8."

 

Автор указал все правильно. Все эти настройки действительно немного расслабят сервер, не нужно тут ля-ля.

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

 

Аргументы запуска в своем большинстве не нужны, за исключением -Xmn/выбора сборщика мусора. Дело в том, что без них может работать даже лучше. Аргументы нужно ставить только в том случаи, если вам нужно экспериментировать с производительностью сервера.

Из настроек, скажу, что самыми эффективными являются view-distance, use-async-lightning, chunk-gc, max-bulk-chunks.

 

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

В шапке топика есть пометка:
Данная статья является конечной в оптимизации сервера, если вы имеете нестабильную сборку, в конфиги ядра лезть бессмысленно.
Данные аргументы и используются для запуска G1GC. Сообщение Aikar на эту тему с описанием флагов.
Все параметры, что приведены выше являются действенными в снижении нагрузки на сервер. Вопрос в другом, чем именно сервер загружен? Активация энити, кол-во энити, etc. Я приводил пример работы с таймингами, от них и пляшем.

 

Какой параметр отвечает за работу механизмов? Если стоять в чанке с механизмом, то он работает быстро, как и должен. Но если выйти хотя бы за блок в другой чанк, то он работает по сниженному тикрейту.

 

Много чего уже знал, но спасибо

 

Можно снизить кап тиков. Но в корне это не решит проблему (точнее решение будет через чур глобальным) . Хотя и снизит нагрузку при большом кол-ве механизмов.
Конфиг paper.yml

Код:

 tick-next-tick-list-cap: 10000 # Maximum cap of tickables (Don't touch me unless you know what you're doing)
tick-next-tick-list-cap-ignores-redstone: false # Should the above cap ignore redstone (Always tick redstone)

Реализация плагином:
К примеру

 

Под механизмами я имел ввиду всяческие машины из модов, а данные настройки подходят только к редстоун-механизмам

 

Я подумал именно про механизмы из редстоуна. По поводу модов у меня нет ответа. Никогда с подобным не сталкивался).

 

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

 

Еще раз повторюсь. Это руководство не призывает к действию, а лишь описывает возможные рычаги оптимизации ядра. Если вы имеете стабильную работу сервера не стоит лезть в конфиги ( зачем придумывать велосипед и лезть туда, что и без вас работает отлично)

Если проблема проявилась после настройки конфига стоит обратить внимание на параметры работы Entity. Возможно мод завязан на частицы, а в конфиге мы меняем радиус активации, соединение, время активации (в случае воронок)

 

Код:

java -Xmx8G -Xms8G -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=50 -XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:InitiatingHeapOccupancyPercent=10 -XX:G1MixedGCLiveThresholdPercent=50 -XX:+AggressiveOpts -jar имя_ядра.jar

Я с этим батником запустил, у меня комп вырубился, в защиту ушел от перегрева, загрузка цп стала 800% Охеренный оптимизатор ))).

 

Снизь количество выделенной оперативной памяти в параметрах -Xmx -Xms. Например, -Xmx1G -Xms1G.

 

На лицо явные проблемы с пониманием происходящего.

 

Ну-ка объясни? Я готов выслушать конструктивный ответ понимающего человека по поводу происходящего. Или балабол?