Проблема, есть метод который жутко мусорит в jvm, он по сути создает очень сложную модель данных по описанию текстовому.

Худший сценирий в зависимости от сложности этого описания, в jvm 13Gb замусорить и если запустить gc то останется около 2.5Gb живых данных. В среднем около 60-90% это мусор. Чистка занимает секунд 40-60.

Не все модели такие большие но крайней мере одна точно попадается, в среднем это 8Gb и после очистки около 1.5Gb.

Т.е в приципе 16Gb на сервере достаточно для работы порядки 5 моделей, но грузим первую после загрузки остается около 3-5Gb памяти. Грузим вторую и там начинается gc и все очень медленно работает.

В jsonsole паттерн следующий
edem -> s0 ->s1 и затем из s0 или s1 все аккуратно перезжает в heap и так повторяется пока модель не создастся.

Какие стратегии в этом случае попробовать, чтобы улучшить положение?
Пока насколько я понял можно попробовать edem выкрутиь на максимум, и добавить памяти так чтобы в edem всегда было место для мусора а в heap места достаточно для хранения моделей.
Т.е. в edem догнать до 13Gb(дабы все могло поместиться без переезда в head),а в heap должно быть около 10Gb места для хранения моделей ( по 2Gb на 5 моделей). То бишь для сервера в таком случае выделять нужно 24Gb.

Насколько я в верном направлении и что еще можно предпринять?

PS код не мой(не поправят) работать нужно с тем что есть.

jdk1.8_140

забыл ник,

Java 8 - Parallel GC в 4 потока (на машине 4 процессора)

спс

1. с G1 немного помогло, теперь подчищает понемногу в момент создания модели. График растущая пила но тем менее по крайне мере мусора меньше 50% в конце остается, и отклик в разумное время. Попробую поиграть с настройками сборщика.

2. менять код который мусорит не могу.