Java CMS GC Behaviors

Ответ 1

вы не можете просто игнорировать пространства оставшихся в живых при использовании CMS. CMS не является компактирующим сборником, а это означает, что если вы (или JVM) ошибочно допустили порог владения, то вы будете постепенно рассеивать объекты, которые будут увеличивать скорость, с которой налагаются фрагменты, которые будут вызывать время, когда CMS принудительно, потому что имеет недостаточное смежное свободное пространство, доступное для обработки рекламных акций из оставшихся в живых помещений, которые будут заставлять полный цикл gc без предварительного предупреждения, и, следовательно, это полная вещь в одной паузе STW. Сколько времени это займет, будет зависеть от размера вашей кучи, но одна вещь весьма вероятна, она будет на порядки дольше, чем обычная коллекция eden.

Здесь есть еще несколько вещей:

• STW-паузы происходят не только от CMS, но и от коллекционера молодых людей.
• CMS имеет 2 фазы STW (отметка и примечание) и 3-4 параллельные фазы, 1-я фаза STW (отметка) строго односторонняя, что может вызвать проблемы (пример обсуждения этого здесь)
• Вы можете контролировать отсутствие потоков, обрабатывающих параллельные фазы.
• Вам нужно понять, как долго длится объект, это может означать использование -XX:+PrintTenuringDistribution, или вы можете просто смотреть его с помощью visualgc, как вы это делали.
• Затем вы можете настроить это с помощью -XX:SurvivorRatio, чтобы контролировать размер оставшихся в живых объектов относительно eden и -XX:MaxTenuringThreshold, чтобы контролировать, как часто объект может пережить молодую коллекцию до того, как она будет нанята.
• -XX:CMSInitiatingOccupancyFraction может использоваться для управления CMS в отношении того, насколько полно он должен быть до того, как он запустит фазу CMS (получите это неправильно, и вы сильно перепутаете)

В конечном счете вам нужно понять, какой сборщик приостанавливается, как часто, как долго и какие-либо аномальные причины этой паузы. Затем вам нужно сравнить это с размером каждого поколения, чтобы узнать, можете ли вы настроить параметры, чтобы свести к минимуму число (и/или продолжительность) пауз.

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

Одним из хороших источников сводной информации о внутренних элементах является блог Джона Масамицу. Еще одна хорошая презентация: Настройка GC в виртуальной машине Java HotSpot.

Ответ 2

Лучший способ минимизировать влияние GC - это минимизировать количество создаваемого объекта объекта. Это не всегда легко сделать или лучшее решение в целом, но это минимизирует паузы GC.

Если вы не можете создать меньше объектов, постарайтесь сделать их достаточно короткими, а пространство для эденов достаточно велико, чтобы они не покидали пространство с эденом. (Или сделать очень долговечным и повторно использованным)

• Здесь есть три пробела, eden → survivor → tenured http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

• GC пытается обеспечить достаточное свободное пространство после полного GC, а опции -ms и -mx определяют, насколько они велики (ранее известные как -Xms и -Xmx)

• Полноценный GC начинается, когда заполненное пространство заполнено, или пространство сувовика исключено (например, слишком много объектов, скопированных из пространства eden), или CMS-решения теперь являются хорошей плиткой, чтобы попытаться выполнить одновременная очистка.

• CMS только очищает пространство, на котором хранятся.

• См. мои предыдущие ответы.