Какова наилучшая конфигурация GC и памяти для системы реального времени, которая хочет минимизировать задержку GC на обычной виртуальной машине Sun / Oracle Hotspot?

Question

Вопрос в значительной степени говорит сам за себя.Какие поддерживаемые JVM GC следует использовать и с какой конфигурацией, чтобы минимизировать влияние GC в приложении?

РЕДАКТИРОВАТЬ: 64-битная версия Linux Ubuntu:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Answer 1

Начиная с J2SE 5.0, параллельный сборщик выбран по умолчанию на машинах серверного класса, как подробно описано в документе Эргономика сборщика мусора. Кроме того, в параллельном коллекторе используется метод автоматической настройки , который позволяет указывать желаемое поведение вместо размеров генерации и других низкоуровневых параметров настройки. Можно указать следующие варианты поведения:

Максимальное время приостановки сбора мусора пропускная способность Footprint (т.е. размер кучи) Максимальное время паузы задается параметром командной строки -XX: MaxGCPauseMillis =. Это интерпретируется как подсказка, что желательны времена паузы в миллисекундах или меньше; по умолчанию нет максимальной цели паузы. Если задана цель времени паузы, размер кучи и другие параметры , связанные с сборкой мусора, корректируются в попытке сделать паузы сбора мусора короче указанного значения . Обратите внимание, что эти настройки могут привести к снижению общей пропускной способности приложения сборщиком мусора, и в некоторых случаях желаемое время ожидания не может быть достигнуто.

Выдержка из http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.ergonomics

Answer 2

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

Если вам нужна производительность в реальном времени (в прямом смысле этого слова), вам нужна Java VM, которая реализует расширения RTSJ в реальном времени. Эта страница , в которой перечислены некоторые реализации. Обратите внимание, что для получения производительности в реальном времени на уровне приложений Java вам также необходимо работать на платформе ОС с поддержкой реального времени.

---

С другой стороны, если вы просто хотите собирать мусор с малой паузой без каких-либо серьезных гарантий производительности в реальном времени, тогда в документах по настройке GC Oracle объясняется, как это сделать. См. Ответ Чака Фрикано.

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

Нет простых ответов.

И, конечно же, не существует универсальной конфигурации, позволяющей минимизировать задержку. Даже для конкретной версии JVM, операционной системы и аппаратной платформы.

Answer 3

Для правильной настройки ГХ вам необходимо понять жизненный цикл объекта в вашем приложении.Как уже упоминалось, нет простых ответов.Для меня сработало определение размера молодого поколения, чтобы большинство объектов умирали там, используя CMS и устанавливая начальную дробь, чтобы она не работала постоянно.Вот мои параметры:

-server -Xms4000M -Xmx4000M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:MaxTenuringThreshold=4 -XX:MaxNewSize=384m -XX:NewSize=384m -XX:SurvivorRatio=12 -Xloggc:/opt/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Вы также можете использовать сторонние утилиты для анализа файлов журнала GC для просмотра статистики по сборщику.