Нарушение использования собственной памяти в рамках процесса JVM на SLES

Question

У меня есть приложение WebSphere Portal, работающее с четырьмя экземплярами в одном окне, и примерно через 7 дней с момента запуска в основной памяти доступно только 130-150 МБ адресного пространства (с использованием PMAP). Где-то еще через 7-10 дней показатель падает значительно ниже 100 мб (что мы считаем опасным, и мы начинаем перерабатывать JVM). Если мы не будем перерабатывать, JVM в конечном итоге выйдет из строя с сигналом SIGSEGV.

Мы провели начальное расследование по классам и размеру кода JIT. Количество классов растет, но медленно от 50 тыс. Лет ... около пары сотен в день. Размер JITC достигает примерно 210 МБ через 7 дней и растет примерно на 1 МБ в день после этого. В нашем предыдущем опыте мы не находим их зловещими ценностями.

Что нужно, чтобы иметь возможность разбивать то, что находится в нативной куче, будь то потоки (все подсчеты потоков выглядят нормально, и у нас есть фиксированные пулы потоков), пулы строк, постоянные пулы, байт-код или что-то еще ,

Один из примеров, которые мы сейчас пытаемся сделать, сводится к уменьшению порога отражения до 0 (отключая приемники байт-кода для отражательно созданных классов). Это приложение использует много pointcutting и много размышлений, поэтому мы надеемся, что есть хороший шанс, который это помогает.

Любые советы приветствуются.

Answer 1

После долгих исследований это оказалось ошибкой WebSphere: PK72252: CALLS TO CLASSLOADER.GETRESOURCEASSTREAM ARE SLOW. Исправлено в 6.0.2.33.

Answer 2

Может быть, немного назад и вперед, но у вас GC-журнал и гарантированно, что он не увеличивает кучу Java со временем? Посмотрел на свое пространство? SIGSEGV интересен, хотя я бы ожидал большего сбоя JVM-ish для любых проблем в Java-памяти.