Недостаточно памяти при низком потреблении ЦП

Я пытаюсь настроить какое-то приложение с высокой нагрузкой, которое передает данные из одного облака в другое с некоторой предварительной обработкой. Особенностью моего приложения является интенсивное использование памяти и низкое потребление процессора. Я мониторил приложение с помощью jconsole и получил интересную картину - процессор загружен до 15%, и я все еще ловлю ошибку нехватки памяти.

Ручной запуск «Выполнить GC» из jconsole очищает много памяти во всех поколениях, поэтому я предполагаю, что в приложении нет утечки памяти.

Мое приложение работает на мезосе/марафоне, поэтому я попытался переключиться с одного виртуального ЦП на многопроцессорный с различными GC (-XX:+UseG1GC; -XX:+UseParallelGC без другой настройки), и картина на самом деле такая же;

  • Итак, почему сборщик мусора не использует ЦП для освобождения памяти?
  • Можем ли мы настроить GC для более частой/правильной работы?

Показатели времени выполнения: введите здесь описание изображения

Конфигурация системы: введите здесь описание изображения


java out-of-memory memory garbage-collection high-load
person Silk0vsky    schedule 14.04.2017    source источник
comment
Что означает нехватка памяти в данном контексте? вы получаете исключение OuOfMemoryException? Это кажется маловероятным, поскольку вы говорите, что память освобождается при ручном вызове GC. Если вы не получаете исключение, в чем ваша проблема?   -  person Axel    schedule 14.04.2017
comment
Возможно, вы выделяете что-то настолько большое, что даже GC не очистил бы достаточно памяти, и в этом случае я полагаю, что система может выбросить это, даже не утруждая себя выполнением GC.   -  person john16384    schedule 14.04.2017
comment
Получите дамп кучи и посмотрите, что там в памяти   -  person Vipin    schedule 17.04.2017

Ответы (2)


arrow_upward
2
arrow_downward

Сборщик мусора запускается, когда приложению требуется освободить память. GC — дорогостоящая операция, и она будет работать только тогда, когда это необходимо. Я не уверен, почему вы пытаетесь связать загрузку ЦП с запуском GC. Использование ЦП не имеет ничего общего с запуском приложения GC. Если поток VM решит запустить GC, он приостановит все запущенные потоки приложения (Safepointing) и позволит GC выполнить операцию, поэтому объем использования ЦП Java остается прежним, не имеет значения, сколько ЦП у вас осталось.

Есть много флагов GC, которые можно использовать для тонкой настройки вашего приложения, я не смогу предложить ни одного, так как не уверен, что именно представляет собой ваше приложение?

Возможные приведенные ниже ссылки помогут вам http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collection/ https://confluence.atlassian.com/enterprise/garbage-collection-gc-tuning-guide-461504616.html

Вы должны знать, где вы получаете OOM, старое поколение, Metaspace, Codegen или родной код, основываясь на том, что вы можете точно настроить с помощью параметров кучи.

person Fairoz    schedule 19.04.2017
comment
Привет Файроз, спасибо за ответ и ссылки! Я связал использование ЦП с активностью GC, потому что у нас могут быть такие проблемы, как превышение лимита накладных расходов GC. Когда пользовательские потоки остановлены, а GC обрабатывает память - он потребляет ЦП. Так что эта комбинация показалась мне странной: проблемы с памятью и низкое потребление процессора. - person Silk0vsky; 19.04.2017
comment
Кроме того, я понял, что это не GC - связанная проблема - person Silk0vsky; 19.04.2017

arrow_upward
1
arrow_downward

Считаю, что должен поделиться результатами своих исследований.

"Недостаточно памяти" - это то, что я получил от DevOps-парня, и первое, что я представляю - OutOfMemoryException. Итак, спасибо Алексу за уточняющий вопрос.

В моем случае это был OOMKill в среде докеров из базовой ОС. Я выделил 1G для контейнера и ограничил размер кучи java 736m. Но мое приложение использовало netty, которая выделяла собственные буферы памяти в обход кучи. Таким образом, когда появляется больше соединений, netty выделяет больше прямых буферов, что приводит к OOMKill, несмотря на здоровую кучу.

person Silk0vsky    schedule 19.04.2017
comment
Я думаю, это хорошее объяснение, и вы можете принять свой собственный ответ. - person maaartinus; 25.04.2017