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

Question

С учетом этих двух команд

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B

$ java -Xms5G -Xmx5G myjavacode input.txt

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Решением было исключить старые объекты из сеанса.

Stuart

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

> 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 нестандартны и могут быть изменены без предварительного уведомления.

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