Настройка сборок мусора для низкой задержки

Question

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

Мое собственное тестирование показывает, что задержкасамое низкое, когда молодое поколение довольно большое (например, -XX: NewRatio <3), однако я не могу примирить это с интуицией, что чем больше молодое поколение, тем больше времени нужно для сбора мусора.</p>

Приложение работает на 64-битной Linux, JDK 6.

Использование памяти составляет около 50 мегабайт долгоживущих объектов, загружаемых при запуске (= кэш данных), и оттуда это только (много) создание объектов с очень коротким сроком службы (со средней продолжительностью жизни <1 миллисекунды).</p>

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

Answer 1

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

Например (скажем, у вас был 32-битный JVM)

• 3072M куча (Xms и Xmn)
• 128 млн. Шт. (Т. Е. Xmn 2944 м.)
• MaxTenuringThreshold = 1
• SurvivorRatio = 190 (т. Е. Каждое пространство выживших составляет 1/192 от YG)
• TargetSurvivorRatio = 90 (т.е. заполнить выживших как можно больше)

Точные параметры, которые вы будете использовать для этой настройки, зависят от того, каков размер установившегося состояния вашего рабочего набора (т. Е. Сколько живого во время каждой коллекции). Размышления здесь явно противоречат нормальным правилам определения размера кучи, но тогда у вас нет приложения, которое ведет себя таким образом. Мысль заключается в том, что приложение в основном состоит из недолговечного мусора и небольшого количества статических данных, поэтому настройте jvm так, чтобы статические данные быстро передавались на хранение, а затем имели достаточно большой YG, чтобы их часто не собирали, часто минимизируя Частота пауз. Вам нужно будет многократно вертеть ручки, чтобы определить, какой размер вам подходит, и как он соотносится с размером паузы, которую вы получаете за каждую коллекцию. Например, вы можете найти более короткие, но более частые паузы YG.

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

Однако в вашем случае важен не только алгоритм сбора данных, но и место, где выделяется память. Коллектор NUMA (совместимый только с коллектором пропускной способности и активированный с помощью переключателя UseNUMA) использует наблюдение, что объект часто используется исключительно тем потоком, который его создал, и, таким образом, выделяет память соответствующим образом. Я не уверен, на чем он основан в Linux, но он использует MPO (оптимизация размещения памяти) в Solaris, некоторые подробности в одном из блогов GC guys

Поскольку вы используете 64-битную jvm, убедитесь, что вы также используете CompressedOops.

Принимая во внимание скорость выделения объектов (возможно, какая-то научная библиотека?) И время жизни, вам следует уделить внимание повторному использованию объектов. Одним из примеров того, как библиотека делает это, является javalution StackContext

Наконец, стоит отметить, что GC-паузы - это не единственные паузы STW, вы можете запустить их со сборкой 6u21 для раннего доступа , в которой есть некоторые исправления для переключателей PrintGCApplicationStoppedTime и PrintGCApplicationConcurrentTime (которые эффективно печатают время на глобальном уровне). безопасная точка и время между этими безопасными точками). Вы можете использовать флаг tracesafepointstatistics, чтобы получить некоторое представление о том, что заставляет его нуждаться в безопасной точке (иначе ни один байт-код не выполняется ни одним потоком).

Answer 2

Вы уже включили более релевантные настройки ГХ, такие как выбор параллельного алгоритма коллектора с низкой паузой?

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

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

Может быть, полезно отметить, что в «больших» чувствительных к производительности серверных приложениях я счел необходимым сократить молодое поколение в целом. Это связано с тем, что такие приложения уже должны были быть профилированы для горячих точек выделения памяти и оптимизированы, поэтому они создают несколько недолговечных объектов. Это, в свою очередь, означает, что молодое поколение перегружает кучу.

Итак, я полагаю, что сначала я сделаю эту оптимизацию, а затем посмотрю на увеличение NewRatio за пределы 8 и просмотр результата, полученного с помощью -verbose: gc, чтобы увидеть, как происходит обмен временем GC и Full GC и где оно оптимально.

Answer 3

При попытке приложений реального времени с Java настройка сборщика мусора является существенной, но есть и другие аспекты, о которых вы должны подумать (например, JIT-компилятор, таймеры, потоки, асинхронная обработка событий).

Поскольку, похоже, существует потребность в Java реального времени, Sun предоставляет спецификацию Java Real-Time System и предлагает коммерческую реализацию. Вы можете найти больше информации здесь .