Java-поколение продолжает расти до тех пор, пока Tomcat не перезагрузится

Question

У меня есть JDK 8 на нескольких серверах, а размер кучи продолжает увеличиваться, пока он не достигнет 90%, и приложение не работает. В течение этого периода времени выполняется несколько GC, но старое поколение продолжает расти, пока приложение не сработает. Текущая работа - перезапустить Tomcat. Мой сервер имеет 15 ГБ оперативной памяти, 4 ядра процессора. Моя настройка Java:

-Xms12036M -Xmx12036M -Xmn800M 

Есть ли рекомендации по этим значениям? Я думал, что GC позаботится об этом, но старое поколение, но, похоже, не будет. Я новичок в Java и не уверен, что это указывает на утечку памяти или если GC не делает такую ​​вещь?

Answer 1

Сначала проверьте на наличие утечки памяти с помощью JStacks/JMaps, резьбовых дампов и инструментов анализатора памяти. Если у вас нет утечек в памяти вашей системы, вы должны точно настроить алгоритмы сбора мусора.

Java предлагает различные типы сборщиков мусора.

взглянуть на сильные стороны & слабость различных GC algorithms

1. серийный коллектор: Серийный коллектор является самым простым один, и тот, который вы, вероятно, не будет использовать, так как он в основном предназначен для однопоточных сред.

2. Параллельный/пропускной коллектор: Его самым большим преимуществом является то, что он использует несколько потоков для сканирования и уплотнения кучи. Недостатком параллельного коллектора является то, что он остановит потоки приложений при выполнении небольшой или полной коллекции GC.

3. The CMS Коллектор: Этот алгоритм использует несколько потоков («параллельное») для сканирования через кучу («метки») для неиспользуемых объектов, которые могут быть переработаны («зачистка»). Это будет эффективно, если вы либо увеличите размер старого поколения (или всю кучу, если на то пошло), либо выделите больше фоновых потоков для collector.It использует больше процессора, чтобы обеспечить приложение с более высокими уровнями непрерывной пропускной способности.

4. Коллекционер G1: Первый сборщик мусора (G1), представленный в обновлении JDK 7 4, был разработан для лучшей поддержки кучи размером более 4 ГБ. Сборщик G1 использует несколько фоновых потоков для сканирования через кучу, которая делится на регионы, от 1 МБ до 32 МБ (в зависимости от размера вашей кучи). используя флаг -XX: + UseG1GC.

Если вы используете сборщик G1, вам необходимо точно настроить параметр размера региона. Если размер вашей кучи составляет 15 ГБ, размер вашей области должен быть (15 ГБ/2048) МБ, который составляет около 7 МБ. Не экспериментируйте больше с New Gen Size. Вы можете придерживаться настроек по умолчанию, так как этот алгоритм обеспечивает максимальную производительность со значениями по умолчанию.

Посмотрите на эту статью:

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html

Answer 2

Я не думаю, что с вашими параметрами что-то не так. Я предлагаю искать утечки памяти в вашем коде. Использование профилировщика - хорошая идея, но вы также можете искать шаблон утечки. Вот очень хорошая коллекция: Creating a memory leak with Java

Answer 3

ГХ JVM только ответ на объекты, которые не ссылаются основной программой, (входит в «ссылочный цикл»),

Если есть много объектов в динамической памяти не может быть собран с помощью ОГО, вызвавших ООЙ, две возможности:

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

2. те объекты, которые логически не нужны, но по-прежнему ссылается основной программы, (например: объект не нужен, но не удалили из списка): это утечка памяти в Java, это ошибка, вы должны исправить ее в своей программе.

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

Answer 4

-Xmn800M (800MB молодое поколение) кажется довольно низким значением для 12 ГБ кучи. Подумайте о простом убийстве этого параметра и просто сохраните параметры -Xms12036M -Xmx12036M.

Обратите внимание, что ваше прежнее поколение будет продолжать расти до тех пор, пока не закончится полный GC. У вас будет много второстепенных GC, которые будут делать GC на первых 800 МБ, но не на оставшихся 11,2 ГБ. По существу, попробуйте compare heap dumps using something the Eclipse Memory Analysis Tool. Также попробуйте grab a few different heap dumps. Следите за объектами, которые монотонно растут по размеру.