Garbage Collection

[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 поигрался. Для таких лоадов его можно довольно хорошо затюнить.

[Сабина]

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

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

и батч и не батч. У нас таких (это EC2 instance) 40, они собирают данные раз в день и раз в час. по требованиям могут начать собирать чаще или реже. обьем данных в батче ( длительность обработки) тоже очень непредсказуемая. Ну и все они кладут собранное в Kafka claster.

[Palych]

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

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

Допустим Xmx=1G, Xms=64m.
В данный момент куча 100m.
InitiatingHeapOccupancyPercent=45

Вопрос: при каком размере кучи включится сборщик?
- 45m?
- 0.45G?
- 64m * 0.45?

И еще, если не возражаете (извиняюсь за назойливость):
Что делает G1 если осознает что не выполняет взятые на себя обязательства?
Есть ли у него какие инструменты кроме подстройки размера кучи, при котором он включается?

[kostik78]

и батч и не батч. У нас таких (это EC2 instance) 40, они собирают данные раз в день и раз в час. по требованиям могут начать собирать чаще или реже. обьем данных в батче ( длительность обработки) тоже очень непредсказуемая. Ну и все они кладут собранное в Kafka claster.

Ну я говорю что Вам G1 не нужен для такого лоада. Я бы Parallel GC затюнил и еще демографию памяти посмотрел во время работы на предмет того что-то временное в old gen переползает а не должно. Ну мне тут сложно советовать ибо для файн тюнинга надо знать как приложение работает.

[kostik78]

Допустим Xmx=1G, Xms=64m.
В данный момент куча 100m.
InitiatingHeapOccupancyPercent=45

Вопрос: при каком размере кучи включится сборщик?
- 45m?
- 0.45G?
- 64m * 0.45?

Нету однозначного ответа. Если потребление памяти активное и быстро вырастет то 45% от 1G. А иначе просто наберет статистику и будет пахать как надо.

И еще, если не возражаете (извиняюсь за назойливость):
Что делает G1 если осознает что не выполняет взятые на себя обязательства?
Есть ли у него какие инструменты кроме подстройки размера кучи, при котором он включается?

Обязательства по чему ? По времени - это best efforts. То бишь стремиться сделать но не гарантирует. Если память закончиться то сделает world pause with full GC + defragmentation + rearrangement of G1 regions.

[Сабина]

и батч и не батч. У нас таких (это EC2 instance) 40, они собирают данные раз в день и раз в час. по требованиям могут начать собирать чаще или реже. обьем данных в батче ( длительность обработки) тоже очень непредсказуемая. Ну и все они кладут собранное в Kafka claster.

Ну я говорю что Вам G1 не нужен для такого лоада. Я бы Parallel GC затюнил и еще демографию памяти посмотрел во время работы на предмет того что-то временное в old gen переползает а не должно. Ну мне тут сложно советовать ибо для файн тюнинга надо знать как приложение работает.

Так я и обьяснила как работает. Временной интервал батча - непостоянен, обьем данных тоже, ровно как и частота повторения

[kostik78]

Так я и обьяснила как работает. Временной интервал батча - непостоянен, обьем данных тоже, ровно как и частота повторения

Вы меня не поняли. Для файн-тюнинга надо смотреть на статистику GC (нужно некоторое колличество verbose output включить), memory hot spots and etc Вообщем детально и методично к вопросу подходить

[Palych]

Если потребление памяти активное и быстро вырастет то 45% от 1G. А иначе просто наберет статистику и будет пахать как надо.

И еще, если не возражаете (извиняюсь за назойливость):
Что делает G1 если осознает что не выполняет взятые на себя обязательства?
Есть ли у него какие инструменты кроме подстройки размера кучи, при котором он включается?

Обязательства по чему ? По времени - это best efforts. То бишь стремиться сделать но не гарантирует. Если память закончиться то сделает world pause with full GC + defragmentation + rearrangement of G1 regions.

Я понимаю что не гарантирует. Вопрос в том - как он стремится?
Что делается если паузы оказываются слишком длинными. Допустим что память не кончилась.
Какие меры принимаются? В смысле - какой арсенал этих мер?
Входит ли в эти меры изменение границы за которой включается сборщик?

[Сабина]

Так я и обьяснила как работает. Временной интервал батча - непостоянен, обьем данных тоже, ровно как и частота повторения

Вы меня не поняли. Для файн-тюнинга надо смотреть на статистику GC (нужно некоторое колличество verbose output включить), memory hot spots and etc Вообщем детально и методично к вопросу подходить

И правда не поняла Что значит не должно в old gen ? Ведь все эти регионы придуманы для рациональной работы сборщика, а не приложения ? Приложению сколько надо держать в памяти коллекцию столько оно и будет. Всегда есть варианты поменять, но рефакторинг начнется только если полезут ООМ или нужно уменьшить memory footprint ( на EC2 costs сэкономить, я не знаю). У нас стоял parallel GC, работал хуже. Но не факт что был настроен праивильно или вообще был настроен. Это дело такое, не зря все, включая Gil Tene говорят " не чешется - не трогайте"

[Dmitry67]

Меня всегда интересовало, чето происходит системой посадки Фалкона во время world pause.

[kostik78]

Что делается если паузы оказываются слишком длинными. Допустим что память не кончилась.
Какие меры принимаются? В смысле - какой арсенал этих мер?
Входит ли в эти меры изменение границы за которой включается сборщик?

Там много разного. Если детально интересуетсь почитайте блог Оракла по GC. там разные моменты они описывают. В конце концов исходники JVM тоже доступны

[kostik78]

И правда не поняла Что значит не должно в old gen ? Ведь все эти регионы придуманы для рациональной работы сборщика, а не приложения ? Приложению сколько надо держать в памяти коллекцию столько оно и будет. Всегда есть варианты поменять, но рефакторинг начнется только если полезут ООМ или нужно уменьшить memory footprint ( на EC2 costs сэкономить, я не знаю). У нас стоял parallel GC, работал хуже. Но не факт что был настроен праивильно или вообще был настроен. Это дело такое, не зря все, включая Gil Tene говорят " не чешется - не трогайте"

Ну смотрите для примера (эту ошибку девелопера я встречал несколько раз) - многопоточное приложение и есть какой то глобальный лок что может вызвать lock starvation. Потоки аллоцируют память что переживает несколько minor GC pauses из-за lock starvation и в результате эту память переносят в old gen хотя в реальности это временная аллокация. Если ситуация происходит часто, то в результате old gen забивается этим мусором и происходит old gen GC которого можно было избежать. Ну и т.д. Не очевидно ... но реально импакт на GC большой ... и зачастую нужно сделать простой фикс в коде чтобы избежать этой ситуации. Есть другие но идея примерна таже. Временная память (что по идее не должна покидать young gen) попадает в old gen.

[Сабина]

И правда не поняла Что значит не должно в old gen ? Ведь все эти регионы придуманы для рациональной работы сборщика, а не приложения ? Приложению сколько надо держать в памяти коллекцию столько оно и будет. Всегда есть варианты поменять, но рефакторинг начнется только если полезут ООМ или нужно уменьшить memory footprint ( на EC2 costs сэкономить, я не знаю). У нас стоял parallel GC, работал хуже. Но не факт что был настроен праивильно или вообще был настроен. Это дело такое, не зря все, включая Gil Tene говорят " не чешется - не трогайте"

Ну смотрите для примера (эту ошибку девелопера я встречал несколько раз) - многопоточное приложение и есть какой то глобальный лок что может вызвать lock starvation. Потоки аллоцируют память что переживает несколько minor GC pauses из-за lock starvation и в результате эту память переносят в old gen хотя в реальности это временная аллокация. Если ситуация происходит часто, то в результате old gen забивается этим мусором и происходит old gen GC которого можно было избежать. Ну и т.д. Не очевидно ... но реально импакт на GC большой ... и зачастую нужно сделать простой фикс в коде чтобы избежать этой ситуации. Есть другие но идея примерна таже. Временная память (что по идее не должна покидать young gen) попадает в old gen.

Спасиюо, теперь понятно о чем речь и очень познавательно

[Palych]

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

Главная проблема - сборка мусора занимает CPU на время, которое не коррелирует с количеством мусора. То есть - если мусора мало - это не значит что сборка мусора будет быстрой.
К тому же - получается что объекты вышедшие из употребления с точки зрения Java не обязательно являются мусором. (слабые ссылки, да и объекты могут быть возрождены). Стало быть - отвязаться от учета количества свободной памяти невозможно практически.

[Сабина]

Кстати вспомнила одну из new GC features.
Коллектор теперь сам распознает duplicate strings и убирает лишние копии. Правда мне это показалось немного dangerous в смысле что поддерживать референсы мне кажется может быть нетривиально

[Сабина]

(слабые ссылки, да и объекты могут быть возрождены).

soft references строго говоря не убитые
а про "возрождены" можно поподробнее ?