RSS БлогаВ ответ на мою заметку об OutOfMemoryError, на одном замечательном форуме меня немножко поправили и дополнили.
Цитата (автор Shurr):
Для начала стоит попытаться определиться с чем проблема: с кодом приложения, или с ресурсами. Если проблема в ресурсах – я бы начал с базовых рекомендаций по диагностике тюнингу от производителя, например Tuning Garbage Collection от Sun. Конкретно по ключам запуска можно посмотреть здесь. В случае, если используется не HotSpot JVM от Sun, то и документацию по используемой реализации, например для IBM.
В данном случае ошибка возникает при горячем передеплое, и OutOfMemory вылетает для perm-области. После прочтения документации мы видим, что проблема скорее всего в ресурсах. Конкретнее – при горячем передеплое контейнер держит два полных набора классов: старые классы ждут полной выработки уже запущенных на исполнение задач, новые используются для всех вновь поступивших.
В качестве простого решения можно попробовать увеличить размер perm’а. Логически можно предположить, что увеличивать размер perm’а более чем в два раза сейчас не нужно, т.к. один полный набор классов в текущий момент влазит в выделенную для него память.
Если не поможет – нужно смотреть лог сборки мусора, производится ли она в указанной области, с какими результатами.
Да, я согласен, что проблема описанная мной в заметке – OutOfMemoryError, на самом деле намного глубже и серьезнее. Но ведь не всегда требуется глубокий анализ для решения проблемы, иногда банально не хватает времени:)
p/s
Спасибо Shurr за более глубокое разъяснение проблемы:)