Сборка мусора - алгоритм изменения коллектора - PullRequest
3 голосов
/ 15 февраля 2012

Мы запускаем наше веб-приложение Spring + Hibernate на Tomcat (Java 1.5). В настоящее время мы используем 2 ГБ пространства кучи (мне сказали, что это максимально возможный объем на 32-битных серверах Solaris, хотя на сервере всего 16 ГБ ОЗУ). Текущие JAVA_OPTS:

-XX: MaxPermSize = 512m -XX: + UseParallelGC -Xms2048m -Xmx2048m

Пространство Young Gen + Survivor составляет ~ 600 МБ, а Old Gen - 1,4 ГБ.

Есть время, когда память заполняется, и нам нужно перезапустить Tomcat. Ниже приведены наблюдения:

  1. При активной работе сервера в течение приблизительно 16 часов ГХ тратит около часа на MarkSweep (~ 300 коллекций - Old Gen) и 5-7 минут на очистку (~ 1500 коллекций - Young Gen).
  2. Бывают случаи, когда Old Gen заполняется через 10 минут, и нам нужно перезагрузить сервер. Идентификация вызывающей нить не очень удалась

Мы хотели бы перейти к следующему JAVA_OPTIONS - мне нужна информация о том, является ли это разумным выбором (среды UAT не соответствуют нагрузке Prod env, и мы не можем повторить то же самое в UAT)

  1. Добавить -Xmn1024m - Это сделано для того, чтобы объекты «Молодого поколения» не могли быть легко переведены в «Старое поколение». Есть предложения по увеличению / уменьшению этого? Кроме того, это привело бы к большему количеству юных генералов и меньшим старым генералам.

  2. -XX: + UseParallelOldGC - чтобы заставить GC Young и Old Gening запускать несколько потоков, чтобы они быстрее получали GCed.

  3. Применимо ли ограничение в 2 ГБ к серверам Solaris? Может ли куча быть увеличена до более чем 2 ГБ?

Пожалуйста, поделитесь своими мыслями по поводу вышеизложенного.

Спасибо, Midhun

1 Ответ

0 голосов
/ 16 февраля 2012

Если у вас возникла слишком большая пауза в основных коллекциях, вам следует рассмотреть возможность использования -XX:+UseConcMarkSweepGC (а также сохранение -XX:+UseParallelOldGC) для одновременного выполнения GC.

Факт использования -Xms2048m -Xmx2048m может бытьплохая идея, если эти значения не совсем хороши, вы не позволяете JVM масштабировать их (но если вы уверены, что нет проблем).В Настройка производительности Java, 2-е изд. 5 часто даются предложения о размере кучи:

  1. Установите начальный размер кучи равным максимальному размеру кучи
  2. Установите начальный размер равным размеру, необходимому для максимального количества живых объектов, и установите максимальное значение в 4 раза больше этой суммы
  3. Установите начальную кучу на максимальный размер кучи
  4. Установите начальный размер кучиот 1/10 до 1/4 максимального размера кучи
  5. Используйте начальный размер кучи по умолчанию

(Попробуйте найти лучшее для вас)

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

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