Сборка мусора Java G1 в производстве - PullRequest
89 голосов
/ 12 февраля 2010

Поскольку Java 7 по умолчанию будет использовать новую сборку мусора G1, сможет ли Java обрабатывать кучу на порядок больше без предполагаемого «разрушительного» времени приостановки GC? Кто-нибудь на самом деле внедрил G1 в производство, каков был ваш опыт?

Чтобы быть справедливым, единственный раз, когда я видел действительно длинные паузы GC, это очень большие кучи, гораздо больше, чем рабочая станция. Уточнить мой вопрос; откроет ли G1 шлюз в сотни ГБ? TB

Ответы [ 16 ]

4 голосов
/ 27 августа 2010

CMS может привести к медленному снижению производительности, даже если вы работаете без накопленных объектов. Это из-за фрагментации памяти, которой G1 якобы избегает.

Миф о G1, доступном только с платной поддержкой, это всего лишь миф. Sun и теперь Oracle разъяснили это на странице JDK.

3 голосов
/ 13 июля 2012

Я недавно перенес часть Twicsy на новый сервер с 128 ГБ ОЗУ и решил использовать 1.7. Я начал использовать те же настройки памяти, что и в 1.6 (у меня есть несколько экземпляров, выполняющих различные операции, от 500 МБ кучи до 15 ГБ, а теперь и новой с 40 ГБ), и это не сработало , 1.7, похоже, использует больше кучи, чем 1.6, и за первые несколько дней у меня возникло множество проблем. К счастью, у меня было достаточно оперативной памяти, и я увеличил объем оперативной памяти для большинства моих процессов, но все еще имел некоторые проблемы. Моим обычным МО было использование очень маленького минимального размера кучи 16 м, даже с максимальной кучей в несколько гигабайт, а затем включение инкрементального сборщика мусора. Это сводило паузы к минимуму. Это сейчас не работает, и мне пришлось увеличить минимальный размер примерно до того, что я ожидал использовать в среднем в куче, и это сработало очень хорошо. У меня все еще включен инкрементальный сборщик мусора, но я буду пробовать без него. Теперь никаких пауз, и кажется, что все идет очень быстро. Итак, я думаю, что мораль этой истории в том, что ваши настройки памяти не будут идеально переводиться с 1.6 на 1.7.

2 голосов
/ 03 января 2011

G1 делает приложение намного более гибким: широта приложения повысится - приложение можно назвать «мягким в реальном времени». Это можно сделать, заменив два вида прогонов GC (мелкие второстепенные и один большой на Tenured Gen) равными маленьким.

Для более подробной информации посмотрите на это: http://geekroom.de/java/java-expertise-g1-fur-java-7/

1 голос
/ 19 декабря 2014

Я использую G1GC в Java 8, а также с Groovy (также Java 8), и я выполняю различные виды рабочих нагрузок, и в целом G1GC работает так:

  • Использование памяти очень низкое, например 100 МБ вместо 500 МБ по сравнению с настройками Java по умолчанию

  • Время отклика постоянное и очень низкое

  • Производительность между настройками по умолчанию и G1GC составляет 20% замедления при использовании G1GC в худшем случае (без настройки однопоточного приложения). Это не так много, учитывая хорошее время отклика и низкое использование памяти.

  • При запуске из Tomcat, который является многопоточным, общая производительность улучшается на 30%, а использование памяти намного ниже, а время отклика значительно ниже.

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

1 голос
/ 31 марта 2011

Я работаю с Java, для малой и большой кучи, и вопрос о GC и Full GC появляется каждый день, так как ограничения могут быть более строгими, чем другие: в определенных условиях, 0,1 секунды из GC мусорщика или Full GC, просто убейте fonctionnalité и важно иметь детализированную конфигурацию и возможности (CMS, iCMS, другие ... цель здесь - получить максимально возможное время отклика при обработке почти в реальном времени (здесь обработка в реальном времени часто 25 мс), поэтому приветствуются любые улучшения в эргономике GC и heuristique!

0 голосов
/ 25 августа 2017

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

https://bugs.openjdk.java.net/browse/JDK-8148175

JDK-8165766

JDK-8186112

...