Так как Java 7 собирается использовать новую сборку мусора G1 по умолчанию, Java сможет обрабатывать на порядок большую кучу без предполагаемых "разрушительных" периодов паузы GC? Кто-нибудь действительно реализовал G1 в производстве, каковы были ваши впечатления?
Чтобы быть справедливым, единственный раз, когда я видел действительно длительные паузы GC, находится на очень больших кучах, намного больше, чем у рабочей станции. Прояснить мой вопрос; G1 откроет шлюз для кучи в сотнях GB? ТБ?
Похоже, что точка G1 должна иметь меньшее время паузы, даже до того момента, когда у нее есть возможность указать максимальную цель времени паузы.
Сбор мусора - это не просто "Эй, он полный, пусть все перемещается и начинает больше" - это фантастически сложная многоуровневая система с фоновым потоком. Он может выполнять большую часть своего обслуживания в фоновом режиме без каких-либо пауз, а также использует знания о системных ожидаемых шаблонах во время выполнения, чтобы помочь - например, если большинство объектов умирают сразу после создания и т.д.
Я бы сказал, что времена паузы GC продолжат улучшаться, а не ухудшаться, с будущими выпусками.
EDIT:
при повторном чтении мне пришло в голову, что я использую Java ежедневно - Eclipse, Azureus и приложения, которые я разрабатываю, и это было ДЛИТЕЛЬНОЕ ВРЕМЯ с тех пор, как я увидел паузу. Не значительная пауза, но я имею в виду любую паузу.
Я видел паузы, когда я нажимаю правой кнопкой мыши на Windows Explorer или (иногда), когда я подключаю определенное USB-оборудование, но с Java --- вообще нет.
Есть ли проблема с кем-то еще?
Я тестировал это с помощью тяжелого приложения: 60-70 ГБ выделяется в кучу, при использовании 20-50 ГБ в любое время. При таких видах приложений преуменьшение можно сказать, что ваш пробег может отличаться. Я запускаю JDK 1.6_22 в Linux. Малые версии важны - примерно до 1.6_20, в G1 были ошибки, вызвавшие случайные NullPointerExceptions.
Я обнаружил, что очень хорошо держать в пределах целевой паузы, которую вы даете ей большую часть времени. По умолчанию используется пауза в 100 мс (0,1 секунды), и я рассказываю ей сделать это наполовину (-XX: MaxGCPauseMillis = 50). Однако, как только он становится очень низким в памяти, он паникует и делает полную сборку мусора в мире. С 65 ГБ это занимает от 30 секунд до 2 минут. (Количество процессоров, вероятно, не имеет значения, вероятно, ограничено скоростью шины.)
По сравнению с CMS (который не является GC сервера по умолчанию, но он должен быть для веб-серверов и других приложений реального времени), типичные паузы намного более предсказуемы и могут быть значительно короче. До сих пор мне повезло с CMS за огромные паузы, но это может быть случайным; Я вижу их всего несколько раз каждые 24 часа. Я не уверен, какой из них будет более уместным в моей производственной среде на данный момент, но, вероятно, G1. Если Oracle продолжит настраивать его, я подозреваю, что G1 в конечном итоге станет явным победителем.
Если у вас нет проблем с существующими сборщиками мусора, нет никаких оснований рассматривать G1 прямо сейчас. Если вы используете приложение с малой задержкой, такое как приложение с графическим интерфейсом, G1, вероятно, является правильным выбором, при этом MaxGCPauseMillis устанавливается очень низко. Если вы используете пакетное приложение, G1 ничего не покупает.
Хотя я не тестировал G1 на производстве, я думал, что буду комментировать, что GC уже проблематичны для случаев без "гуманных" куч. В частности, услуги GC с помощью, например, 2 или 4 концертов могут серьезно пострадать от GC. Молодые генераторы GC обычно не проблематичны, так как они заканчиваются в миллисекундах (или, самое большее, двузначных). Но коллекции старого поколения гораздо более проблематичны, так как они занимают несколько секунд со старыми размерами 1 гига или выше.
Теперь: теоретически CMS может многое помочь, поскольку он может выполнять большую часть своей работы одновременно. Однако со временем будут случаи, когда он не сможет этого сделать и должен вернуться к коллекции "остановить мир". И когда это произойдет (после, скажем, 1 час - не часто, но все же слишком часто), хорошо, держитесь за свои шляпы. Это может занять минуту или больше. Это особенно проблематично для служб, которые пытаются ограничить максимальную задержку; вместо того, чтобы принимать, скажем, 25 миллисекунд, чтобы выполнить запрос, теперь он занимает десять секунд или больше. Чтобы добавить травму к оскорблениям, клиенты часто будут выходить из запроса и повторять попытку, приводя к дальнейшим проблемам (иначе это "дерьмовая буря" ).
Это одна из областей, где G1 надеялся много помочь. Я работал в большой компании, предлагающей облачные сервисы для хранения и отправки сообщений; и мы не могли использовать CMS, поскольку, хотя большую часть времени он работал лучше, чем параллельные сорта, у него были эти кризисы. Так что около часа все было хорошо; а затем материал попал в вентилятор... и потому, что сервис был основан на кластерах, когда один из node попал в неприятности, другие обычно следуют (поскольку таймауты, вызванные GC, приводят к другим узлам, верят, что node разбился, маршруты).
Я не думаю, что GC - это большая проблема для приложений, и, возможно, даже некластеризованные службы реже затрагиваются. Но все больше и больше систем кластеризованы (особенно благодаря хранилищам данных NoSQL), а размеры кучи растут. GC OldGen супер-линейно связаны с размером кучи (это означает, что размер кучи удвоения более чем удваивает время GC, при условии, что размер набора данных в реальном времени также удваивается).
Azul CTO, Gil Tene, имеет хороший обзор проблем, связанных с Garbage Collection, и обзор различных решений в его Понимание коллекции мусора Java и What You Can Do It About, а также дополнительные подробности в этой статье: http://www.infoq.com/articles/azul_gc_in_detail.
Сборщик мусора Azul C4 в нашей Zing JVM является одновременно параллельным и параллельным и использует тот же механизм GC как для нового, так и для старого поколения, одновременно работая и уплотняя в обоих случаях. Самое главное, что у C4 нет отставания в мире. Все уплотнения выполняются одновременно с запущенным приложением. У нас есть клиенты, которые работают очень большими (сотни ГБ) с худшим временем паузы GC в & 10 мс, и в зависимости от приложения часто раз меньше 1-2 мсек.
Проблема с CMS и G1 заключается в том, что в какой-то момент память кучи Java должна быть уплотнена, и обе эти сборщики мусора останавливают-мир/STW (т.е. приостанавливают приложение) для выполнения уплотнения. Поэтому, хотя CMS и G1 могут вытеснить паузы STW, они не устраняют их. Однако Azul C4 полностью устраняет паузы STW и почему Zing имеет такие низкие GC-паузы даже для гигантских размеров кучи.
И чтобы исправить утверждение, сделанное в более раннем ответе, Zing не требует никаких изменений в операционной системе. Он работает так же, как и любая другая JVM на немодифицированных дистрибутивах Linux.
Мы уже используем G1GC, начиная с почти двух лет. Он отлично справляется с нашей критически важной операцией по обработке транзакций, и он оказался отличной поддержкой w.r.t высокой пропускной способностью, низкими паузами, concurrency и оптимизированным управлением большой памятью.
Мы используем следующие настройки JVM:
-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
Обновление
-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000
Коллектив G1 уменьшает влияние полных коллекций. Если у вас есть приложение, в котором вы уже сократили потребность в полных коллекциях, коллекционная коллекция Sweep Collector так же хороша и по моему опыту имеет более короткие минимальные времена сбора.
Кажется, что запуск G1 JDK7u4, наконец, официально поддерживается, см. RN для JDK7u4 http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html.
Из нашего тестирования еще для больших JVM настроенная CMS все еще действует лучше, чем G1, но я думаю, что она будет расти лучше.
CMS может привести к снижению производительности, даже если вы используете его, не накапливая объекты с сохранением целостности. Это из-за фрагментации памяти, которую G1 якобы избегает.
Миф о G1, доступный только при платной поддержке, - это просто миф. Sun и теперь Oracle разъяснили это на странице JDK.
Недавно меня перенесли из
CMS для G1GC с кучей 4G и 8-ядерным процессором на серверах с JDK 1.7.45.
(JDK 1.8.x G1GC предпочтительнее более 1,7, но из-за некоторых ограничений я должен придерживаться версии 1.7.45)
Я сконфигурировал ниже ключевые параметры и сохранил все остальные параметры по умолчанию.
-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n apart from -Xms and -Xmx
Если вы хотите точно настроить эти параметры, посмотрите на эту статью oracle.
Ключевые наблюдения:
Но все же я рад, что время паузы Max GC меньше, чем у CMS. Я установил время паузы Max GC как 1,5 секунды, и это значение еще не было перечеркнуто.
Связанный вопрос SE:
G1 GC должен работать лучше. Но если установка -XX: MaxGCPauseMillis слишком агрессивно, мусор будет собираться слишком медленно. И вот почему полный GC вызван в примере Дэвида Леппика.
Недавно я перенес часть Twicsy на новый сервер с 128 ГБ оперативной памяти и решил использовать 1.7. Я начал использовать все те же настройки памяти, что и с 1.6 (у меня есть несколько экземпляров, выполняющих разные вещи, от 500 мб кучи до 15 ГБ, а теперь новый с 40 ГБ), и это совсем не сработало, 1.7, похоже, использует больше кучи, чем 1,6, и я испытал много проблем в течение первых нескольких дней. У меня, к счастью, было много оперативной памяти для работы и нажимала RAM для большинства моих процессов, но у меня все еще были проблемы. Моя нормальная МО должна была использовать очень малую минимальную кучу размером 16 м, даже с максимальной кучей в несколько гигабайт, а затем включить инкрементный GC. Это сдерживало паузы. Однако это не работает, и мне пришлось увеличить минимальный размер до того, что я ожидал использовать в среднем в куче, и это получилось очень хорошо. У меня все еще есть инкрементный GC включен, но я буду пытаться его без него. Теперь нет пауз, и все, кажется, работает очень быстро. Итак, я думаю, что мораль этой истории не предполагает, что ваши настройки памяти будут отлично переведены с 1,6 до 1,7.
Я только что реализовал G1 Garbage Collector в нашем проекте Terracotta Big Memory. Работая над различными типами коллекционеров, G1 дал нам лучшие результаты с временем ответа менее 600 мс.
Вы можете найти результаты теста (всего 26) здесь
Надеюсь, что это поможет.
G1 делает приложение намного более гибким: латентность приложения будет повышаться - приложение можно назвать "мягким в реальном времени". Это делается путем замены двух видов GC-прогонов (небольших младших и одного большого на Tenured Gen) на небольшие размеры.
Подробнее об этом смотрите: http://geekroom.de/java/java-expertise-g1-fur-java-7/
Я работаю с Java, для маленькой и большой кучи, и вопрос о GC и Full GC появляется каждый день, поскольку ограничения могут быть более строгими, чем другие: в определенной среде, 0,1 секунды от мусорщика GC или Full GC, убейте просто fonctionnalité, и у вас есть мелкозернистая конфигурация и возможности (CMS, iCMS, другие... цель здесь - получить максимально возможное время отклика при лечении в реальном времени (здесь лечение в режиме реального времени часто 25 мс), поэтому, в принципе, любые улучшения в эргономике GC и heuristique приветствуются!
Я использую G1GC на Java 8, а также с Groovy (также Java 8), и я занимаюсь различными видами рабочих нагрузок, и, в сущности, G1GC работает следующим образом:
Использование памяти очень низкое, например. 100 Мбайт вместо 500 МБ по сравнению со стандартными настройками Java
Время ответа согласованное и очень низкое
Производительность между настройками по умолчанию и G1GC составляет 20% -ное замедление при использовании G1GC в худшем случае (без настройки однопоточного приложения). Это не так много, учитывая хорошее время отклика и низкое использование памяти.
При работе с многопоточным Tomcat общая производительность на 30% лучше, а использование памяти намного ниже, а время ответа намного ниже.
Таким образом, в целом при использовании действительно различных рабочих нагрузок G1GC - очень хороший сборщик для Java 8 для многопоточных приложений, и даже для однопоточных есть некоторые преимущества.
Не рекомендуется использовать java8 w/G1GC для вычисления точки с плавающей точкой с помощью JVM с подобной точкой доступа. Это опасно для целостности и точности применения.
https://bugs.openjdk.java.net/browse/JDK-8148175
JDK-8165766
JDK-8186112