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

Question

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

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

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

• Java 6 (runnign в 64-битном режиме)
• 4-ядерный Xeon
• RHEL4, 64-разрядная
• весна, спящий
• Высокий уровень дискового и сетевого ввода-вывода

РЕДАКТИРОВАТЬ : Я старался не публиковать конфигурацию моей JVM, но ясно, что это делает вопрос смехотворно открытым. Итак, здесь мы идем с соответствующими параметрами конфигурации:

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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