Туториал Ускорение работы Java [Аргументы]

  • Автор темы Автор темы Starr
  • Дата начала Дата начала
ВНИМАНИЕ! Используйте только при крайней необходимости. Не стоит страдать этой уйнёй, автору просто нечем было заняться.

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

И так, приступим.
Я собрал множество аргументов с описанием, которые позволяют серверу, а также клиенту работать более оптимизировано и быстрее.

ВНИМАНИЕ! Для того, чтобы добиться максимальной производительности, лучше выбрать определенные аргументы, нежели вписывать все сразу.
На разных версиях Java и на разном железе - аргументы ведут себя по-разному. Так что лучше после установки аргумента каждый раз перепроверять, улучшилась производительность, или нет.


Пример строки запуска:
Код:
java -аргумент1 -аргумент2 -аргументN server.jar

Строка запуска моего сервера:
Код:
java -Xmx5G -Xmn192M -XX:+UseConcMarkSweepGC -jar server.jar

Аргументы моего клиента:
Код:
-Xmn256M

Выделение Java под конкретные ядра (только Linux)

Перед командой запуска сервера, добавьте эту команду:

Код:
taskset -c [ядра] [команда запуска]
[ядра] = 0,1,2,3 - указывать обязательно в таком формате.
Выражаем благодарность @scrik78



Список аргументов:

Основные флаги
  • -Xincgc - активирует сборщик мусора, который время-от-времени будет выгружать неиспользуемую оперативную память. Тип сборщика выбирается в зависимости от версии Java.
  • -server - активирует серверную версию Java, в которой по умолчанию включена функция поддержки экспериментальных флагов, а также ускоряет компиляцию классов, что даёт прирост в производительности, но увеличивает время запуска (только 64-битные системы)

Выделение памяти
  • -Xmx5G - количество максимальной выделяемой памяти под сервер
  • -Xms512M - количество минимально выделяемой памяти под сервер
  • -Xmn128M - количество выделяемой памяти под недолгоживущие объекты (которые не были выгружены сборщиком мусора)
  • -XX:MaxPermSize=128M - количество памяти под PermGen Space (не работает на Java 8)
  • -XX:SharedReadOnlySize=30M - количество памяти под read-only место в PermGen

Сборщики мусора
Это больная тема, советую экспериментировать, чтобы добиться хоть чего-то стоящего, а не наоборот, ухудшить производительность.
МИНИ-СОВЕТ: Для одноядерных процессоров используйте любой сборщик мусора, но не указывайте кол-во потоков для него. На данный момент лучшим сборщиком мусора для кубача является ConcMarkSweepGC. Чем больше число SurvivorRatio - тем лучше, тем меньше старые объекты будут захламлять ОЗУ. Чем больше TargetSurvivorRatio - тем больше старых объектов будет очищаться (желательно не ставить более 90).
Использовать MaxGCPauseMillis лучше всего с G1GC или с конкретно указанным сборщиком мусора. AutoGCSelectPauseMillis - со сборщиком, который система сама выберет. G1HeapRegionSize лучше не устанавливать, java сама подберет оптимальное значение, использовать только если знаете, что делаете.

  • -XX:+UseSerialGC - включает сборщик мусора, который работает в 1 потоке
  • -XX:+UseConcMarkSweepGC - включает сборщик мусора, который использует мощь нескольких процессоров.
  • -XX:ConcGCThreads=2 - количество процессов для сборщика мусора.
  • -XX:+UseG1GC - активирует новый сборщик мусора, разделяет всю память на определенные участки, и благодаря использованию нескольких ядер, собирает со всех участков неиспользуемую память.
  • -XX:G1HeapRegionSize=32 - количество памяти, выделяемой под каждый участок.
  • -XX:AutoGCSelectPauseMillis=2500 - количество времени в миллисекундах между вызовом автоматически выбраного сборщика мусора.
  • -XX:MaxGCPauseMillis=1000 - длительность времени в миллисекундах между вызовом конкретного сборщика мусора. Для G1GC исполняет роль максимально установленного промежутка.
  • -XX:SurvivorRatio=8 - количество радиуса для существования выживающих объектов (чем меньше число, тем больше место). Большее место дает возможность недавно сгенерированным объектам жить дольше перед очисткой мусора.
  • -XX:TargetSurvivorRatio=90 - количество места в процентах под выживающие объекты, что позволит очищать больше неиспользуемых объектов во время сборки мусора.

Экспериментальные аргументы
  • -XX:+AggressiveOpts - активация экспериментальных опций Java-машины.
    (-XX:AutoBoxCacheMax=20000 -XX:BiasedLockingStartupDelay=500 -XX:+EliminateAutoBox -XX:+OptimizeFill -XX:+OptimizeStringConcat)
  • -XX:+UseBiasedLocking - ускорение синхронизации объектов на многоядерных процессорах.
  • -XX:+UseFastAccessorMethods - использование оптимизированных версий вызова методов.
  • -XX:+UseFastEmptyMethods - исключение из компиляции пустых методов.
  • -XX:+UseCompressedOops - уменьшение размеров указателя, заголовков, а также сдвигов внутри созданных объектов. В зависимости от кода сэкономит 20-60% ОЗУ.
  • -XX:+OptimizeFill - замена циклов работы с массивами на машинный код, что ускоряет работу
  • -XX:+OptimizeStringConcat - оптимизация конкатенации объектов типа String. Вместо 20 вызовов одной операции на 20 символов, вызывает единожды на 400 символов
  • -XX:+UseStringCache - включает кеширование объектов типа String. Где и как кешируется не понятно.
  • -XX:-UseGCOverheadLimit - игнорирует нехватку памяти для сборки мусора, избавляет частично от Out Of Memory Error
  • -XX:+CMSIncrementalPacing - автоматическое регулирование процессов CMS в Incremental mode.
  • -XX:+CMSCleanOnEnter - очистка CMS при запуске Java-машины.
  • -XX:+UseInterpreter - включение интерпретатора для некомпилированных методов.
  • -XX:UseSSE=4 - использование инструкций SSE процессора. (0 - отключить, 1/2/3/4 - использование SSE/SSE2/SSE3/SSE4)
  • -XX:MaxTenuringThreshold=15 - количество копирований выживающих объектов между разными местами.
  • -XX:+RewriteFrequentPairs - перезапись недавно использовавшихся пар байткода в одно целое.
  • -XX:+UseInlineCaches - использование внеочередного кеширования для виртуальных вызовов.
  • -XX:+UseThreadPriorities - использование приоритета для процесса Java-машины.
  • -XX:ThreadPriorityPolicy=42 - установка приоритета процесса для увеличения выделяемых ресурсов.

Надеюсь, мой туториал вам пригодился 🙂
 
Последнее редактирование:
Выделение Java под конкретные ядра

Перед командой запуска сервера, добавьте эту команду:

[ядра] = 0,1,2,3 - указывать обязательно в таком формате.
Выражаем благодарность @scrik78

Извините меня пожалуйста за глупый вопрос.
Эта команда работает только на ОС linux?
Просто проверив на винде, пишет что мол ""Taskset" не является внутренней или внешней командой, исполняемой командой или пакетным файлом.".

Хотелось бы узнать, эта строка повысит производительность?
 
Извините меня пожалуйста за глупый вопрос.
Эта команда работает только на ОС linux?
Просто проверив на винде, пишет что мол ""Taskset" не является внутренней или внешней командой, исполняемой командой или пакетным файлом.".

Хотелось бы узнать, эта строка повысит производительность?
данная команда для linux
в windows гуглите в сторону команды "start" ,опция /affinity
 
данная команда для linux
в windows гуглите в сторону команды "start" ,опция /affinity
Строку добавлять над скриптов или перед ним?
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
taskset -c 0,1 java -Dfile.encoding=UTF-8 -XX:+UseG1GC -server -Xms3074M -Xmx3074M -Xmn128M -XX:+OptimizeFill -XX:+UseBiasedLocking -XX:ConcGCThreads=2 -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:MaxGCPauseMillis=1000 -XX:SurvivorRatio=6 -jar spigot-1.8.8.jar -o true
exit 0
Это может дать больше производительности?

И еще, со строками оптимизации все в порядке?
 
Строку добавлять над скриптов или перед ним?
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
taskset -c 0,1 java -Dfile.encoding=UTF-8 -XX:+UseG1GC -server -Xms3074M -Xmx3074M -Xmn128M -XX:+OptimizeFill -XX:+UseBiasedLocking -XX:ConcGCThreads=2 -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:MaxGCPauseMillis=1000 -XX:SurvivorRatio=6 -jar spigot-1.8.8.jar -o true
exit 0
Это может дать больше производительности?

И еще, со строками оптимизации все в порядке?
taskset у вас нормально вписан
 
Строку добавлять над скриптов или перед ним?
Это может дать больше производительности?
И еще, со строками оптимизации все в порядке?
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
taskset -c 0,1 java -Dfile.encoding=UTF-8 -XX:+UseG1GC -server -Xms3074M -Xmx3074M -Xmn192M -jar spigot-1.8.8.jar -o true
exit 0

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

а насчёт ядер, сборщик мусора насколько знаю юзает все ядра процессора изначально, а сам сервер работает в одном потоке. поэтому тасксетом ты просто ограничиваешь кол-во ядер которые может использовать g1gc
 
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
taskset -c 0,1 java -Dfile.encoding=UTF-8 -XX:+UseG1GC -server -Xms3074M -Xmx3074M -Xmn192M -jar spigot-1.8.8.jar -o true
exit 0

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

а насчёт ядер, сборщик мусора насколько знаю юзает все ядра процессора изначально, а сам сервер работает в одном потоке. поэтому тасксетом ты просто ограничиваешь кол-во ядер которые может использовать g1gc
Машина слабая.
Процессор старенький(2.10 ghz 2 ядерный)
Памяти 4 гб
Тпс скачет если например телепортироватся куда нибудь.
Я еще юзаю банжи, ей выделил 1 гб, а серверу 3 гб.
Java 8 уже использует эти аргументы?)
И стоит юзать аргументы в запуск BungeeCord?
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
java -Dfile.encoding=UTF-8 -Xms1024M -Xmx1024M -server -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -jar BungeeCord.jar -o true
exit 0
 
Машина слабая.
Процессор старенький(2.10 ghz 2 ядерный)
Памяти 4 гб
Тпс скачет если например телепортироватся куда нибудь.
Я еще юзаю банжи, ей выделил 1 гб, а серверу 3 гб.
Java 8 уже использует эти аргументы?)
И стоит юзать аргументы в запуск BungeeCord?
Код:
#!/bin/bash
BINDIR=$(dirname "$(readlink -fn "$0")")
cd "$BINDIR"
java -Dfile.encoding=UTF-8 -Xms1024M -Xmx1024M -server -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -jar BungeeCord.jar -o true
exit 0
На банжу толк есть юзать? Я же не думаю что у тебя на банже огромный мир с кучей игроков и разных ентити
Конечно применяй аргументы к самому серверу
 
На банжу толк есть юзать? Я же не думаю что у тебя на банже огромный мир с кучей игроков и разных ентити
Конечно применяй аргументы к самому серверу
У меня получается немного не обычно.
На дедике 2 сервера.
BungeeCord локально адресует на основной сервер.
И адресует на мой ип.
Я просто тестирую сервер мини-игр.
На банжу толк есть юзать? Я же не думаю что у тебя на банже огромный мир с кучей игроков и разных ентити
Конечно применяй аргументы к самому серверу
Можете посоветовать самые нужные аргументы в запуск исходя из машины?
 
У меня получается немного не обычно.
На дедике 2 сервера.
BungeeCord локально адресует на основной сервер.
И адресует на мой ип.
Я просто тестирую сервер мини-игр.

Можете посоветовать самые нужные аргументы в запуск исходя из машины?
Я знаю принцип работы банжи, может не обьяснять
Для банжи нет толка оптимизировать что либо, тк все действия будут происходить на основном сервере

Аргументы я уже советовал, достаточно лишь к стандартной команде запуска добавить -XX:+UseG1GC и -Xmn192M
Если сервак пролагивает, когда игрока перекидывает с банжа на основной сервер, тогда берите другую машинку.
 
Я знаю принцип работы банжи, может не обьяснять
Для банжи нет толка оптимизировать что либо, тк все действия будут происходить на основном сервере

Аргументы я уже советовал, достаточно лишь к стандартной команде запуска добавить -XX:+UseG1GC и -Xmn192M
Если сервак пролагивает, когда игрока перекидывает с банжа на основной сервер, тогда берите другую машинку.
Я убрал ненужные агрументы..
И теперь вижу такую картину
https://timings.spigotmc.org/?url=wiligogeje

Через какое то время TPS падает, но это не так почему то видно.
Игроки вроде плавно двигаются, но тпс 14 а то и ниже! Такого не было.
По совету из timings, я вместо 7 поставил 6(ну не очень хочется чанки резать), все равно такая фигня. Может у меня не правильно настроен конфиг spigot.yml?
Выполнил команду /stoplag
После нее удалились мобы.
Потом /stoplag -c
И вроде все в порядке. Дело в мобах? Как то можно ограничить число их спавна?
 
Я убрал ненужные агрументы..
И теперь вижу такую картину
https://timings.spigotmc.org/?url=wiligogeje

Через какое то время TPS падает, но это не так почему то видно.
Игроки вроде плавно двигаются, но тпс 14 а то и ниже! Такого не было.
По совету из timings, я вместо 7 поставил 6(ну не очень хочется чанки резать), все равно такая фигня. Может у меня не правильно настроен конфиг spigot.yml?
Выполнил команду /stoplag
После нее удалились мобы.
Потом /stoplag -c
И вроде все в порядке. Дело в мобах? Как то можно ограничить число их спавна?
у тебя в основном мире слишком много ентити генерируется, их можно в баккит.умл и спигот.умл ограничить.
и еще советую настроить chunk-threshold, если на серваке загружено больше определенного кол-ва чанков, он выгружает не используемые. так уменьшается нагрузка
 
Спасибо! Статья полезная! исходя из этой темы, поюзав гугл час, найдя нужные флаги, увеличил TPS с 13,62 до 19,34
 
предложение: дописать в ПП темы что часть параметров включена по умолчанию и дописывать их не нужно (исключение только тогда когда др аргумент их выключает).
возможно меня бомбануло?
Часть описания параметров jvm в ПП не до конца верны/точны.

На Java 7 лучше всего работает сборщик мусора CMS (ConcMarkSweepGC)
нет, ParallelGC(+ParallelOldGC) чистит память лучше остальных, проверено на HotSpot/OpenJDK, и нет стоп-мир паузы редки и малы чтобы от них отказываться, лаги от компрессии/декомпрессии и др слоу кода куда больше жрут времени в течении работы сервера(общее кол-во времени на сие операции затратил сервер за некое кол-во часов его работы до ребута).
На Java 8 использовать следует Garbage One GC (G1GC)
компания Oracle рекомендует использовать G1GC только при хипе более 16гб, практика и гугл с тестами показывает что CMS лучше чистит мусор чем G1GC (даже при куче выше 16гб)

ParallelGC лучше работал имхо на J7, тестилось на майне 1.7.10 с форгом(как пара так и пара десятков модов). Про сборщики мусора - проверял и для 1.8/1.8.9/1.9/1.10/1.10.2 ваниль и с парой модов, на J7/J8, версий билдов 80+(например HotSpot 1.8 build 92).

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

Прочел почти всю тему, мдя, видно не знание мат. части господа.
Ну и сама Java8 повышает производительность.
вжжжух, без конкретики и случая это очень сомнительно, скорее самопил будет лучше, но только после тестов JMH/Unit.

Для более быстрой работы количество максимальной и минимальной выделяемой памяти под сервер должно совпадать!
тесты показали что добавление Xms на клиент-сервер с модами (грегтех тоже стоит) увеличивает потребление памяти на процесс, ускорение запуска не обнаружено.
 
Последнее редактирование:
Напомните мне пж сколько памяти на 1 игрока выделять? И сколько еще надо дать плагинам (у меня на сервере в среднем 21-22 плагина)
 
Назад
Верх Низ