Garbage Collection

[Сабина]

времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.

Замечательно!
Так сколько будем ставить - 1 гиг, 12 или 32?

У нас 16, все замечательно. Но max memory вообще то ставится в зависимости от системы и приложения

[Flash-04]

А 128 Gb не хотите?

История увеличения памяти для одного и того же приложения:
Вначале жила в 1.6Gb (больше на Win32 нельзя было дать). Потом переехало на Linux64 и пошло:
- 8Gb
- 16 Gb
- 32 Gb
- 64 Gb

(подправлено. на сервере 128Gb, но Java отдали только половину, что логично).

[anarchist]

12Gb хип?? Жава 8 вроде 1гб максимум, не?

Давно я не конфигурил Жаву.
Так мы все еще про размер хипа, или про размер физической памяти на сервере? Что то я с трудом себе представляю нахрена хип размером 12гб для Жава приложения.

[Flash-04]

Иногда и больше надо.

[iDesperado]

Какого рода приложение?

Splunk

а где там С++, если эта фигня поверх java и hadoop построена ? там веб админка, что ли на C++ ?

[Flash-04]

Здрасьте, где там Java? И Hadoop не в enterprise продукте. вы на их сайт зайдите, там плюсовые программисты нужны.

Update:
proof здесь, из первых рук так сказать: http://www.splunk.com/view/SP-CAAABF9" onclick="window.open(this.href);return false;
С++ и Python (но только для "обвязки" и внешних модулей).
Я понимаю что хотелось поумничать, но делать это не имея тесного знакомства с продуктом как-то несколько опрометчиво.

[Palych]

Иногда и больше надо.

А как вы определяете что надо больше?
В общих чертах...

[Flash-04]

Technical support говорит

[Palych]

Technical support говорит

А они поди смотрят на то сколько памяти java занимает - хватаются за голову и добавляют памяти.
А java с радостью откладывает сборку мусора наподольше, поскольку до максимума ещё далеко, и зажирает ещё больше памяти.
А support иногда пытается "спасти" ситуацию и bounce the app, что хоронит всю оптимизацию со сбором статистики, кэшами и проч.

[Flash-04]

Не-а, тупо смотрят что с 32 Gb приложение дохнет, а с 64Gb бодро работает.
С этим конкретным приложением беда в том что оно дохренища данных вынуждено держать в оперативки. Больше поток данных - больше памяти надо. Ну и тогось... Правда там насколько я понял начали сказываться дефекты самой архитектуры.

[Palych]

То есть - высота зубьев пилы не зависит от размера Xmx?

Ответ на этот вопрос не совсем прост. Но в целом не зависит. Но в G1 есть ньюанс, он чем то похож на CMS если Вы расcматриваете отдельный регион (eden gen + metadata + old gen), но в отличие от CMS у которого был только один такой регион G1 делит хип на множество таких кубиков. Там на самом деле есть threshold -XX:InitiatingHeapOccupancyPercent=45. Он говорит G1 на начальном этапе как вести себя пока статистика не набрана еще.

А можно попросить разъяснить?

XX:InitiatingHeapOccupancyPercent: Percentage of the (entire) heap occupancy to start a concurrent GC cycle. GCs that trigger a concurrent GC cycle based on the occupancy of the entire heap and not just one of the generations, including G1, use this option. A value of 0 denotes 'do constant GC cycles'. The default value is 45.

Как подсчитывается вся куча? Это Xmx или его производная?

[Сабина]

Азы:
https://static.rainfocus.com/oracle/oow ... ep2016.pdf" onclick="window.open(this.href);return false;

Отличная презентация про G1GC. тут новые фичи самые интересные
https://static.rainfocus.com/oracle/oow ... p-dive.pdf" onclick="window.open(this.href);return false;

А это мужик, который тулзы написал на которые я тут выше ссылалась. Хорошие кстати
https://static.rainfocus.com/oracle/oow ... CLogs.pptx" onclick="window.open(this.href);return false;
https://static.rainfocus.com/oracle/oow ... rbage.pptx" onclick="window.open(this.href);return false;

[Сабина]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.
По дефолту G1 впринципе работает намного лучше чем CMS который требует тонкого тюнининга. Но G1 тоже требует настройки и у него есть ахилесовы пяты: Final, Weak, Soft and etc references, требует warm period чтобы статистику набрать и баги еще прут только так. Но в целом наш опыт что G1 работает гораздо предсказуемее и стабильнее чем CMS, которому переодически требуется переделывать fine tuning введу изменившегося кода.

Да вы правы дo max вроде не доходит, но я видела когда доходил. Думаю там несколькo факторов и все не так straight forward, впрочем я уже об этом писала, мало ли какие другие флаги выставлeны при запуске JVM. Вот картинка с системы (G1GC) где каждый час запускается процесс сборки данных дляшийся минут 10-15

[kostik78]

Как подсчитывается вся куча? Это Xmx или его производная?

Не совсем понял вопроса. Xmx это максимальный хип. На стороне сервера лучше задавать Xms и Xmx одинаковыми тогда параметр будет от Xmx. И опять же пока не набереться статистика.

[kostik78]

Да вы правы дo max вроде не доходит, но я видела когда доходил. Думаю там несколькo факторов и все не так straight forward, впрочем я уже об этом писала, мало ли какие другие флаги выставлeны при запуске JVM. Вот картинка с системы (G1GC) где каждый час запускается процесс сборки данных дляшийся минут 10-15

Глядя на картинку похоже что у Вас batch load - то пусто то густо. G1 не лучший выбор в данном случае. Я бы с Parallel GC поигрался. Для таких лоадов его можно довольно хорошо затюнить.