Быстрый компромисс между опциями Java -Xms и -Xmx

StackOverflow https://stackoverflow.com/questions/1043817

  •  20-08-2019
  •  | 
  •  

Вопрос

Учитывая эти две команды

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B:

$ java -Xms5G -Xmx5G myjavacode input.txt

У меня есть два вопроса:

  1. Поскольку команда A резервирует больше памяти для своих параметров, будет ли A выполняться быстрее, чем B?
  2. Как сделать -Xmx и -Xms повлиять на запущенный процесс и выходные данные моей программы?
Это было полезно?

Решение

Это зависит от GC, который использует ваша java.Параллельные GCS могли бы работать лучше при больших настройках памяти - хотя я не эксперт в этом.

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

Другие советы

В -Xmx аргумент определяет максимальный размер памяти, который может быть доступен куче для JVM.Вы должны хорошо знать свою программу и видеть, как она работает под нагрузкой, и соответствующим образом установить этот параметр.Низкое значение может привести к Исключения из памяти или очень низкая производительность, если объем памяти кучи вашей программы достигает максимального размера кучи.Если ваша программа запущена на выделенном сервере, вы можете установить этот параметр выше, потому что это не повлияет на другие программы.

В -Xms аргумент задает начальный размер памяти кучи для JVM.Это означает, что при запуске вашей программы JVM мгновенно выделит этот объем памяти.Это полезно, если ваша программа с самого начала будет потреблять большой объем оперативной памяти.Это позволяет избежать постоянного увеличения кучи JVM и может повысить там некоторую производительность.Если вы не знаете, поможет ли вам этот параметр, не используй это.

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

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

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

Решение состояло в том, чтобы удалить старые объекты из сеанса.

Стюарт

  1. Распределение всегда зависит от вашей операционной системы.Если вы выделите слишком много памяти, вы могли бы в конечном итоге загрузить части в swap, что действительно происходит медленно.
  2. Будет ли ваша программа работать медленнее или быстрее, зависит от ссылок, которые виртуальная машина должна обрабатывать и очищать.GC не нужно просматривать выделенную память, чтобы найти заброшенные объекты.Он знает, что это за объекты и объем памяти, который они выделяют, путем сопоставления ссылок.Таким образом, подметание зависит только от размера ваших объектов.Если ваша программа ведет себя одинаково в обоих случаях, единственное влияние на производительность должно быть при запуске виртуальной машины, когда виртуальная машина пытается выделить память, предоставляемую вашей операционной системой, и если вы используете swap (что снова приводит к 1).

Трудно сказать, как распределение памяти повлияет на вашу скорость.Это зависит от алгоритма сборки мусора, используемого JVM.Например, если вашему сборщику мусора необходимо сделать паузу, чтобы выполнить полную сборку, то если у вас на 10 больше памяти, чем вам действительно нужно, то сборщику нужно будет очистить на 10 больше мусора.

Если вы используете java 6, вы можете использовать jconsole (в каталоге bin jdk) для подключения к вашему процессу и наблюдения за поведением сборщика.В целом коллекторы очень умные, и вам не нужно будет выполнять какую-либо настройку, но если у вас возникнет необходимость, есть множество опций, которые вы можете использовать для дальнейшей настройки процесса сбора.

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

В -X опции являются нестандартными и могут быть изменены без предварительного уведомления.

(копировать-вставить)

Этот вопрос всегда возникал у меня, когда я работал над одним из своих приложений, которое создавало огромное количество потоков на запрос.

Так что это действительно хороший вопрос, и в этом есть два аспекта:
1.Должно ли мое значение Xms и Xmx быть одинаковым
       - Большинство веб-сайтов и даже документы Oracle предполагают, что это одно и то же.Однако я предлагаю иметь примерно 10-20% буфера между этими значениями, чтобы предоставить вашему приложению возможность изменять размер кучи в случае внезапных скачков трафика ИЛИ случайной утечки памяти.

2.Должен ли я запускать свое приложение с меньшим размером кучи
       - Итак, вот в чем дело - независимо от того, какой алгоритм GC вы используете (даже G1), в большой куче всегда есть какой-то компромисс.Цель состоит в том, чтобы определить поведение вашего приложения, до какого размера кучи вы можете разрешить паузы GC с точки зрения задержки и пропускной способности.
              - Например, если в вашем приложении много потоков (каждый поток имеет 1 МБ стека в собственной памяти, а не в куче), но не занимает много места на объектах, тогда я предлагаю использовать меньшее значение Xms.
              - Если ваше приложение создает много объектов с увеличивающимся количеством потоков, то определите, на какое значение Xms вы можете установить, чтобы допускать эти паузы STW.Это означает, что определите максимальное время отклика на ваши входящие запросы, которое вы можете выдержать, и в соответствии с этим настройте минимальный размер кучи.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top