Какой тип сборщика? Какие размеры поколений? Про VisualVM пишут что он с большими кучами никак не справляется. Для анализа больших куч желательно иметь платный профайлер под рукой. Другое дело что ещё нужно и дамп как-то снять.
Настройте и читайте GC Log в продакшне. Напишите триггер, который бы пробовал сделать дамп не на 16Gb, а на 4-8, при условии что 1,5Gb - нормальная загрузка.

Сопаставьте время в GC Log-е с логом приложения и посмотрите что же реально происходит в момент стремительного роста.

Eden я бы сделал побольше.

publexusПараметры
MaxPermSize у вас не работает, так как у вас Metaspace вместо него.
Отключать GCOverheadLimit это всё равно что бороться с пожаром путём отключения пожарной сигнализации.
Тут немного про young. Хотя дело не в нём.
https://blogs.oracle.com/jonthecollector/entry/the_second_most_important_gc

Есть какие-то асинхронные процессы в приложении?

publexusИ как заставить GC принудительно выполнять полную очистку с определенным периодом (если это поможет)?
Это вообще никак не поможет. Есть молодое поколение - там сборка происходит часто в фоновом режиме и без каких либо телодвижений. Есть старое поколение - там сборка происходит редко, потому что сборка в старом поколении включает Stop-the-world фазы, который для многопользовательского сервера очень вредны.
У вас старое поколение забивается под завязку и многократный вызов GC ничего не освобождает. Так что насильный вызов вряд ли приведёт к другому результату.

publexusДа, асинхронные процессы есть: по запросу пользователя может запускаться несколько потоков, каждый из которых может оперировать своим (неразделяемым) набором hashmaps. Но в момент роста памяти кардинальных отклонений от стандартного режима нет.
Ну, я имел ввиду что-то типа RxJava. С такими решениями есть классический косяк, когда событие уходит в цикл между разными потоками, а каждый вызов создаёт кучу объектов. Единственное что странно, что у вас эти данные где-то в глобальном хранилище оседают. Судя по графику они почти сразу в tenured улетают и в Eden особо не задерживаются.

publexusВ вычислениях используются обычные HashMap, которых по моим подсчетам должно создаваться максимум несколько тысяч одновременно.
Заведите глобальный счетчик, и логируйте его. Тогда будет понятно косяк в этом коде или где-то ещё. Не удивлюсь если ваша ситуация вообще сюрприз от GlassFish.

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 осилить.

Petro123ну если вы так уверены). То и разговора нет.
Т.к. банальное отсутствие
(recordSet\Statement\...).Close
даст утечку памяти.
Удачи!
Тут не совсем обычная утечка. Тут неожиданное потребление огромного количества памяти.

publexusПри этом в данное время отсутствуют какие либо отклонения в пользовательской активности, либо аномальные вычислительные процессы
publexusодин из аналитических запросов на аномальном распределении данных возвращает очень много данных
Ну, вот как так, взять и отбросить один из самых вероятных сценариев, не имея на то весомых причин?