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

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

EDIT: Linux Ubuntu 64-бит:

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)
10
garbage-collection java memory optimization

3 ответов

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

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

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

8

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

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

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

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

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

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

7

чтобы правильно настроить GC, вам нужно понять жизненный цикл объекта в вашем приложении. Как уже упоминалось, простых ответов не существует. То, что сработало для меня, - это определение размера молодого поколения, поэтому большинство объектов умирают там и используют 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 для просмотра статистики на коллекционер.

2