анализа динамической памяти Java с VisualVM и МАТОМ

У меня есть запущенный и недавно заметил, что мой контейнер не реагирует и ведет себя по-разному, как журналы не писан и т.д. ...анализа динамической памяти Java с VisualVM и МАТОМ

Так я думал о collectin Gth дампа кучи и анализе что происходит.

Я выбрал VisualVM и MAT. Анализируя, я сейчас запутался.

Пожалуйста, найдите картинки ниже и будет здорово, если я получу некоторые мысли.

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

И Visualvm показывает полную память.

VisualVM

enter image description here

МАТ с unreachable_objects

enter image description here

МАТ гистограмму

enter image description here

источник

2015-07-21 Srikanth Hugar

Я бы не ожидал, что классы двигателей SSL будут вызывать большую память, если не будет большого количества одновременных соединений SSL. Там происходит что-то рыбное.

Ваши варианты:

Попробуйте другую (новую) JVM (может быть утечка памяти есть)
Проверьте наличие открытых соединений/настроить параметры пула соединений имеют несвежие связи упал
Исследовать дальше в эти классы (SSLEngineResult, SSLEngineArgs)

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

источник

2015-07-21 11:34:42 emu

Спасибо за быстрый ответ. Я использую apache karaf: 3.0.0, jetty: 8.x, openjdk: 1.7.0_79. –

Можете ли вы попробовать Oracle JDK и посмотреть, не изменит ли он что-нибудь? Кроме того, что касается фактической нагрузки на ваше приложение: есть ли у вас какая-либо пользовательская конфигурация, касающаяся потоков/акцепторов в вашем файле jetty.xml, которая позволит использовать большое количество параллельных соединений? (возможно, post jetty.xml) Сколько запросов сервер видит за определенное количество времени/сколько времени потребуется после перезагрузки для ваших проблем? – emu

Проблема была с другим кодом java https://github.com/TooTallNate/Java-WebSocket/issues/171. Спасибо. –

«Лик подозревает» что-нибудь показывает? Если вы не хотите найти, где вы создаете все те объекты SSLEngineResult и почему они все еще доступны - «Пути к GC Roots» должны это сделать. Есть очень мало вариантов: просто так много одновременных подключений открыты, у вас есть ссылки на них в полях singleletons/static class или в ThreadLocal.

источник

2015-07-21 11:38:32 user158037

Утечки подозреваемых не показывают ничего.Мне нужно проверить одновременные открытые соединения. –

Проблема была с некоторым другим кодом java https://github.com/TooTallNate/Java-WebSocket/issues/171. Спасибо. –

анализа динамической памяти Java с VisualVM и МАТОМ

ответ

Смежные вопросы