Увеличение использование RAM памяти после обновления версий браузера(Chrome, Firefox) внутри докера

Всем привет!
Не много предыстории: На нашем проекте гонялись UI тесты внутри gitLab CI и использовался очень старый зашитый образ с 11 Java и хромом аж 94.0.4606.61 версии и сборка на gradle. Запускали и радовались жизни и имели потребление RAM памяти в поде собственно такое:


Далее решили использовать свой докер файл для использования более новых версий браузеров, да и java так же:
DockerFile:

FROM ... # здесь образ с java 17 и gradle

ARG CHROME_VERSION=120.0.6099.109
ARG FIREFOX_VERSION=121.0.1
ARG GECKO_DRIVER_VERSION=v0.34.0

RUN dnf -y update && dnf install -y liberation-mono-fonts liberation-narrow-fonts liberation-sans-fonts liberation-serif-fonts libappindicator-gtk* lsb nss mesa-libgbm bzip2 gzip

RUN wget "https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/$CHROME_VERSION/linux64/chrome-linux64.zip" -O /tmp/chrome-linux64.zip
RUN unzip -j /tmp/chrome-linux64.zip 'chrome-linux64/*' -d /opt/chrome
RUN ln -s /opt/chrome/chrome /usr/bin/google-chrome
RUN wget "https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/$CHROME_VERSION/linux64/chromedriver-linux64.zip" -O /tmp/chromedriver-linux64.zip
RUN unzip -j /tmp/chromedriver-linux64.zip 'chromedriver-linux64/chromedriver' -d /usr/bin/

RUN wget "https://ftp.mozilla.org/pub/firefox/releases/$FIREFOX_VERSION/linux-x86_64/ru/firefox-${FIREFOX_VERSION}.tar.bz2" -O /tmp/firefox-${FIREFOX_VERSION}.tar.bz2
RUN tar -jxf /tmp/firefox-${FIREFOX_VERSION}.tar.bz2 -C /opt/
RUN ln -s /opt/firefox/firefox /usr/bin/firefox
RUN wget "https://github.com/mozilla/geckodriver/releases/download/$GECKO_DRIVER_VERSION/geckodriver-${GECKO_DRIVER_VERSION}-linux64.tar.gz" -O /tmp/geckodriver-${GECKO_DRIVER_VERSION}-linux64.tar.gz
RUN tar -zxf /tmp/geckodriver-${GECKO_DRIVER_VERSION}-linux64.tar.gz -C /usr/bin

RUN rm -rf /tmp/*
RUN google-chrome --version && chromedriver --version && \
    firefox --version && geckodriver --version

Все загружается абсолютно отлично все версии выводятся, но.
При запуске тестов с этим образом мы получаем аномально выросшее использование RAM для ui тестов:

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

Дополнительная информация:

  1. По либам: selenide версии 7.0.4., testng версии 7.4.0.
  2. Java была до этого 11, в новом образе 17
  3. После каждого тестового сценария закрываем драйвер через
        Selenide.closeWebDriver();
  1. Тесты запускаю в параллели в 3 потока по test, тестовый suite имеет также атрибут group-by-instance= true
  2. Конфигурация для браузера:
        Configuration.browser = System.getProperty("browserName", "chrome");
        Configuration.browserSize = "1920x1080";
        Configuration.headless = true;
        Configuration.proxyEnabled = true;
        Configuration.fileDownload = FileDownloadMode.PROXY;
        SelenideLogger.addListener("UI action logger", new UIActionLogger());
        if (Configuration.browser.equals(Browsers.CHROME)) {
            ChromeOptions opt = new ChromeOptions();
            opt.addArguments("--no-sandbox");
            Configuration.browserCapabilities = opt;
        }

Буду рад любым рекомендациям!!!

а что мешает воткнуть новые браузеры и драйвера браузеров на старый контейнер - неужели так сильно явы сенманцать захотелось ?

@sergueik Такое не пробовали, спасибо за идею. Вообще хотелось бы очень жабу 17) Но опять же, это не объясняет почему так происходит, интересно же в чем суть проблемы и почему так раньше не происходило

не считая общих оснований (потому же почему раньше трава была зеленее) предположу что вы плохо выбрали орбаз. альпин с минимальным X или Xfvb или XVNC и без оконного менеджера экономит ресурсы
кстати делайте все хедлесс если ресурсами напряг.

а что за профит от семнадцатой ? рекорды и прочие минорные изменения синтаксиса ?- так по моему хотите ультие современного синтаксиса идите на с шарп или ноду
по моему это довольно хорошо что
ява это кобол

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

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

спс если все ещё удручает зайдите туда и посмотрите кто ест

imho, для автотестов 8-ой хватает выше крыши.

Так проблема ясна, что это браузера так грузят(даже вернее их драйвера) ибо апи тесты проходят легально по памяти, суть вопроса выше, почему так происходит? Нормально ли такое потребление вообще? Если не нормально, то как люди боролись с этим? Спасибо!

Пожалуйста, обратите внимание вопрос не по джаве, не стоит пихать сюда ответы про использование версий джавы, в контексте данного вопроса, это не уместно. Спасибо.

так вот именно это (наскольно 121 прожорливее 94) я и предлагал померять и узнать и чтоб другим не повадно было

В вопросе прикреплены скрины из графаны которая собирала использования рам памяти.

  1. Скрин, 1.5. Часа ui тестов, все стабильно) 94 версия хрома
  2. Скрин, 15 минут ui тестов, уходит использования рам памяти к 4 гигам и срабатывает оом.

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

кстати ява может быть виновата и более вероятно что она а не бро
еслт только он не переключиля в видимый но тогда должны быть х

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

В Java есть замечательный параметр -XX:+HeapDumpOnOutOfMemoryError.
Если виновата Java, и в следующий раз случится OutOfMemory, она сохранит дамп памяти на диск. И вы сможете его почитать и понять, какая сволочь там жрёт память.

Профилированием памяти мы уже занимались, забавная штука, разворачивали дамп и в рантайме смотрели, но ничего криминального не нашли. А вообще все каким-то чудом нормализовалось для хрома. Ради эксперимента провел анализ, что собственно по памяти, если юзать 11 java с 120.0.6099.109 версией хрома, то RAM памяти кушает на 12-13%(Минутка просто интересных фактов). А лиса как выжирала 4 гига RAM памяти за 15-20 минут, так и выжирает, но это слава богу не критично. Всем спасибо за дискуссию.