Увеличение байтов для javaw-процесса в java 8

Мой проект начал использовать java 8 из java 7.

После перехода на java 8 мы видим, что проблемы, связанные с потреблением памяти, со временем становятся все выше.

Вот те исследования, которые мы сделали:

  • Проблемы возникают только после перехода из java7 и из java8
  • Поскольку metaspace - единственное, что связано с памятью, которая изменяется от hava 7 до java 8. Мы отслеживали metaspace, и это не увеличилось более чем на 20 МБ.
  • Куча также остается непротиворечивой.

Теперь единственный путь - проанализировать, как распределяется память для обработки в java 7 и java 8, в частности, в частную память байтов. Любые мысли или ссылки здесь будут оценены.

ПРИМЕЧАНИЕ. Это приложение javaw представляет собой приложение на основе swing.

ОБНОВЛЕНИЕ 1: проанализировав собственную память с помощью инструмента NMT и создав разницу в памяти, сравниваемую с базой. Мы обнаружили, что куча осталась такой же, но потоки просачивают всю эту память. Так как никаких изменений в куче, я предполагаю, что эта утечка происходит из-за собственного кода.

Так что вызов остается открытым. Любые мысли о как анализировать память, занятую всеми потоками, будут полезны здесь. Ниже приведены снимки, взятые из встроенного отслеживания памяти.

В этом рисунке вы видите, что 88 МБ увеличилось в потоках. Там, где количество рукописей и ресурсов было значительно увеличено.

введите описание изображения здесь

на этой картинке видно, что в этом Malloc увеличилось 73 МБ. Но здесь нет имени метода. введите описание изображения здесь

Поэтому, пожалуйста, бросьте какую-то информацию в понимание этих скриншотов.

Ответы

Ответ 1

Вы можете попробовать другую реализацию GC, такую ​​как G1, введенную в Java 7, и вероятно, GC по умолчанию в Java 9. Для этого просто запустите свои Java-приложения с помощью:

-XX:+UseG1GC

Также есть интересная функциональность с G1 GC в Java 8u20, которая может искать дублированные строки в куче и "дедуплицировать" их (это работает только если вы активируете G1, а не по умолчанию Java 8 GC).

-XX:+UseStringDeduplication

Будьте внимательны, чтобы тщательно протестировать вашу систему перед тем, как перейти к производству с таким изменением!!!

Здесь вы можете найти хорошее описание различных GC, которые вы можете использовать

Ответ 2

рассмотрим оптимизацию параметров JVM

  • Параллельный коллектор (пропускной коллектор)

    -XX: + UseParallelGC

  • параллельные коллекторы (коллекторы с малой задержкой)

    -XX: + UseConcMarkSweepGC

  • использовать String Duplicates remover

    -XX: + UseStringDeduplication

  • оптимизировать компактное соотношение

    -XXcompactRatio: и см. link1 link2

Ответ 3

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

UPDATE

Вы использовали параметр -XX: NativeMemoryTracking = detail? Результаты просты, они показывают, что большая часть памяти выделяется malloc.:) Это немного очевидно. Ваш следующий шаг - профилировать ваше приложение. Для анализа собственных методов и Java я использую (и использую на производстве) пламенные графики с perf_events. Посмотрите на это сообщение в блоге для хорошего старта.

Обратите внимание, что ваша память увеличилась для потоков, вероятно, ваши потоки растут в приложении. Перед первичным я рекомендую проанализировать потоки дампов до/после, чтобы проверить, растет ли число потоков Java и почему. Сбрасывать потоки вы можете с помощью jstack/jvisualvm/jmc и т.д.