Уменьшает ли JVM Sun, когда больше памяти выделяется через -Xmx?

Question

Является ли Sun JVM медленным, когда доступно больше памяти и используется через -Xmx? (Предположение: машина имеет достаточную физическую память, так что обмен виртуальной памятью не является проблемой.)

Я спрашиваю, потому что мои производственные серверы получат обновление памяти. Я хотел бы поднять значение -Xmx на что-то decadent. Идея состоит в том, чтобы предотвратить сбои в исчерпании пространства кучи из-за моих собственных ошибок программирования, которые происходят время от времени. Редкие события, но их можно было избежать с помощью моего быстро развивающегося webapp, если бы у меня было непристойное значение -Xmx, например 2048 МБ или выше. Приложение сильно контролируется, поэтому будут наблюдаться необычные всплески в потреблении памяти JVM и исправления любых дефектов.

Возможные важные детали:

• Java-6 (runnign в 64-битном режиме)
• 4-ядерный Xeon
• RHEL4 64-битный
• Спринг, Hibernate
• High диск и сеть IO

EDIT: Я попытался избежать публикации конфигурации моей JVM, но, несомненно, это делает вопрос смехотворно открытым. Таким образом, здесь мы идем с соответствующими параметрами конфигурации:

-Xms256m 
-Xmx1024m 
-XX:+UseConcMarkSweepGC 
-XX:+AlwaysActAsServerClassMachine 
-XX:MaxGCPauseMillis=1000 
-XX:MaxGCMinorPauseMillis=1000 
-XX:+PrintGCTimeStamps 
-XX:+HeapDumpOnOutOfMemoryError 

Answer 1

Добавив больше памяти, куча заполнится дольше. Следовательно, это уменьшит частоту сбора мусора. Однако, в зависимости от того, насколько смертны ваши объекты, вы можете обнаружить, что сколько времени потребуется, чтобы сделать какой-либо один GC.

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

Answer 2

Больше памяти, как правило, дает лучшую производительность в средах со сбором мусора, по крайней мере, до тех пор, пока это не приведет к виртуальному использования памяти/свопинга.

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

Я не уверен, что все еще есть сервер и клиентская виртуальная машина для 64-разрядного (есть 32 бит), поэтому вы можете также изучить это.

Answer 3

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

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

Answer 4

Согласно моему опыту, он не замедляется, но JVM пытается все время сокращать до Xms и стараться оставаться на нижней границе или близко. Поэтому, если вы можете приложить усилия, ударьте Xms. Sun рекомендует оба размера одинакового размера. Добавьте некоторый -XX: NewSize = 512m (только что составленный номер), чтобы избежать дорогостоящей накапливания старых данных в старом поколении, что ведет к более длинным/тяжелым GC на пути. Мы запускаем наше веб-приложение с 700 МБ NewSize, потому что большинство данных недолговечны.

Итак, нижняя строка: я не ожидаю замедления, но положил больше памяти на работу. Установите большую область нового размера и установите Xms в Xmx, чтобы снизить нагрузку на GC, потому что не нужно пытаться сокращать пределы Xms ...

Answer 5

Обычно это не поможет вашему результату/пропускной способности, если вы увеличиваете -Xmx. Теоретически, могут быть более длинные фазы «остановить мир», но на практике с CMS это не проблема.

Конечно, вы не должны установить -Xmx в какой-то безумной стоимости, как 300Gbyte, если вам действительно нужно это :)