#java #memory-leaks #weblogic
#java #утечки памяти #weblogic
Вопрос:
У нас есть приложение, работающее на Weblogic 8.1.3, использующее пакет 1.4.2 JDK, и у него умеренно быстро происходит утечка памяти.
Я немного прочитал о том, как исправить утечки памяти, но большинство из них, похоже, предполагают, что используемый JDK равен 5 или выше. Существуют ли какие-либо инструменты, доступные для более ранних версий?
Кроме этого, мы обнаружили очень мало информации: утечка, похоже, происходит только в полной рабочей среде, а не в тестовых средах.
- У нас есть две машины, на которых работает weblogic, кластеризованные для балансировки нагрузки
- Утечка происходит на одном из кластеризованных серверов одновременно (?!), Но никогда на обоих
- Утечка иногда, но не всегда, переключается с сервера на сервер при перезапуске Weblogic.
Итак, я полагаю, что при запуске сервера должен быть создан объект, который может быть создан на одном (но не на обоих) серверах, который стоит за утечкой. Кажется ли это разумным местом для начала поиска?
Ответ №1:
JProfiler поддерживает профилирование Java 1.4 в его текущей версии (7.0)
Вы могли бы взглянуть на этот экран, показывающий, как искать утечки памяти с помощью JProfiler.
Отказ от ответственности: моя компания разрабатывает JProfiler
Комментарии:
1. Сладко. Ну, я взял пробную версию, и пока, похоже, она подключается и профилирует, как и ожидалось. Я испытываю несколько проблем с некоторыми подключениями к нашему серверу SonicMQ, но помимо этого, похоже, что мы можем оказаться в выигрыше…
Ответ №2:
Вы пытались запустить jvisualvm и просмотреть используемую память (дамп кучи)?
-> http://download.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html
Комментарии:
1. Да, к сожалению. Я могу заставить его подключиться к JVM, но раздел анализа памяти требует, чтобы цель была запущена на JDK 6 или 7. Мы можем видеть использование кучи, но не более того.
2. jvisualvm использует jstatd, а не JVMTI, поэтому он просто не распознает JVM версии 1.4.