Настройка сборок "мусора" для низкой задержки
Я ищу аргументы относительно того, как лучше всего измерить молодое поколение (относительно старого поколения) в среде, где низкая задержка очень важна.
Мое собственное тестирование имеет тенденцию показывать, что задержка является самой низкой, когда молодое поколение является довольно большим (например,-XX:NewRatio <3), однако я не могу согласовать это с интуицией это, чем больше молодое поколение, тем больше времени должно потребоваться для сборки "мусора".
Выполнение приложения на Linux 64 бита, jdk 6.
Использование памяти составляет приблизительно 50 мегабайтов долговечных объектов, загружаемых при запуске (=data кэш), и оттуда это - только (много) очень недолгие создаваемые объекты (со средней продолжительностью жизни <1 миллисекунда).
Некоторый цикл сборки "мусора" берет больше чем 10 миллисекунд для выполнения..., который взгляды действительно диспропорционируют по сравнению с задержкой приложения, которая является снова несколькими millisecs в максимум.
3 ответа
Для приложения, которое генерирует много недолговечного мусора и ничего долгоживущего, тогда один подход, который может работать, - это большая куча, почти все это молодое поколение и почти все это eden и tenure. который не раз уцелел в коллекции YG.
Например (допустим, у вас 32-битная jvm)
- 3072M куча (Xms и Xmn)
- 128M временных (т.е. Xmn 2944m)
- MaxTenuringThreshold = 1
- SurvivorRatio = 190 (т.е. каждый выживший пространство составляет 1/192 от YG)
- TargetSurvivorRatio = 90 (т.е.заполните этих оставшихся в живых как можно больше)
Точные параметры, которые вы будете использовать для этой настройки, зависят от того, каков размер в устойчивом состоянии вашего рабочего набора (то есть сколько осталось живых на момент каждой коллекции). Представленное здесь мышление явно идет вразрез с обычными правилами определения размера кучи, но тогда у вас нет приложения, которое ведет себя подобным образом. Считается, что приложение в основном представляет собой кратковременный мусор и немного статических данных, поэтому настройте jvm так, чтобы эти статические данные быстро попадали на хранение, а затем имели достаточно большой YG, чтобы он не собирался часто, таким образом минимизируя частота пауз. Вам нужно будет несколько раз поворачивать ручки, чтобы понять, какой размер вам подходит, и как это соотносится с размером паузы, которую вы получаете для каждой коллекции. Например, вы можете найти более короткие, но более частые паузы YG.
Вы не говорите, как долго работает ваше приложение, но здесь цель состоит в том, чтобы вообще не иметь постоянных коллекций в течение всего срока существования приложения. Конечно, это может быть невозможно, но к этому стоит стремиться.
Однако в вашем случае важен не только алгоритм сбора, но и то, где выделяется память. Сборщик NUMA (совместимый только с сборщиком пропускной способности и активируемый с помощью переключателя UseNUMA) использует наблюдение, что объект часто используется исключительно потоком, который его создал, и, таким образом, соответственно выделяет память. Я не уверен, на чем он основан в Linux, но он использует MPO (оптимизацию размещения памяти) в Solaris, некоторые подробности в одном из блогов разработчиков GC
Поскольку вы используете 64-битную jvm, убедитесь, что вы тоже используем CompressedOops.
Учитывая скорость выделения объектов (возможно, своего рода научную библиотеку?) И время жизни, вам следует уделить некоторое внимание повторному использованию объектов. Одним из примеров такой библиотеки является javalution StackContext
Наконец, стоит отметить, что паузы сборщика мусора - не единственные паузы STW, вы можете запустить его со сборкой раннего доступа 6u21 , которая содержит некоторые исправления для переключателей PrintGCApplicationStoppedTime и PrintGCApplicationConcurrentTime (которые эффективно распечатывают время в глобальной точке сохранения и время между этими точками сохранения). Вы можете использовать флаг tracesafepointstatistics, чтобы получить некоторое представление о том, что заставляет его нуждаться в точке безопасности (иначе говоря, ни один поток не выполняет ни одного байтового кода).
Вы уже включили более важные настройки GC, например, выбрали алгоритм параллельного сборщика с низкой паузой?
В целом, размер молодого, постоянного и старого поколений должен соответствовать профилю вашего приложения. Если у вас много короткоживущих объектов, а размер young слишком мал, многие объекты станут постоянными, что заставит чаще собирать все постоянное поколение. Аналогично, если young слишком велико, то tenured обязательно будет меньше, и это может вынудить часто делать крупные коллекции tenured.
Практически говоря, я думаю, вы обнаружите, что время, затрачиваемое на мелкие и крупные коллекции, уравновешивается по мере увеличения размера молодого поколения и в какой-то момент становится оптимальным.
Возможно, будет полезно отметить, что в "больших" серверных приложениях, чувствительных к производительности, я обнаружил необходимость уменьшения молодого поколения, в целом. Это происходит потому, что такие приложения должны быть уже профилированы на предмет "горячих точек" распределения памяти и оптимизированы, поэтому они производят мало короткоживущих объектов. Это, в свою очередь, означает, что молодое поколение занимает слишком много кучи.
Поэтому я полагаю, что сначала я бы сделал эту оптимизацию, затем посмотрел бы на увеличение NewRatio выше 8, и посмотрел бы на вывод, выдаваемый -verbose:gc, чтобы увидеть, как распределяется время GC и Full GC и где оно оптимально.
При попытке приложений реального времени с Java настройка сборки мусора имеет важное значение. но есть и другие аспекты, о которых вам нужно подумать (например, JIT-компилятор, таймеры, многопоточность, асинхронная обработка событий).
Поскольку кажется, что существует спрос на Java реального времени, Sun предоставляет спецификацию системы реального времени Java и коммерческую реализацию. Дополнительную информацию можно найти здесь .