Компромисс скорости использования опций Java -Xms и -Xmx

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

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

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

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

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

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

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

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

Стюарт

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

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

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

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

Этому вопросу 11 лет, и с тех пор влияние параметров JVM на производительность стало еще труднее предсказать заранее. Таким образом, вы можете попробовать разные значения и увидеть их влияние на производительность или использовать бесплатный инструмент, например Optimizer Studio, который автоматически найдет оптимальные значения параметров JVM.

> 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 быть одинаковыми
- Большинство веб-сайтов и даже документы оракула предлагают, чтобы они были одинаковыми. Однако я предлагаю иметь 10-20% буфера между этими значениями, чтобы дать вашему приложению возможность изменять размер кучи на случай внезапных скачков трафика ИЛИ случайной утечки памяти.

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