Java 12-GC (JEP 346) Является ли поведение особенно невыгодным в контейнерных средах, где ресурсы оплачиваются путем использования?
Заявленная цель этого JEP состоит в том, чтобы улучшить сборщик мусора G1 для автоматического возврата памяти кучи Java операционной системе при простое
Поскольку G1 изо всех сил старается полностью избежать полных GC и запускает только параллельный цикл, основанный на занятии и распределении кучи Java, во многих случаях он не будет возвращать память кучи Java, если не будет вынужден делать это извне.
Так ли это невыгодно в контейнерных средах, где ресурсы оплачиваются за счет использования?
Может кто-нибудь, пожалуйста, уточнить это....
Ссылка: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089
2 ответа
Если я вас не правильно понимаю, кажется, вы спрашиваете, невыгодно ли использовать GC для восстановления памяти в контейнерах, поскольку пользователь может не полностью использовать память и, следовательно, перегружен для ресурсов.
Ссылка, которую вы предоставили, на самом деле гласит следующее:
Такое поведение особенно невыгодно в контейнерных средах, где ресурсы оплачиваются путем использования. Даже на этапах, когда виртуальная машина использует только часть назначенных ей ресурсов памяти из-за неактивности, G1 сохранит всю кучу Java. Это приводит к тому, что клиенты все время платят за все ресурсы, а облачные провайдеры [не могут в полной мере использовать свое оборудование][4].
Если бы виртуальная машина была способна обнаруживать фазы недоиспользования кучи Java ("незанятые" фазы) и автоматически уменьшать использование кучи в течение этого времени, оба выиграли бы.
Разработчики этого JEP, похоже, полагают, что и пользователь, и поставщик облачных вычислений выиграют от восстановления неиспользованной памяти, и, похоже, это имеет смысл из приведенного выше утверждения.
Однако, если ваша программа работает во временной среде (такой как AWS Lambda) и она недолговечна, вы можете даже использовать Epsilon GC, где память не восстанавливается, поскольку в некоторых случаях это может принести вам еще большую пользу. (зачем тратить циклы ЦП на восстановление памяти, если контейнер будет просто уничтожен?).
Согласно документу JEP, новое поведение является обязательным
В значениях конфигурации по умолчанию мы отключаем эту функцию. Это не приводит к неожиданным изменениям в поведении виртуальной машины для приложений, чувствительных к задержке или пропускной способности.
так что не будет никакого влияния на любую систему. Для сред, где это может стоить того, можно включить его, а затем оценить влияние.
Хотя цель состоит в том, чтобы помочь совместно используемым контейнерным средам или средам виртуальных машин, это не обязательно означает, что все такие среды действительно выиграют, поскольку это зависит от их использования, от того, сколько пиковой памяти можно сократить во время простоя, будь то ЦП или память более ценны и много других факторов.
Так что, является ли это (не) выгодным, нужно будет оценивать в каждом конкретном случае.
Мотивация JEP 346 проста: сделать приложения Java (включая стеки промежуточного программного обеспечения Java) менее жадными в отношении использования ОЗУ или, другими словами, сделать их эластичными. Проблема неэффективности существует уже много лет, поскольку GC по умолчанию не был хорошо согласован с широко распространенными эластичными облачными технологиями, особенно с контейнерами. Люди привыкли мириться с этой проблемой... Однако стоимость потребляемых облачных ресурсов тщательно подсчитывается в малых и средних проектах, и даже крупные предприятия, которые заботятся об оптимизации использования инфраструктуры, могут получить от этого выгоду.
Некоторые поставщики облачных услуг пытались предложить другие решения. Например, Jelastic PaaS и Alibaba имели собственную внутреннюю настройку для повышения эффективности рабочих нагрузок Java. Теперь, наконец, эластичность доступна в ядре с открытым исходным кодом. Итак, есть решение для G1, и теперь нет необходимости отказываться от эффективности с помощью GC по умолчанию. Кроме того, новые реализации GC (Shenandoah и ZGC) также учитывают важность эластичности.
Следующая презентация специально посвящена этой теме: Эластичная JVM для масштабируемых приложений Java, работающих в контейнерах.