Скоростная компиляция вариантов Java -Xms и -Xmx

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

А:

$ java -Xms10G -Xmx10G myjavacode input.txt

В:

$ java -Xms5G -Xmx5G myjavacode input.txt

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Стюарт

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

(копипаст)

Ответ 7

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

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

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