Таблетки OpenL Правила с большим количеством проблем с памятью

Question

В моей организации есть правила, встроенные в планшеты Openl с 20 + условиями столбца в нескольких из них. Это потребляет весь размер кучи Java, а затем приложение зависает. Любое предложение, что делать?

Ручная сборка мусора с использованием System.gc (), но не сработала

Исходный код доступен на планшетах OpenL

https://github.com/openl-tablets/openl-tablets/releases/tag/release-5.22.1/

Сборка мусора должна быть более эффективной и не занимать всю память, когда в столбцы условий добавляется больше условий.

Все, что превышает 20 столбцов, начинает потреблять дополнительную память, каждое редактирование, загрузка добавляет к предыдущему использованию памяти.

Мы пробовали использовать Linux-сервер 32 ГБ с размером кучи Java 24 ГБ, но не решить проблему

Answer 1

Проблема, которую вы описываете, - утечка памяти (не проблема сборщика мусора).

По какой-то причине в вашей куче занято большое количество объектов, которые не могут быть переработаны GC из-за их доступности на графе объектов.

Все, что превышает 20 столбцов, начинает потреблять дополнительную память, каждое редактирование, загрузка добавляет к предыдущему использованию памяти.

Это означает, что каждое редактирование, загрузка и т. Д. Приводит к утечке памяти.

Вам нужно найти причину утечки памяти, используя инструмент для анализа дампа кучи. Я могу предложить бесплатные JVisualVM и Eclipse MAT.

Я бы порекомендовал взять два дампа кучи:

• первый раз после перезапуска приложения
• секунда после нескольких правок, загрузка (избегайте заполнения всей памяти, работа с дампом кучи 20 ГБ - это боль)

В инструментах анализа дампов кучи вы можете сравнивать дампы и находить, какие объекты просочились. Этот же инструмент также позволит вам отслеживать пути от экземпляров просочившегося объекта к корню GC.