UBERROT Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 (изменено) Техническое неполное руководство по аргументам для Java Virtual Machine Вступление Гайд сделан от интереса этой сферы, дабы пользователи VimeWorld об этом больше узнали. Информация собрана с открытых англоязычных и русскоязычных источников, и не претендует на звание первоисточника. В Руководстве описывается работа аргументов, как их можно применить. Если я в чём-то ошибся поправьте меня в комментариях. Содержание Основные понятия Работа с памятью Сборщик мусора Аргументы Аргументы для разработчиков Основные понятия Что такое JVM? - Java Virtual Machine (сокращенно Java VM, JVM) — виртуальная машина Java — основная часть исполняющей системы Java, так называемой Java Runtime Environment (JRE). Виртуальная машина Java исполняет байт-код Java, предварительно созданный из исходного текста Java-программы компилятором Java (javac). JVM может также использоваться для выполнения программ, написанных на других языках программирования. Например, исходный код на языке Ada может быть скомпилирован в байт-код Java, который затем может выполниться с помощью JVM. JVM является ключевым компонентом платформы Java. Так как виртуальные машины Java доступны для многих аппаратных и программных платформ, Java может рассматриваться и как связующее программное обеспечение, и как самостоятельная платформа. Использование одного байт-кода для многих платформ позволяет описать Java как «скомпилируй единожды, запускай везде» (compile once, run anywhere). Что такое JVMargs? - Это аргументы для настройки JVM. Как использовать JVMargs на VimeWorld? - файл jvmargs.txt должен находиться в папке .vimeworld, чтобы все работало следует перезапустить игру. Куча? - Мешок, пакет с определённым количеством памяти обработки за раз. K, M, G - Килобайт, мегабайт, гигабайт. Работа с памятью -Xmx1024M - Максимальное количество памяти, которое вы хотите дать игре. Можно выдать от "300M" до "8192M"+, для VimeWorld MiniGames за голову хватает 4-5гб памяти, советую ставить значения "1024M", "2048M", "4096M", так-же можно ставить "2G", "4G" и т.д. Прирост FPS может быть до значения "4096M", выше прироста FPS вы не заметите, связано это с ограничением чанков на сервере(8). Размер памяти влияет на задержку обработки памяти, "1024M" - примерно 1ms, "5120M"+ - примерно 10ms+, не уверен зависит ли данная задержка от скорости вашей оперативной памяти и её таймингов, вероятнее всего нет. Связано с количеством FPS. -Xmn2M - Минимальная куча памяти которая будет использоваться в игре. Можно выдать от "любогоK" до "6-8части максимального количества памяти". Чем меньше тем стабильнее, не советую ставить менее чем "2M". Cвязано со стабильностью FPS. -Xms512M - Среднее количество памяти которое будет использоваться в игре. Можно выдать от половины и менее максимального количества памяти в игре. Тут выставлено среднее значение, так-же можно выставить 765M и т.д. Данное количество памяти будет использовано в 100% времени игры, если игра захочет взять больше то может дойти до потолка(максимума) что вы указали, что приведет к принудительному очищению мусора и спаду до среднего("512M" к примеру) значения, так как минимальная куча выставлена в районе 2M, то память может вообще никогда не дойти до потолка. Что-то среднее между стабильностью и количеством FPS, ближе к стабильности. -XX:MaxMetaspaceSize=1310M - Максимальное количество выделяемой виртуальной памяти. -XX:NewSize=256M - Выделяемое количество виртуальной(?) памяти. -XX:MaxNewSize=1310M - Максимальное количество выделяемой виртуальной(?) памяти. -Xss512K - Каждый поток в приложении Java имеет собственный стек. Стек используется для хранения адресов возврата, аргументов вызова функции/метода и т. д. Поэтому, если поток имеет тенденцию обрабатывать большие структуры с помощью рекурсивных алгоритмов, ему может потребоваться большой стек для всех этих адресов возврата и тому подобного. В Sun JVM вы можете установить этот размер с помощью этого параметра. Насколько я знаю, выше чем 2048K либо 4096K(не уверен) не работает. Сборщик мусора -XX:+UseSerialGC - Последовательный сборщик использует один поток для выполнения всей работы по сбору мусора, что делает его относительно эффективным, поскольку между потоками не возникает дополнительных затрат на связь. Он лучше всего подходит для однопроцессорных машин, поскольку не может использовать преимущества многопроцессорного оборудования, хотя может быть полезен на многопроцессорных системах для приложений с небольшими наборами данных (примерно до 100 МБ). Сборщик последовательных портов выбирается по умолчанию в определенных конфигурациях оборудования и операционной системы или может быть явно включен с помощью параметра -XX:+UseSerialGC. -XX:+UseParallelGC - Параллельный сборщик (также известный как сборщик пропускной способности) выполняет второстепенные сборы параллельно, что может значительно сократить накладные расходы на сборку мусора. Он предназначен для приложений с наборами данных среднего и большого размера, которые работают на многопроцессорном или многопоточном оборудовании. Параллельный сборщик выбирается по умолчанию в определенных конфигурациях оборудования и операционной системы, или его можно явно включить с помощью параметра -XX:+UseParallelGC. -XX:+UseG1GC - Сборщик мусора Garbage-First (G1) — это сборщик мусора серверного типа, предназначенный для многопроцессорных машин с большим объемом памяти. Он пытается с высокой вероятностью выполнить цели по времени паузы сборки мусора (GC), достигая при этом высокой пропускной способности. Операции с целой кучей, такие как глобальная маркировка, выполняются одновременно с потоками приложения. Это предотвращает прерывания, пропорциональные размеру кучи или оперативных данных. G1GC включается с помощью параметра командной строки -XX:+UseG1GC. Используется на VimeWorld по умолчанию. -XX:+G1UseAdaptiveIHOP -XX:InitiatingHeapOccupancyPercent=45 - Значения по умолчанию для управления начальной загрузкой кучи указывают на то, что адаптивное определение этого значения включено, и что для первых нескольких циклов сбора G1 будет использовать загрузку 45% от старого поколения в качестве порога начала метки. -XX:G1HeapRegionSize=<var> - Размер областей кучи. Значение по умолчанию основано на максимальном размере кучи и рассчитано для рендеринга примерно 2048 регионов. Размер должен быть степенью 2, а допустимые значения — от 1 до 32 МБ. -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60 - Общий размер молодого поколения, который варьируется между этими двумя значениями в процентах от текущей используемой кучи Java. Требует -"XX:+UnlockExperimentalVMOptions". -XX:G1MixedGCCountTarget=8 - Ожидаемая продолжительность фазы освоения пространства в ряде коллекций. -XX:G1MixedGCLiveThresholdPercent=85 - Области старого поколения с более высокой заполненностью живыми объектами, чем этот процент, не собираются на этом этапе освоения пространства. Требует -"XX:+UnlockExperimentalVMOptions". -XX:-G1EnableStringDeduplication - По умолчанию дедупликация строк отключена. Вы можете включить его. -XX:+UseConcMarkSweepGC или -XX:+USeParNewGC - Сборщик Concurrent Mark Sweep (CMS) предназначен для приложений, которые предпочитают более короткие паузы при сборке мусора и могут позволить себе совместно использовать ресурсы процессора со сборщиком мусора во время работы приложения. Как правило, приложения, которые имеют относительно большой набор долгоживущих данных (большое постоянное поколение) и работают на машинах с двумя или более процессорами, как правило, выигрывают от использования этого сборщика. Тем не менее, этот коллектор следует рассматривать для любого приложения с низкими требованиями к времени паузы. Сборщик CMS включается с помощью параметра командной строки -XX:+UseConcMarkSweepGC (Для сервера), -XX:+USeParNewGC. -XX:CMSInitiatingOccupancyFraction=70 - (Для сервера) Выбирает уровень, на котором начинается сбор. Значение по умолчанию — 68%. -XX:-CMSIncrementalMode - Включает инкрементный режим. Обратите внимание, что сборщик CMS также должен быть включен (с -XX:+UseConcMarkSweepGC), чтобы эта опция работала. -XX:-CMSIncrementalPacing - Включает автоматическую стимуляцию. Рабочий цикл инкрементного режима автоматически настраивается на основе статистики, собранной во время работы JVM. -XX:CMSIncrementalDutyCycle=10 - Процент (от 0 до 100) времени между второстепенными сборами, который разрешен для запуска сборщика CMS. Если CMSIncrementalPacing включен, то это просто начальное значение. -XX:CMSIncrementalDutyCycleMin=0 - Процент (от 0 до 100), являющийся нижней границей рабочего цикла при включении CMSIncrementalPacing. -XX:CMSIncrementalSafetyFactor=10 - Процент (от 0 до 100), используемый для добавления консерватизма при вычислении рабочего цикла. -XX:CMSIncrementalOffset=0 - Процент (от 0 до 100), на который рабочий цикл инкрементного режима смещается вправо в течение периода между второстепенными сборами. -XX:CMSExpAvgFactor=25 - Процентное значение (от 0 до 100), используемое для взвешивания текущей выборки при вычислении экспоненциальных средних для статистики коллекции CMS. -XX:+UseShenandoahGC - Shenandoah GC позиционируется как сборщик, который стремится поддерживать короткие паузы даже на кучах большого объема, за счет выполнения как можно большего количества работы по сборке мусора в конкурентном режиме, то есть одновременно с работой основных потоков приложения. Скрытый текст Эвристика. После выбора режима эвристика сообщает, когда Shenandoah запускает цикл GC, и области, которые он считает для эвакуации. Эвристика может быть выбрана с помощью -XX:ShenandoahGCHeuristics=<имя>. Некоторые эвристики принимают параметры конфигурации, которые могут помочь лучше адаптировать операцию GC к вашему варианту использования. Доступные эвристики включают Адаптивный (по умолчанию). Эта эвристика отслеживает предыдущие циклы сборки мусора и пытается запустить следующий цикл сборки мусора, чтобы он мог завершиться до исчерпания кучи. -XX:ShenandoahInitFreeThreshold=# - Начальный порог, при котором инициируются «обучающие» коллекции. -XX:ShenandoahMinFreeThreshold=# - Порог свободного пространства, при котором эвристика безоговорочно запускает сборщик мусора. -XX:ShenandoahAllocSpikeFactor=# - Сколько кучи зарезервировать для поглощения всплесков распределения. -XX:ShenandoahGarbageThreshold=# - Устанавливает процент мусора, который регион должен содержать, прежде чем его можно будет пометить для сбора. Статический (ранее по иронии судьбы известный как динамический). Эта эвристика решает запустить цикл GC на основе занятости кучи. Полезные ручки настройки для этой эвристики: -XX:ShenandoahMinFreeThreshold=# - Установите процент свободной кучи, при котором запускается цикл GC -XX:ShenandoahGarbageThreshold=# - Устанавливает процент мусора, который регион должен содержать, прежде чем его можно будет пометить для сбора. Компактный (ранее ошибочно известный как непрерывный). Эта эвристика запускает циклы GC непрерывно, начиная следующий цикл, как только завершается предыдущий цикл, пока происходит выделение памяти. Эта эвристика обычно приводит к накладным расходам на пропускную способность, но обеспечивает наиболее быстрое освобождение пространства. Полезные ручки настройки: -XX:ConcGCThreads=# - Сократите количество одновременных потоков GC, чтобы освободить место для запуска приложения. -XX:ShenandoahAllocationThreshold=# - Установите процент памяти, выделенной с момента последнего цикла GC, перед запуском другого. Агрессивный (диагностический). Эта эвристика говорит сборщику мусора быть полностью активным. Он начнет новый цикл GC, как только завершится предыдущий (например, «compact»), и эвакуирует все живые объекты. Эта эвристика полезна для функционального тестирования самого коллектора. Это влечет за собой серьезные потери производительности. Режимы отказа. Параллельный GC, такой как Shenandoah, неявно полагается на сбор быстрее, чем выделяет приложение. Если нагрузка на выделение высока и не хватает места для размещения выделений во время работы сборщика мусора, в конечном итоге произойдет сбой выделения. У Шенандоа есть изящная лестница деградации, которая помогает выжить в таких случаях. Лестница состоит из: Темп(Pacing) (-XX:+ShenandoahPacing, включен по умолчанию). Когда сборщик мусора работает, он имеет представление о том, сколько работы сборщика мусора необходимо выполнить и сколько свободного места доступно для приложения. Pacer попытается приостановить выделение потоков, если сборка мусора будет выполняться недостаточно быстро. В обычных условиях GC собирает быстрее, чем выделяет приложение, и пейсер естественно не глохнет. Обратите внимание, что синхронизация вводит локальную задержку для каждого потока, которая не видна в обычных инструментах профилирования. Вот почему киоски не являются бесконечными, и они ограничены -XX:ShenandoahPacingMaxDelay=#ms. После истечения максимальной задержки распределение произойдет в любом случае. Большую часть времени легкие всплески распределения поглощаются стимулятором. Когда давление распределения очень велико, пейсер не справляется, и деградация переходит к следующему шагу. Обычная задержка: <10 мс Вырожденный GC(Degenerated GC) (-XX:+ShenandoahDegeneratedGC, включен по умолчанию). Если приложение сталкивается с ошибкой распределения, то Шенандоа погрузится в паузу «останови мир», остановит все приложение и продолжит цикл под паузой. Вырожденный GC продолжает текущий «параллельный» цикл под остановкой мира. Во многих случаях сбой распределения происходит после того, как значительный объем работы по сборке мусора уже выполнен, а небольшая часть работы по сборке мусора должна быть завершена. Вот почему пауза STW обычно невелика. Это будет сообщено как пауза GC в журнале GC, все обычные потоки мониторинга и пульса: действительно, одна из причин, чтобы вызвать паузу STW, состоит в том, чтобы сделать сбои в параллельном режиме четко наблюдаемыми. Вырожденный GC может произойти, если цикл GC начался слишком поздно или если произошел очень значительный всплеск распределения. Вырожденный цикл может быть быстрее, чем параллельный, поскольку он не конкурирует с приложением за ресурсы и использует -XX:ParallelGCThreads, а не -XX:ConcGCThreads для определения размера пула потоков. Обычная индуцированная задержка: <100 мс, но может быть и больше, в зависимости от точки вырождения Полный GC (Full GC). Если ничего не помогло, например, когда Degenerated GC не освободил достаточно памяти, произойдет полный цикл GC, и уплотнит кучу до максимума. Некоторые сценарии, такие как необычно фрагментированная куча в сочетании с ошибками и пропусками производительности реализации, могут быть исправлены только с помощью полного GC. Этот последний GC гарантирует, что приложение не выйдет из строя с OOM, если есть хотя бы немного доступной памяти. Обычная задержка:> 100 мс, но может быть и больше, особенно в очень занятой куче Анализ производительности. Подходы к анализу эффективности: Некоторое странное поведение производительности — например, ошибки при распределении GC или длинные итоговые оценки — можно объяснить проблемами эвристики. -Xlog:gc+ergo — ваш друг. Если у вас длительная рабочая нагрузка, запуск под управлением Shenandoah Visualizer позволит вам понять высокоуровневое поведение сборщика мусора. Иногда там отчетливо видно странное поведение. Некоторую разницу в производительности можно объяснить большим давлением на выделение ресурсов в Shenandoah, поскольку он включает указатель пересылки с каждым объектом. Посмотрите на скорость распределения, чтобы увидеть, может ли это быть проблемой, и проведите эксперименты, которые могут это подтвердить (например, увеличение объектов должно уменьшить разницу в производительности по сравнению с другим сборщиком). В некоторых случаях больший размер означает выпадение кеша ЦП, ищите различия промахов L1/L2/LLC. Многие различия в пропускной способности можно объяснить накладными расходами барьеров GC. При работе с параметром -XX:ShenandoahGCHeuristics=passive и только с этой эвристикой барьеры не требуются для корректности, поэтому эвристика отключает их. Затем можно выборочно включить барьеры обратно и посмотреть, какие барьеры влияют на пропускную способность. Список барьеров, которые отключает «пассивная» эвристика, указан в выводе GC, например: $ java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=passive -Xlog:gc [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahSATBBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahKeepAliveBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahWriteBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahReadBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahStoreValReadBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahCASBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahAcmpBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahCloneBarrier by default [0.003s][info][gc] Using Shenandoah Профилировать нативный код сборщика мусора легко с помощью Linux perf: Соберите OpenJDK с --with-native-debug-symbols=internal, это даст вам сопоставление с кодом C++ Запустите рабочую нагрузку с помощью Perf Record java... (обычный профиль) или perf Record -g java... (профиль дерева вызовов). Откройте отчет с отчетом о производительности. Просмотрите отчет и посмотрите, где находятся подозрительно горячие методы/пути. Нажатие "а" на методе обычно дает более подробную разборку по нему. Для профилирования кода барьеров требуется сборка с поддержкой PrintAssembly. Мы рекомендуем использовать JMH-prof perfasm для создания изолированных сценариев и просмотра сгенерированного кода под Shenandoah. Важно понимать, что паузы GC могут быть не единственным существенным фактором, влияющим на время отклика в обычных приложениях. Наличие большой паузы GC означает проблему со временем отклика с очень высокой вероятностью, но отсутствие длинных пауз GC не всегда означает приличное время отклика. Задержки в очереди, сетевые задержки, задержки других служб, дрожание планировщика ОС и т. д. могут быть сопутствующими затратами. Рекомендуется запустить Shenandoah с измерением времени отклика, чтобы получить полную картину того, что происходит в системе, которую затем можно использовать для корреляции со статистикой времени паузы GC. Например, это пример отчета с jHiccup по одной из рабочих нагрузок: Функциональная диагностика. В этом разделе описываются способы диагностики и/или отладки Shenandoah. Вот шаги, которые вы можете сделать, чтобы сузить проблемную область: Запустите с -XX:+ShenandoahVerify. Это первая линия защиты от ошибок GC. Он доступен как в релизной, так и в быстрой отладочной сборке. Если Verifier идентифицирует проблему, то, скорее всего, это ошибка сборщика мусора. Было бы удобно иметь простой репродуктор, чтобы лучше диагностировать это. Во многих случаях имеет значение то, что произошло раньше в GC, например. последние действия, предпринятые GC. Эта история обычно записывается в связанный файл hs_err_pidXXXX.log, обязательно включите его полностью при сообщении об ошибке. Запустите сборку fastdebug. Во многих случаях это приведет к созданию осмысленных сообщений об утверждениях, указывающих на самый ранний момент, когда сборщик мусора обнаружил функциональную аномалию, а Shenandoah много утверждает. Эти сборки можно создать, добавив --enable-debug в файл configure и пересобрав. Как обычно, hs_err_pidXXXX.log удобно записывает среду и исторические данные, которые помогают исследовать сбой утверждения. Запустите с параметром -XX:ShenandoahGCHeuristics=passive, который будет выполнять только сборщик мусора с остановкой мира и не будет выполнять большую часть параллельной работы. Если проблема исчезает в пассивном режиме, это должна быть ошибка в параллельных фазах и/или барьерах. Запуск с разными компиляторами: -Xint (только интерпретатор), -XX:TieredStopAtLevel=1 (только C1), -XX:-TieredCompilation (только интерпретатор и C2) — чтобы проанализировать, какие режимы не работают, а какие нет. Это покажет, связана ли проблема с обработкой барьеров или оптимизацией в интерпретаторе, C1 или C2. Обычно это полезно комбинировать со сборками fastdebug, потому что компиляторы тоже что-то утверждают. Запустите с -XX:ShenandoahGCHeuristics=aggressive. Эта эвристика запускает последовательные сборщики мусора и очищает все непустые регионы. Поскольку Shenandoah выполняет большую часть тяжелой работы сборщика мусора одновременно, это не блокирует выполнение приложения, хотя сборщик мусора в этом режиме потребляет гораздо больше циклов и замедляет работу приложения. Обратите внимание, что включение Verifier в этом режиме, вероятно, снизит производительность до неприемлемого уровня. Добавьте больше проверок с помощью -XX:+ShenandoahVerifyOptoBarriers (проверяет барьеры в идеальном графе C2), -XX:VerifyStrictOopOperations (выполняет дополнительные проверки, чтобы убедиться, что сравнения oop выполняются правильно). Общие методы отладки применимы к Shenandoah: Поместите операторы регистрации в код вокруг ошибочного утверждения, чтобы лучше понять проблему. При наличии достаточного количества журналов вы можете отследить все, что произошло в сборщике. Добавьте больше утверждений вокруг подозрительных частей кода. Посмотрите определения макросов в shenandoahAsserts.hpp, чтобы узнать, какие расширенные утверждения доступны. Подключите собственный отладчик, например, gdb, попросив виртуальную машину выполнить внешнее действие в случае сбоя с помощью -XX:OnError="gdb - %p" (%p будет заменен PID процесса). Создайте простой репродуктор и передайте его разработчикам Shenandoah. Сборка из исходного кода. Это гарантирует, что вы запустите самую последнюю и лучшую версию. Некоторые функции и исправления могут быть недоступны в более старых версиях JDK. Старые версии JDK должны быть более стабильными. Добавление --enable-debug в ./configure приведет к созданию сборки «fastdebug», которая имеет больше возможностей для диагностики. Вы можете обнаружить, что загрузка рабочих областей занимает слишком много времени, особенно для рабочих областей jdk10+. В таком случае вы можете скачать архив рабочей области отсюда: https://builds.shipilev.net/workspaces/ # JDK master: $ hg clone http://hg.openjdk.java.net/jdk/jdk shenandoah # JDK 11u: $ hg clone http://hg.openjdk.java.net/jdk-updates/jdk11u shenandoah # JDK 8u: $ hg clone http://hg.openjdk.java.net/shenandoah/jdk8 shenandoah $ cd shenandoah/ # Configure and build, JDK 11+: $ sh ./configure $ make images # Configure and build, JDK 8: $ sh ./get_source.sh $ sh ./configure $ make images # Run! JDK 11+: $ build/linux-x86_64-normal-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -Xlog:gc [...][info][gc] Using Shenandoah # Run! JDK 8: $ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -XX:+UseShenandoahGC -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-shade_2016_12_19_15_52-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) Примечание. OpenJDK обычно компилируется со всеми предупреждениями, которые рассматриваются как ошибки. Более новые компиляторы могут иметь больше предупреждений, которые кодовая база еще не догнала. В таких случаях вы можете передать --disable-warnings-as-errors в ./configure. Во всех случаях для сборки из исходников необязательно, но желательно запускать тесты. Это особенно важно для платформ, выходящих за рамки тех, на которые в настоящее время нацелен Шенандоа, и/или для создания со слишком новыми или слишком старыми инструментальными цепочками. Вам понадобится jtreg для запуска тестов. -XX:+UseZGC - Сборщик мусора Z (ZGC) — это масштабируемый сборщик мусора с малой задержкой. ZGC выполняет всю дорогостоящую работу одновременно, не останавливая выполнение потоков приложений более чем на несколько миллисекунд. Он подходит для приложений, требующих низкой задержки. Время паузы не зависит от размера используемой кучи. ZGC поддерживает размер кучи от 8 МБ до 16 ТБ. Сборщик мусора Z включается с помощью параметра командной строки -XX:+UseZGC. Требует "-XX:+UnlockExperimentalVMOptions". Скоро будет полная информация по этому сборщику. -XX:+UseEpsilonGC - Не нашел информации. Общие аргументы для всех сборщиков мусора. -XX:MaxGCPauseMillis=200 - Пауза сборщика мусора в миллисекундах. -XX:ParallelGCThreads=4 - Количество потоков вашего процессора. -XX:ConcGCThreads=2 - Количество потоков вашего процессора которые будут использоваться одновременно. Аргументы -server - Выбирает оптимизацию времени выполнения серверного приложения. Серверу каталогов потребуется больше времени для запуска и «прогрева», но он будет более агрессивно оптимизирован для обеспечения более высокой пропускной способности. -client - Выбирает оптимизацию времени выполнения клиентского приложения. Приложение будет быстрее запускаться и быстрее реагировать из-за меньших накладных расходов на компиляцию. -d64 - Только для 64-битных машин. По умолчанию сервер каталогов выбирает 32-разрядную JVM независимо от архитектуры. Этот параметр следует указывать, когда требуется большая куча JVM (более 4 гигабайт) и архитектура является 64-разрядной. -XX:AggressiveHeap - Включает оптимизацию кучи Java. Это устанавливает оптимальные параметры для длительных заданий с интенсивным выделением памяти в зависимости от конфигурации компьютера (ОЗУ и ЦП). По умолчанию этот параметр отключен, и куча не оптимизирована. FPS? -XX:AggressiveOpts - Позволяет использовать агрессивные функции оптимизации производительности, которые, как ожидается, станут стандартными в следующих выпусках. По умолчанию этот параметр отключен, и экспериментальные функции повышения производительности не используются. FPS -XX:AlwaysPreTouch - Позволяет касаться каждой страницы в куче Java во время инициализации JVM. Это загружает все страницы в память перед входом в метод main(). Этот параметр можно использовать при тестировании для имитации долго работающей системы, в которой вся виртуальная память отображается на физическую память. По умолчанию этот параметр отключен, и все страницы фиксируются по мере заполнения пространства кучи JVM. -XX:DisableExplicitGC - Другой способ, которым приложения могут взаимодействовать со сборкой мусора, — явный вызов полных сборок мусора с помощью вызова System.gc(). Это может привести к выполнению основного сбора, когда в этом может не быть необходимости (например, когда будет достаточно второстепенного сбора), и, как правило, этого следует избегать. Влияние явных сборок мусора на производительность можно измерить, отключив их с помощью флага -XX:+DisableExplicitGC, который заставляет виртуальную машину игнорировать вызовы System.gc(). -XX:+ExplicitGCInvokesConcurrent - Включается по умолчанию, что означает, что будет вызываться параллельный цикл сборки мусора, а не полный сборщик мусора STW. -XX:ParallelRefProcEnabled - Включает параллельную обработку ссылок. По умолчанию эта опция отключена. -XX:PerfDisableSharedMem - Я не нашел официального документа, но кажется, что это мешает GC писать в файловой системе. -XX:UsePerfData - Включает функцию perfdata. Этот параметр включен по умолчанию, чтобы разрешить мониторинг JVM и тестирование производительности. Его отключение подавляет создание каталогов hsperfdata_userid. Чтобы отключить функцию perfdata, укажите -XX:-UsePerfData. -XX:UseCompressedOops - Отключает использование сжатых указателей. По умолчанию этот параметр включен, и сжатые указатели используются, когда размер кучи Java меньше 32 ГБ. Когда этот параметр включен, ссылки на объекты представляются как 32-битные смещения вместо 64-битных указателей, что обычно повышает производительность при запуске приложения с размерами кучи Java менее 32 ГБ. Этот вариант работает только для 64-битных JVM. -XX:+UnlockExperimentalVMOptions - Разблокирует экспериментальные возможности, нужно для многих аргументов в этом списке. -XX:+OptimizeStringConcat - Оптимизирует операции конкатенации строк, когда это возможно. -XX:+UseCompressedStrings - Использует тип byte[] для объектов String, которые могут быть представлены в чистом формате ASCII. -XX:+UseStringCache - Включает кэширование часто выделяемых строк, доступных в пуле строк. -XX:+UseLargePages - Использует большую страничную память, если она поддерживается системой; обратите внимание, что OpenJDK 7 имеет тенденцию к сбою при использовании этого параметра JVM. -XX:+UseStringDeduplication - В Java 8u20 этот параметр JVM введен для уменьшения ненужного использования памяти за счет создания слишком большого количества экземпляров одной и той же строки; это оптимизирует память кучи, уменьшая повторяющиеся значения String в один глобальный массив char[]. -XX:+UseLWPSynchronization - Устанавливает LWP (облегченный процесс) — политику синхронизации на основе, вместо синхронизации на основе потоков. -XX:LargePageSizeInBytes: - Устанавливает большой размер страницы, используемый для кучи Java; принимает аргумент в ГБ/МБ/КБ; с большими размерами страниц мы можем лучше использовать аппаратные ресурсы виртуальной памяти; однако это может привести к увеличению размера пространства для PermGen, что, в свою очередь, может привести к уменьшению размера пространства кучи Java. -XX:MaxHeapFreeRatio:16 - Устанавливает максимальный процент свободной кучи после GC, чтобы избежать сжатия. -XX:MinHeapFreeRatio:3 - Устанавливает минимальный процент свободной кучи после GC, чтобы избежать расширения; для мониторинга использования кучи вы можете использовать VisualVM, поставляемый с JDK. -XX:SurvivorRatio:6 - Соотношение размера пространства Эдем/Выживший – например, -XX:SurvivorRatio=6 устанавливает соотношение между каждым пространством выжившего и пространством Эдема как 1:6, -XX:+UseNUMA - Неоднородный доступ к памяти (NUMA) — это конструкция компьютерной памяти, используемая в многопроцессорной обработке, время доступа к памяти зависит от расположения памяти относительно процессора. -XX:-UseBiasedLocking - Существует компромисс между неконкурентной (предвзятой) пропускной способностью блокировки и безопасными точками, которые JVM делает, чтобы включать и отключать их по мере необходимости. Для рабочих нагрузок, ориентированных на задержку, имеет смысл отключить предвзятую блокировку. Аргументы для разработчиков Ведение журнала сборщика мусора Типичный пример использования: -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=< number of log files > -XX:GCLogFileSize=< file size >[ unit ] -Xloggc:/path/to/gc.log UseGCLogFileRotation указывает политику чередования файлов журнала, как и log4j, s4lj и т. д. NumberOfGCLogFiles обозначает максимальное количество файлов журнала, которое может быть записано для одного жизненного цикла приложения. GCLogFileSize указывает максимальный размер файла. Наконец, loggc обозначает его местоположение. Здесь следует отметить, что есть еще два доступных параметра JVM (-XX:+PrintGCTimeStamps и -XX:+PrintGCDateStamps), которые можно использовать для печати временной метки даты в журнале GC. Например, если мы хотим назначить максимум 100 файлов журнала GC, каждый из которых имеет максимальный размер 50 МБ, и хотим сохранить их в папке «/home/user/log/», мы можем использовать следующий синтаксис: -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M -Xloggc:/home/user/log/gc.log Однако проблема в том, что один дополнительный поток даймона всегда используется для мониторинга системного времени в фоновом режиме. Такое поведение может стать узким местом в производительности; поэтому всегда лучше не играть с этим параметром в продакшене. Обработка нехватки памяти Очень часто большое приложение сталкивается с ошибкой нехватки памяти, которая, в свою очередь, приводит к сбою приложения. Это очень важный сценарий, и его очень трудно воспроизвести для устранения проблемы. Вот почему JVM поставляется с некоторыми параметрами, которые выгружают память кучи в физический файл, который можно использовать позже для обнаружения утечек: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid<pid>.hprof -XX:OnOutOfMemoryError="< cmd args >;< cmd args >" -XX:+UseGCOverheadLimit Здесь следует отметить пару моментов: HeapDumpOnOutOfMemoryError указывает JVM сбросить кучу в физический файл в случае OutOfMemoryError. HeapDumpPath обозначает путь, по которому должен быть записан файл; можно указать любое имя файла; однако, если JVM находит тег <pid> в имени, идентификатор текущего процесса, вызвавшего ошибку нехватки памяти, будет добавлен к имени файла в формате .hprof. OnOutOfMemoryError используется для выдачи экстренных команд, которые должны быть выполнены в случае ошибки нехватки памяти; правильная команда должна использоваться в пространстве аргументов cmd. Например, если мы хотим перезапустить сервер, как только произойдет нехватка памяти, мы можем установить параметр: -XX:OnOutOfMemoryError="shutdown -r" UseGCOverheadLimit — это политика, ограничивающая долю времени, которое виртуальная машина проводит в сборке мусора, прежде чем будет выдана ошибка OutOfMemory. Изменено 5 декабря 2022 пользователем UBERROT Sapiensation_, Fordy_, kuSSya_ и 1 другой 2 2 Ссылка на комментарий
kuSSya_ Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 это лучшее, что я видел в своей жизни Ссылка на комментарий
Refli Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 как всегда нн высрал гайд про то о чем сам не ведает Ссылка на комментарий
Hello_My_Friend Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 Мне плохо Ссылка на комментарий
Umanticker Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 для чего юзеру вайма это + вся инфа тупой копипаст Ссылка на комментарий
unlqved Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 5 часов назад, UBERROT сказал: - Я хз чё эт АВЫЩЗАВЫЗЩФШАЩВЗЫФАШВФЗЫ Ссылка на комментарий
H6W_Police123 Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 Топово Ссылка на комментарий
UBERROT Опубликовано: 5 декабря 2022 Автор Поделиться Опубликовано: 5 декабря 2022 1 час назад, Refli сказал: как всегда нн высрал гайд про то о чем сам не ведает Нн ты видел чё ты написал в разработках? Такое даже дети под в слезах не пишут. 1 час назад, Umanticker сказал: для чего юзеру вайма это + вся инфа тупой копипаст Ты видимо "гений", ведь думаешь что 2+2 можна написать как-то подругому. Ссылка на комментарий
Refli Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 1 минуту назад, UBERROT сказал: под в слезах Ссылка на комментарий
UBERROT Опубликовано: 5 декабря 2022 Автор Поделиться Опубликовано: 5 декабря 2022 Только что, Refli сказал: 1 минуту назад, UBERROT сказал: под в слезах Я не користуюсь узкой розкладкою, але в тебе вже сльози, сходи валер'яночки випий чи шо Ссылка на комментарий
spyshe18plus Опубликовано: 5 декабря 2022 Поделиться Опубликовано: 5 декабря 2022 ет чувак пытался добиться максимального фпса на своем пк за две копейки и полез так глубоко......... если не рофлить с фургона то интересная статья Ссылка на комментарий
Umanticker Опубликовано: 6 декабря 2022 Поделиться Опубликовано: 6 декабря 2022 14 часов назад, UBERROT сказал: Нн ты видел чё ты написал в разработках? Такое даже дети под в слезах не пишут. f[f[f[f[[f[f[F[F[F[F[F[F[ ЭТО ТЫ ЕЩЕ БУДЕШ ЕМУ ПИСАТЬ КОГДА ТЫ В ИДЕИ ПИСАЛ ЧТО МОДЕРАТОРОВ НАДО БРАТЬ С 21 ГОДА И С ПСИХОЛОГИЧЕСКИМ ОБРАЗОВАНИЕМ ХАХАХАХАХААХААХАХАХАХ 14 часов назад, UBERROT сказал: Ты видимо "гений", ведь думаешь что 2+2 можна написать как-то подругому. че Ссылка на комментарий
FUCCELLO Опубликовано: 8 декабря 2022 Поделиться Опубликовано: 8 декабря 2022 06.12.2022 в 13:01, Umanticker сказал: МОДЕРАТОРОВ НАДО БРАТЬ С 21 ГОДА И С ПСИХОЛОГИЧЕСКИМ ОБРАЗОВАНИЕМ Там потом он отредачил кажется на ВЫСШЕЕ образование хАХАХ Ссылка на комментарий
WMI Опубликовано: 6 апреля 2023 Поделиться Опубликовано: 6 апреля 2023 это ведь кто то еще и лайкнул 06.12.2022 в 00:45, spyshe18plus сказал: полез так глубоко......... но все равно ни в чем не разобрался + просто спастил на русский Ссылка на комментарий
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас