Рубрики
Без рубрики

Руководство по наиболее важным параметрам JVM

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

Автор оригинала: baeldung.

1. Обзор

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

2. Явная кучная память – Параметры Xms и Xmx

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

Вот почему мы должны указать минимальный и максимальный размер кучи. Для его достижения можно использовать следующие параметры:

-Xms[unit] 
-Xmx[unit]

Здесь unit обозначает единицу, в которой должна быть инициализирована память (обозначаемая размером кучи ). Единицы измерения могут быть помечены как ‘g’ для ГБ, ‘m’ для МБ и ‘k’ для КБ.

Например, если мы хотим назначить JVM минимум 2 ГБ и максимум 5 ГБ, нам нужно написать:

-Xms2G -Xmx5G

Начиная с Java 8, размер Metaspace не определен. Как только он достигает глобального предела, JVM автоматически увеличивает его, однако, чтобы преодолеть любую ненужную нестабильность, мы можем установить Metaspace size с помощью:

-XX:MaxMetaspaceSize=[unit]

Здесь размер метапространства обозначает объем памяти, который мы хотим присвоить Метапространству .

Согласно рекомендациям Oracle , после общей доступной памяти вторым по значимости фактором является доля кучи, зарезервированной для молодого поколения. По умолчанию минимальный размер YG составляет 1310 MB , а максимальный – unlimited .

Мы можем назначить их явно:

-XX:NewSize=[unit] 
-XX:MaxNewSize=[unit]

3. Сбор Мусора

Для лучшей стабильности приложения очень важен выбор правильного алгоритма Сборки мусора|/.

JVM имеет четыре типа реализаций GC :

  • Серийный Сборщик мусора
  • Параллельный Сборщик Мусора
  • Сборщик мусора CMS
  • Сборщик мусора G1

Эти реализации могут быть объявлены с помощью следующих параметров:

-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+USeParNewGC
-XX:+UseG1GC

Более подробную информацию о сборке мусора реализациях можно найти здесь .

4. Ведение журнала ГК

Чтобы строго контролировать работоспособность приложения, мы всегда должны проверять производительность JVM Garbage Collection . Самый простой способ сделать это-зарегистрировать активность GC в удобочитаемом формате.

Используя следующие параметры, мы можем регистрировать активность GC :

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=< number of log files > 
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log

UseGCLogFileRotation указывает файл журнала rollingpolicy, очень похожий на log4j, s4lj и т. Д. NumberOfGCLogFiles обозначает максимальное количество файлов журнала, которые могут быть записаны за один жизненный цикл приложения. GCLogFileSize указывает максимальный размер файла. Наконец, логика обозначает его местоположение.

Здесь следует отметить, что есть еще два доступных параметра JVM ( -XX:+PrintGCTimeStamps и -XX:+PrintGCDateStamps ), которые можно использовать для печати временной метки по дате в журнале GC .

Например, если мы хотим назначить максимум 100 GC log файлов, каждый из которых имеет максимальный размер 50 МБ, и хотим сохранить их в ‘ home/user/log/’/location, мы можем использовать следующий синтаксис: 

-XX:+UseGCLogFileRotation  
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=50M 
-Xloggc:/home/user/log/gc.log

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

5. Обработка нехватки памяти

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

Вот почему JVM поставляется с некоторыми параметрами, которые сбрасывают память кучи в физический файл, который может быть использован позже для обнаружения утечек:

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=./java_pid.hprof
-XX:OnOutOfMemoryError="< cmd args >;< cmd args >" 
-XX:+UseGCOverheadLimit

Здесь следует отметить несколько моментов:

  • HeapDumpOnOutOfMemoryError инструктирует JVM сбрасывать кучу в физический файл в случае OutOfMemoryError
  • HeapDumpPath обозначает путь, по которому должен быть записан файл; может быть задано любое имя файла; однако, если JVM найдет в имени тег , идентификатор процесса текущего процесса, вызывающего ошибку нехватки памяти, будет добавлен к имени файла в формате .hprof
  • OnOutOfMemoryError используется для выдачи аварийных команд, которые должны быть выполнены в случае outofmemoryerror; правильная команда должна использоваться в пространстве cmd args. Например, если мы хотим перезапустить сервер, как только произойдет нехватка памяти, мы можем установить этот параметр:
-XX:OnOutOfMemoryError="shutdown -r"
  • UseGCOverheadLimit – это политика, ограничивающая долю времени виртуальной машины, которое тратится в GC до появления ошибки OutOfMemory

6. 32/64 Бит

В среде операционной системы, где установлены как 32 -, так и 64-разрядные пакеты, JVM автоматически выбирает 32-разрядные пакеты среды.

Если мы хотим установить среду на 64 бит вручную, мы можем сделать это с помощью приведенного ниже параметра:

-d

Бит ОС может быть любым 32 или 64 . Более подробную информацию об этом можно найти здесь .

7. Разное

  • -server : включает “Server Hotspot VM”; этот параметр используется по умолчанию в 64-битной JVM
  • -XX:+UseStringDeduplication : Java 8u20 ввела этот параметр JVM для уменьшения ненужного использования памяти путем создания слишком большого количества экземпляров одной и той же строки; это оптимизирует память кучи путем уменьшения повторяющихся String значений до одного глобального массива char[]
  • -XX:+UseLWPSynchronization : устанавливает LWP ( Облегченный процесс ) политику синхронизации на основе потоков вместо потоковой синхронизации
  • -XX:LargePageSizeInBytes : устанавливает большой размер страницы, используемый для кучи Java; он принимает аргумент в ГБ/МБ/КБ; при больших размерах страниц мы можем лучше использовать аппаратные ресурсы виртуальной памяти; однако это может привести к увеличению размера пространства для PermGen , что, в свою очередь, может заставить уменьшить размер пространства кучи Java.
  • -XX:MaxHeapFreeRatio : устанавливает максимальный процент свободной кучи после GC , чтобы избежать сжатия.
  • -XX:MinHeapFreeRatio : устанавливает минимальный процент свободной кучи после GC , чтобы избежать расширения; для мониторинга использования кучи вы можете использовать VisualVM , поставляемый вместе с JDK.
  • -XX:SurvivorRatio : Ratio of eden survivor space size – например, -XX:SurvivorRatio=6 устанавливает соотношение между каждым survivor space и eden space равным 1:6,
  • -XX:+UseLargePages : используйте большую память страниц, если она поддерживается системой; обратите внимание, что OpenJDK 7 имеет тенденцию к сбою при использовании этого параметра JVM
  • -XX:+UseStringCache : включает кэширование обычно выделяемых строк, доступных в пуле String
  • -XX:+UseCompressedStrings : use a byte[] type for String objects which can be represented in pure ASCII format
  • -XX:+OptimizeStringConcat : он оптимизирует String операции конкатенации там, где это возможно

8. Заключение

В этой краткой статье мы узнали о некоторых важных параметрах JVM, которые можно использовать для настройки и повышения общей производительности приложений.

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

Если вы хотите изучить справочные параметры более подробно, вы можете начать работу здесь .

Читайте ещё по теме: