В этом временном окне были обнаружены первые симптомы истощения памяти

Я изо всех сил пытаюсь понять следующую ошибку / предупреждение, вызванное новой реликвией:

Early symptoms of memory exhaustion have been detected in this time window.

Ниже представлены диаграммы профилей на основе журналов.

В этом временном окне были обнаружены первые симптомы истощения памяти

В этом временном окне были обнаружены первые симптомы истощения памяти

Хотелось бы понять:

  1. Почему пространство Eden Space никогда не очищается полностью, когда происходит незначительный сборщик мусора?
  2. На основании поведения сборщика мусора из журналов, соответствуют ли синий и желтый основной сборщик мусора и второстепенный сборщик мусора соответственно?
  3. Почему сборщик мусора все время собирает данные?
  4. Красноватая зона - это когда New Relic выдает предупреждение об истощении памяти. Но куча еще не заполнена. Приведет ли это к тому, что автоматический выключатель перейдет в разомкнутое состояние?

Я заметил такое поведение при отправке нового вызова REST в нашу службу исполнителя задач (например, executorService.submit(() -> restconecto.post(..))). Я попытался отправить logger.info(), и он работает нормально, но похоже, что проблема заключается в длинном опросе. Ниже моя конфигурация GC:

  • Параллельный сборщик мусора
  • -Xms2048m -Xmx2048m

Спасибо за любые идеи.

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
0
713
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий
  1. Сборщик мусора - это поток демона, который запускается при запуске JVM, а демон останавливается, когда останавливаются все потоки, не являющиеся демонами. Причина, по которой сборщик мусора постоянно работает, а приложение никогда не очищается, скорее всего, заключается в том, что всегда есть что собрать (это может быть даже фоновая задача). Конечный пользователь не может управлять сборщиком мусора.

  2. На самом деле не понимаю вашего вопроса

  3. См. 1.

  4. Ваша куча не должна быть заполнена, чтобы сработало предупреждение. По умолчанию настройки реликвии следующие:

    Memory threshold: 20%
    Garbage collection CPU threshold: 10%
    

Их, конечно, можно настроить, но в основном это означает, что если доступная память меньше порогового значения, будет срабатывать предупреждение.

Как вы заметили при отправке запроса REST (в зависимости от фактически отправленного запроса и того, как ваше приложение структурировано / спроектировано), этот конкретный запрос может быть «тяжелым» для обработки приложением, поэтому он может использовать больше памяти, чем вы могли ожидать.

  1. Вы используете сборщик молодого поколения PS Мусор. Этот сборщик использует несколько потоков параллельно. Таким образом, нет полной паузы остановить мир, которая собирает все узлы от молодого поколения. Таким образом, доступное пространство вряд ли полностью опустится до 0% для пространства Eden.
  2. Желтые и синие линии на графиках не соответствуют основным или второстепенным событиям GC. Это зависит от самой диаграммы. Однако на диаграмме Процессорное время сборки мусора желтая область соответствует времени ЦП, потраченному на сборщик молодого поколения, PS Scavenge, а синяя область соответствует времени ЦП, потраченному на сборщик старого поколения, PS Mark Sweep.
  3. Сборщик мусора работает все время, потому что и молодой, и выживший, и старый сборщики используют несколько фоновых потоков. Это минимизирует количество пауз остановить мир, которые периодически возникают в однопоточных сборщиках мусора.
  4. Судя по графикам, да. Красная зона - это период времени, в течение которого New Relic определяет, что ему необходимо потенциально приостановить программу и полностью очистить кучу, чтобы программа могла продолжить работу. Обычно параллельные сборщики просто откладывают паузы остановки мира, а не полностью их предотвращают. Подробнее см. Основополагающий доклад Джила Тене в «Сборке мусора». Подробнее об условиях срабатывания автоматического выключателя см. этот документ.

Некоторые комментарии по вашим пунктам: 1. Если я не ошибаюсь, то я читал, что коллекция молодого поколения - это коллекция для всех 4 GC. Проблема с параллельным сборщиком заключается в том, что сборщик мусора использует несколько потоков для выполнения сбора, и, как следствие, память eden должна быть полностью восстановлена ​​после молодой коллекции. Я вижу, что, когда размер eden уменьшается в размере, выживаемость и старые приращения увеличиваются, однако eden никогда не очищается 4. Спасибо за ссылку на документ.

jorgebo10 11.09.2018 18:11

Другие вопросы по теме