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

64

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

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B:

$ java -Xms5G -Xmx5G myjavacode input.txt

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

Since command A reserves more memory with its parameters, will A run faster than B? How do -Xmx and -Xms affect the running process and the output of my program?
Я спросил сопровождающего пакета JVM, и он сказал: «В Linux я не уверен, что -Xms делает очень много, если у вас нет странной настройки. Может быть, он выделяется без MAP_NORESERVE просто для того, чтобы убедиться, что оперативная память действительно есть. Но я сомневаюсь в этом. Ondra Žižka
Ответ на эти типы вопросов всегда "Оцените это и выясните". matt b
Ваш вопрос касается какой-то проблемы реального мира или это только теоретический вопрос? Потому что, если у вас столько ОЗУ в 64-битной системе, вы можете подумать об изменении своих алгоритмов, чтобы воспользоваться этим преимуществом - например, чтение / отображение всего большого input.txt в память и выполнение операций над этим. akarnokd

Ваш Ответ

7   ответов
1

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

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

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

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

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

Не отвечает на вопрос.
4

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

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

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

Стюарт

2

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

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

165

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

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

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

Можете ли вы высказать свои мысли оstackoverflow.com/questions/39652282/… а такжеstackoverflow.com/questions/39652282/… ? заранее спасибо
вы сказалиIf your program is running in dedicated server you can set this parameter higher because it wont affect other programs Я считаю, что если у нас несколько процессов, запущенных на одном узле, и если у всех установлены параметры XMx, ни один процесс не идет в другой процесс, как в Xmx, память уже зарезервирована для каждого процесса (который не может использоваться любым другим процессом) Правильно ?
3
Allocation always depends on your OS. If you allocate too much memory, you could end up having loaded portions into swap, which indeed is slow. Whether your program runs slower or faster depends on the references the VM has to handle and to clean. The GC doesn't have to sweep through the allocated memory to find abandoned objects. It knows it's objects and the amount of memory they allocate by reference mapping. So sweeping just depends on the size of your objects. If your program behaves the same in both cases, the only performance impact should be on VM startup, when the VM tries to allocate memory provided by your OS and if you use the swap (which again leads to 1.)
21

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

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

@ Майкл Боргвардт: Я думал, что описал то же самое, что и ваше второе предложение.
Эмм. Процессоры имеют оперативную память. Он называется кэш-памятью первого и второго уровня.
@jinguy: я исправлен, я имею в виду мой компьютер. neversaint
Процессоры не имеют оперативной памяти.
Общее время, затрачиваемое на сборку мусора, НЕ увеличивается с увеличением объема ОЗУ, если только у вас нет патологического случая с большим количеством заполненных сборок мусора. Обычная проблема с большим количеством ОЗУ заключается в том, что это может привести к тому, что полный сборщик мусора не будет выполняться в течение длительного времени, после чего приложение будет заблокировано, пока оно, наконец, не выполнит отложенный сборщик данных.

Похожие вопросы