Соответствующая настройка JVM / GC для JVM 4 ГБ с кешем 3 ГБ

Question

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

Из 4 ГБ около 3 ГБ используются для кэша (аппликативный кеш, использующий EhCache ), поэтому я ищу лучшую настройку с учетом этого.К вашему сведению, кэш статичен во время жизни приложения (загружается с диска, срок его действия не истекает), но интенсивно используется.

Я уже профилировал свое приложение , и я провел оптимизацию в отношениизапросы БД, архитектура приложения, размер кэша и т. д. * Я просто ищу советы по настройке JVM здесь .Я измерил 99% пропускной способности для сборщика мусора и 6-8-секундных пауз при запуске Full GC (примерно раз в 1 / 2ч).

Воттекущие параметры JVM:

-XX:+UseParallelGC -XX:+AggressiveHeap -Xms2048m -Xmx4096m
-XX:NewSize=64m -XX:PermSize=64m -XX:MaxPermSize=512m
-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log

Эти параметры могут быть полностью отключены, потому что они были написаны давно ... До того, как приложение стало таким большим.

Я использую Java 1.564 бита.

Видите ли вы какие-либо возможные улучшения?

Редактировать: машина имеет 4 ядра.

Answer 1

-XX: + UseParallel * Старый * GC должен ускорить полный GC на многоядерном компьютере.

Вы также можете профилировать с другими значениями NewRatio.Ваши кэшированные объекты будут жить в постоянном поколении, поэтому профилируйте его с -XX: NewRatio = 7, а затем снова с более высокими и более низкими значениями.

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

Редактировать: Пожалуйста, дайте нам знать, на какой ОС / аппаратной платформе вы развернуты.

Полные коллекции каждые 30 минут указывают на то, что старое поколение достаточно полно.Высокое значение для newRatio даст ему больше места за счет молодого поколения.Можете ли вы дать JVM более 4 г или вы ограничены этим?

Было бы также полезно узнать, каковы ваши цели / не функциональные требования.Вы хотите избежать этих 6/7-секундных пауз из-за риска более низкой пропускной способности или эти паузы являются приемлемым компромиссом для максимально возможной пропускной способности?

Если вы хотите минимизировать паузы, попробуйте сборщик CMS, удалив оба

-XX:+UseParallelGC -XX:+UseParallelOldGC 

и добавление

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

профиля с этим с различными значениями NewRatio и посмотрите, как вы попадаете.

Недостатком сборщика CMS является то, что в отличие от параллельного старого и последовательного сборщиков он не уплотняет старое поколение.Если старое поколение становится слишком фрагментированным, а второстепенная коллекция нуждается в одновременном представлении большого количества объектов старому поколению, может быть вызвана полная последовательная коллекция, что может означать длительную паузу.(Я видел это однажды в Prod, но с IBM JVM, которая вышла из памяти вместо вызова компактной коллекции!)

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

Answer 2

Я бы использовал Java 6 update 30 или 7 update 2, 64-битные, так как они намного эффективнее. например по умолчанию они используют 32-битные ссылки.

Я бы также сконфигурировал Ehcache для использования прямой памяти или файла отображения памяти, если это возможно. Это должно минимизировать влияние на GC.

Используя эти опции, можно практически исключить отпечаток кучи. например У меня есть приложение, которое использует до 180 ГБ отображенных в памяти файлов на компьютере с 16 ГБ памяти, а размер кучи составляет 6 МБ. Полный GC занимает до 11 мс при запуске вручную, но не когда-либо GC. ;)

Если вам нужен простой пример, где я отображаю файл 8 ТБ в память и обновляю его. http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html

Answer 3

Надеюсь, вы просто удалили -сервер, чтобы не раздувать сообщение, в противном случае вы должны немедленно включить его.Помимо немного более длительного времени запуска (что на самом деле не является проблемой для веб-приложения, которое должно работать несколько дней), я не вижу никакой причины использовать что-либо, кроме c2.Это может дать некоторые хорошие улучшения производительности в целом.Umn вернуться к теме:

К сожалению, лучшее, что я могу придумать, не будет работать с вашей древней JVM.Сборщик мусора G1 был в основном разработан, чтобы уменьшить задержку.Он не только пытается уменьшить количество пауз в общем, он также предлагает некоторые параметры настройки для установки целей паузы и интервалов.См. эту страницу .

Существует экспериментальный бэкпорт для java6, хотя я сомневаюсь, что он обновляется.И я больше боюсь, что никто больше не тратит время на оптимизацию GC или чего-либо еще для Java 1.5.

PS: Также будет IBM JVM и, очевидно, azul системы (хорошо, чтосерьезное предложение;)), но об этом явно не может быть и речи ... просто хотел упомянуть их.