Garbage Collection

[Сабина]

Да вы правы д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 строго говоря не убитые
а про "возрождены" можно поподробнее ?