⚡ Современная оптимизация современных серверов

⚡ Современная оптимизация современных серверов

Обзор Обновления (27) Рецензии (51) Обсуждение
Как выключить поддержку мобов из 1.20 на 1.19.4?
 
А если у меня на 1.20.1 вот такой маленький конфиг пурпура это нормально? Тут нужно добавлять что-то вручную? Или этих оптимизаций просто пока не завезли на эту версию? Использую платное ядро ssspigot
Вам необходимо зарегистрироваться для просмотра изображений-вложений
 
Sephiroth написал(а):
А если у меня на 1.20.1 вот такой маленький конфиг пурпура это нормально? Тут нужно добавлять что-то вручную? Или этих оптимизаций просто пока не завезли на эту версию? Использую платное ядро ssspigot
Нажмите для раскрытия...
у меня на дефолт пурпуре всё есть
 
Sephiroth написал(а):
А если у меня на 1.20.1 вот такой маленький конфиг пурпура это нормально? Тут нужно добавлять что-то вручную? Или этих оптимизаций просто пока не завезли на эту версию? Использую платное ядро ssspigot
Вам необходимо зарегистрироваться для просмотра изображений-вложений
Нажмите для раскрытия...
Переустанови ядро и удали все конфиги
Авто объединение сообщений:

Я бы хотел узнать будет ли новая версия данной инструкции по оптимизации сервера? Вдруг есть уже новые моменты которые мы можем тоже настроить?
 
Последнее редактирование:
maz1lovo написал(а):
Переустанови ядро и удали все конфиги
Нажмите для раскрытия...
Да, это первое, что я сделал. Даже пробовал сгенерировать конфиг чистым ядром пурпура и скормить его sssspigot, но похоже там увы ещё нет этих оптимизаций, так что придется ждать обновления ((
 
Sephiroth написал(а):
Да, это первое, что я сделал. Даже пробовал сгенерировать конфиг чистым ядром пурпура и скормить его sssspigot, но похоже там увы ещё нет этих оптимизаций, так что придется ждать обновления ((
Нажмите для раскрытия...
Есть там все, у тебя неправильно генерируется файл. Попробуй полностью удалить все и запустить только ядро сервера
 
Pnk написал(а):
ядро которое реализует многопоточность
Нажмите для раскрытия...
Ядро которое я знаю что многопоточное, так это Floria. Но оно сделано только для сервров с мини играми и прочим(Плагинов огромная нехватка на нем т.к ядро свое). Остальные же ядра хорошо работают. Для обычной ваниллы подойдет то же самое ядро Purpur, в котором есть все оптимизации и никаких багов нет. Но покупать какое-то NoName ядро за большие деньги (1 200р) и говорить что там нет никаких оптимизаций.. Ничего не скажу. Жутко становится... Это ядро ssspigot походу долго и не протянет на плаву к сожалению
 
SSSpigot - годно, но только на версиях, где нет альтернатив, типа 1.16.5. На новых используйте бесплатные и популярные решения. Лучшее на последнии версии - Folia и Pufferfish
 
maz1lovo написал(а):
Ядро которое я знаю что многопоточное, так это Floria. Но оно сделано только для сервров с мини играми и прочим(Плагинов огромная нехватка на нем т.к ядро свое). Остальные же ядра хорошо работают. Для обычной ваниллы подойдет то же самое ядро Purpur, в котором есть все оптимизации и никаких багов нет. Но покупать какое-то NoName ядро за большие деньги (1 200р) и говорить что там нет никаких оптимизаций.. Ничего не скажу. Жутко становится... Это ядро ssspigot походу долго и не протянет на плаву к сожалению
Нажмите для раскрытия...
Ssspigot старше твоего пурпура на много насколько я знаю. И оптимизаций этих там нет скорее всего потому, что версия preview 1 только вышла.
Фишка этого ядра в том, что оно собирает в себе исправления из различных форков и что автор чинит больше уязвимостей и делает это по запросу.
 
Sephiroth написал(а):
Ssspigot старше твоего пурпура на много насколько я знаю. И оптимизаций этих там нет скорее всего потому, что версия preview 1 только вышла.
Фишка этого ядра в том, что оно собирает в себе исправления из различных форков и что автор чинит больше уязвимостей и делает это по запросу.
Нажмите для раскрытия...
Ssspigot ребенок по сравнению с пурпуром. Т.к пурпур еще с 18-го года примерно. В 19-ом они начали делать первые версии публично для большей аудитории. Так что ядро Ssspigot хоть многоядерное типо, но это гибрид всего что только возможно + накинуты свои фиксы поверх дополнительно. Пока это ядро 100 лет будет фиксить одни баги, Purprur уже пофиксит за это время раз в 10 больше багов. Поэтому нет доверия платным ядрам у которых даже исходный код закрыт, а если и открыт круглому кругу лиц (Те кто купил ядро), то уж простите.
 
Решил я вспомнить про такую штуку как флаги запуска.
А именно про то, что на самом деле 99% людей вообще в душе не чают что они в свой запускатор пихают, надейясь на то, что это им магическим образом оптимизирует сервер, ведь дяденька из интырнытов так сказал, а дяденька этот наверняка всё изучил.

В общем, критическая монография на статьи по флагам запуска:

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

1)
You must be registered for see links

Данная паста устарела по сути своей. Большинство флагов, которые не являются частью флагов айкара не соответствует нынешним реалиям.
Вероятно она все еще может быть эффективна для старых версий java (ниже 11 лол), но в наше время уже бесполезна и вот почему:
-mx1G
-Xss2048k
Оба флага устаревшие.
-XX:+UseLargePages
В ходе тестирования на проде выяснилось - эффекта не имеет или вовсе отрицателен.
-XX:+OptimizeStringConcat
Может иметь положительный эффект на работу сервера и не имеет потенциальных рисков.
-XX:parallelGCThreads=8
Не имеет под собой силы в случае использования G1GC. Он по умолчанию регулирует количество потоков для сборки мусора самостоятельно и игнорирует параметры, связанные с параллельными сборщиками.
-XX:SurvivorRatio=1
Cудя по собранной мной информации, может быть полезен в условиях ограниченной памяти. В случае с сервером, не клиентом, вероятно не несет эффектов.
-XX:+UseConcMarkSweepGC
Несовместим с G1GC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSScavengeBeforeRemark
-XX:+CMSCleanOnEnter
Флаги для ConcMarkSweepGC, следовательно все они отметаются.
-XX:+ScavengeBeforeFullGC
Неприменим для G1GC. Цитата: Этот флаг относится к сборщикам мусора, которые используют схему поколений с явно выделенной молодежной и старшей областями, таким как Parallel или CMS (Concurrent Mark-Sweep). G1GC же использует более современный подход, который не базируется на традиционной схеме поколений.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Мы отключаем ExplicitGC, так что данный флаг ничего по факту не делает.
-XX:+UseFastJNIAccessors
Потенциально действительно может помочь в оптимизации, если к примеру используются плагины, написанные на котлине.
Потенциальные же риски минимальны.
-XX:+AlwaysTenure
Информация есть буквально только на
You must be registered for see links
, на котором показан принцип его работы... ничего не понятно, не очень интересно. Судя по информации оттуда он применяется для системного сборщика мусора, который нам не нужен.
-XX:+UseCodeCacheFlushing
Неоднозначный флаг. С вероятностью в 90% может лишь навредить производительности, в связи со своим функционалом.
Флаг -XX:+UseCodeCacheFlushing является опцией настройки для Java Virtual Machine (JVM) и контролирует поведение, связанное с очисткой кэша кода (code cache) в JVM.

Code cache в JVM используется для хранения скомпилированного байт-кода (compiled bytecode), который был скомпилирован из Java-кода в машинный код и используется для выполнения Java-программы. Code cache позволяет JVM ускорить выполнение кода, так как повторно использование предварительно скомпилированного кода более эффективно, чем повторная компиляция Java-кода.

Когда флаг -XX:+UseCodeCacheFlushing включен, он разрешает очистку части code cache в JVM в случае переполнения. Это означает, что если code cache заполняется скомпилированным кодом и больше не может хранить новый код, JVM может выполнять очистку (flushing) старых или неиспользуемых скомпилированных кодов, чтобы освободить место для нового кода.

Опция -XX:+UseCodeCacheFlushing может быть полезна в ситуациях, когда JVM испытывает проблемы с переполнением code cache и это влияет на производительность. Однако, использование этой опции может повлиять на производительность приложения, так как очистка code cache может привести к перекомпиляции кода, что потребует дополнительных вычислительных ресурсов.

В большинстве случаев, не требуется включать -XX:+UseCodeCacheFlushing, и это делается только в специфических сценариях, когда переполнение code cache становится проблемой.
-XX:+TieredCompilation
Не требуется для современных версий java.
-XX:+AggressiveOpts
Как описано в статье - включает ряд оптимизаций, однако потенциально может нести риски стабильности. На проде лично у меня не вызывал каких-либо заметных проблем.
-XX:+UseBiasedLocking
Включен по умолчанию в джавах с 11 до 14, далее отключен по умолчанию. Рекомендую довериться дефолтной конфигурации jvm.
-XX:+EliminateLocks
Флаг который несет большие потенциальные риски, главный из которых - рассинхрон. Основа майнкрафт сервера всё еще однопоточная, так что всё должно быть синхронизировано с ним, данный же флаг может потенциально нарушить данные синхронизации, что может вызвать проблемы там, где их не должно было быть. Оценить эффективность оптимизаций на проде тяжело.
Флаг -XX:+EliminateLocks является опцией настройки для Java Virtual Machine (JVM) и контролирует использование оптимизации, связанной с устранением блокировок (locks) в многопоточных программах.

Когда флаг -XX:+EliminateLocks включен, JVM пытается оптимизировать код, чтобы уменьшить использование блокировок и синхронизации в многопоточных приложениях. Это может привести к увеличению производительности при работе с потоками, так как операции блокировки и синхронизации могут быть дорогостоящими и вести к замедлению выполнения.

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

Однако следует быть осторожным при использовании этой опции. В зависимости от характеристик и структуры вашего кода, оптимизация устранения блокировок может привести к непредсказуемому поведению или ошибкам в многопоточных приложениях. Включение -XX:+EliminateLocks требует тщательного тестирования и проверки на безопасность, чтобы убедиться, что оптимизация не нарушает корректность работы вашего кода в многопоточной среде.
-XX:+CompileThreshold=число
Маловероятно, что он в принципе хоть чем-то может помочь в плане производительности.
-XX:AllocatePrefetchStyle=1
В статье указано, что флаг включен по умолчанию с 9 джавы.
-XX:+UseSuperWord
Весьма вероятно не принесет вам производительности. В случае с циклами он может ускорить выполнение кода, но в других случаях наоборот вызвать дополнительные расходы. Ситуация на вроде "шило на мыло".
-XX:+OptimizeFill
Весьма вероятно устарел, точной информации о его работе нет. Лично я не рекомендовал бы испытывать судьбу, но каждому своё.
-XX:LoopUnrollMin=4
-XX:LoopMaxUnroll=16
Весьма маловероятно, что кто-либо из людей вообще способен подогнать данные значения идеально под свои нужды. Лучше будет просто данные флаги не использовать, себе дороже как говорится.
-XX:+UseLoopPredicate
Вновь противоречивый флаг, однако потенциальные риски минимальны. Ситуация схожа с -XX:+UseSuperWord
-XX:+RangeCheckElimination
Ситуация примерно та же, что и с -XX:+EliminateLocks.
Флаг -XX:+RangeCheckElimination является опцией настройки для Java Virtual Machine (JVM), который активирует оптимизации, связанные с устранением проверок диапазона (range checks).

Проверки диапазона - это проверки, которые выполняются в коде, чтобы убедиться, что индекс массива или доступ к элементу коллекции находится в допустимых пределах. Например, если у вас есть массив с 10 элементами, проверка диапазона может гарантировать, что попытка доступа к элементу с индексом 15 не произойдет.

Когда флаг -XX:+RangeCheckElimination включен, JVM пытается оптимизировать код, удаляя проверки диапазона, если она может быть определена как избыточная. В других словах, если компилятор JVM может доказать, что индекс всегда будет в допустимом диапазоне, то он может опустить проверку диапазона, что может привести к увеличению производительности.

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

Включение -XX:+RangeCheckElimination следует рассматривать с осторожностью и только после грундательного тестирования, чтобы убедиться, что это действительно улучшает производительность вашего приложения без создания потенциальных проблем.

С этой статьей завершили, переходим к

2)
You must be registered for see links


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

-XX:+UseStringDeduplication
Максимально вредящий флаг. Да, потенциально, быть может, он и будет экономить вам память... однако какой от этого всего толк, когда нагрузка от сборщика мусора возрастет на четверть?
-XX:-DontCompileHugeMethods
Ну как и было сказано в статье - "Пруфов пользы и вреда нет."
Нужно ли вам устанавливать неизвестный флаг, который делает непонятно что? Вот и я так думаю.
-server
Был удален в 9 джаве.
-Dorg.lwjgl.util.NoChecks=true
-Dforge.forceNoStencil=true
Не применимы для сервера.

3)
You must be registered for see links


Часть флагов отсюда перекликается с флагами из статьи выше, повторяться не буду.

-XX:MaxTenuringThreshold=1
Должен настраиваться под ваши нужды. Потенциального вреда нет, преимуществ от установленного значения также не наблюдал.
-XX:-UseBiasedLocking
В прошлый раз было с плюсом. Включен по умолчанию в джавах с 11 до 14, далее отключен по умолчанию. Рекомендую довериться дефолтной конфигурации jvm.
-XX:UseAVX=3
Просто приведу описание, а далее решит каждый
флаг -XX:UseAVX используется для управления использованием расширений набора команд AVX (Advanced Vector Extensions) в процессорах Intel. Однако, формат и поддерживаемые значения могут изменяться в различных версиях JVM.

Обычно флаг может принимать следующие значения:

0 (по умолчанию): Отключает использование AVX.
1: Включает использование AVX, если оно поддерживается процессором.
2: То же, что и 1, но не гарантирует, что код будет работать на процессорах без поддержки AVX.
3: Этот вариант не является стандартным, и его значение и эффекты могут зависеть от конкретной версии JVM. В общем случае, использование нестандартных или экспериментальных значений флагов не рекомендуется в production-системах, так как они могут вызвать нежелательное поведение или несовместимость.
-XX:+UseFastUnorderedTimeStamps
Данный флаг ххоть потенциально и может увеличить производительность сервера также может вызвать проблемы, связанные с профилированием, а это у нас и spark и тайминги, в следствии чего лично я его не использую.
-XX:+UseAES
-XX:+UseAESIntrinsics
Не все системы это поддерживают. А если ваша система это поддерживает - то можете протестировать эффективность лично.
-XX:UseSSE=4
Как и в прошлом пункте.
-XX:+UseFMA
Как и в прошлом пункте.
-XX:+SegmentedCodeCache
Потенциально способно ускорить работу сервера за счет кеширования часто выполняемого кода. Риски минимальные.
-XX:+UseCompressedOops
Потенциально способно ускорить работу сборщика мусора, а риски почти отсутствуют.
-XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=1
Маловероятно, что пригодится.
-XX:+OmitStackTraceInFastThrow
Вероятно может помочь в случае, когда есть куча возникающих исключений, в иных ситуациях малополезен и может усложнить работу с исключениями.
-XX:+TrustFinalNonStaticFields
Вновь проблема главного потока и рассинхрона. Лично я проблем не испытывал.
-XX:+UseInlineCaches
Может потенциально ускорить работу приложения, однако в замен будет потреблять больше памяти, а также создаст проблемы при профилировании.
-XX:+RewriteBytecodes
Потенциально ускоряет работу сервера с потенциальными же рисками, связанными с профилированием. Однако исходя из тестов - реальных проблем не вызывает.
-XX:+RewriteFrequentPairs
Принцип работы схож с предыдущем.
-XX:+UseNUMA
Оптимизирует работу с памятью и полезен, когда у вас больше 1 физ.ядра
-XX:+UseFPUForSpilling
-XX:+UseFastStosb
-XX:+UseVectorCmov
-XX:+UseXMMForArrayCopy
-XX:+UseXmmI2D
-XX:+UseXmmI2F
-XX:+UseXmmLoadAndClearUpper
-XX:+UseXmmRegToRegMoveAll
Ряд флагов, чья эффективность... не замерялась.
Лично я не увидел ни плюсов ни проблем при использовании.
  • -XX:+UseFPUForSpilling - использует сопроцессор FPU для хранения предупреждающих состояний, связанных с переполнением памяти.
  • -XX:+UseFastStosb - оптимизирует операцию stosb, которая копирует определенное значение в память.
  • -XX:+UseVectorCmov - использует инструкцию cmov для векторных операций.
  • -XX:+UseXMMForArrayCopy - использует регистр xmm для операции копирования массива.
  • -XX:+UseXmmI2D - использует регистр xmm для преобразования целых чисел в числа с плавающей запятой двойной точности.
  • -XX:+UseXmmI2F - использует регистры xmm для преобразования целых чисел в числа с плавающей запятой одинарной точности.
  • -XX:+UseXmmLoadAndClearUpper - использует регистры xmm для загрузки значений с памяти и сброса старших разрядов до нуля.
  • -XX:+UseXmmRegToRegMoveAll - использует регистры xmm для пересылки данных между регистрами xmm.
-XX:+UseNewLongLShift
Весьма узкоспециализированный флаг направленный на операцию сдвига, смысла в использовании фактически 0
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху Снизу