publexusВ том то и дело, что я не могу сравнить или посмотреть что там в памяти аномального сидит.
Как я писал выше, если в момент роста памяти в VisualVM включить мусорщик принудительно, то память очищается практически полностью (мегабайт до 200-300), аномальный рост памяти обрывается и приложение функционирует нормально.
Если я выполняю Heap dump, то перед снятием снимка памяти также почему-то происходит запуск мусорщика и память тоже очищается. Если же память переполнилась, то процесс jvm просто подвисает - не реагирует ни на какие запросы, asadmin не отвечает, помогает только kill -9. Если VisualVM была подключена к jvm, то спустя некоторое время после переполнения тоже отключается от нее. Естественно, снять дапм в этом случае тоже не получается.
Т.е. я никак не могу получить информацию о том, что же там растет.
Есть подозрение что вы немного заблуждаетесь. Если у вас JVM уже "зависла", это значит что уже работает самая полная сборка с остановкой всех других потоков. А UseGCOverheadLimit выкидывает вам исключение когда ещё не "всё потеряно", но полная сборка мусора уже не приносит особых результатов. Так вот VisualVM запускает точно такую же полную сборку. И быть того не может чтобы она собрала то с чем не справился сборщик в штатном режиме.
Более детально можно понять читая GC Log. Если у вас проблема регулярная, то совершенно не понятно почему вы до сих пор его не включили и не опубликовали.
Совсем не сложно написать JMX монитор кучи, который бы вызывал дамп при подозрительном росте, раньше чем вы это сделаете вручную в VisualVM. Плюс вы там можете залогировать любое своё состояние - количество пользователей, размеры текущих сессий и т.п.
Ну, и не забывайте про чтение манулов
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html
Если уж вы добрались до VisualVM, то должны и работу GC осилить.
