Docker контейнера использует только часть CPU ресурсов и работает медленно
Не подскажите как этим бороться? Может какие то параметры в JAVA_OPTS хитрые передать?
Я не думаю, что JAVA_OPTS помогут, если контейнеру мало ресурсов выделяется
пробовал выделять от 2 vCPU до 16 vCPU ситуация не изменяется используется по прежнему только 30% от 1 vCPU --cpu-shares пробовал, внутри контейнера ресурсы отображаются корректно процессоры доступны
https://stackoverflow.com/questions/39089850/docker-doesnt-get-100-of-the-cpu Тут пишут, что в докер десктопе какие-то дефолтные конфиги были, не твой случай?
нет к сожалению:(
java -XshowSettings:all -version https://gist.github.com/cageyv/477b62cc048dfc7c88a047c1f4cbc941 Ресурсов сколько угодно есть.. Есть аналогичный сетап без контейнеров и там дела обстоят ровно в 2 раза лучше процесс забирает 60% от CPU , но там нет возможности проводить эксперименты к сожалению
Есть запущенное приложение без докера и там потребляет больше
а память как то ограничивали?
Да стандартными флагами память ограничена На старой инсталляции это Xmx , на новой пробовал и Xmx и какой то более новый XX:MaxRAMPercentage
дак у вас jdk15, там достаточно лимиты на контейнер поставить
На JDK15 вчера вот и пересобрал как раз) Да там есть UseContainerSupport по дефолту включённый С ним не нужны никакие больше флаги для памяти и процессора?
не нужны, чтобы не уйти в OOM
Спасибо, попробую сегодня убрать , а вот это флаг ещё требуется в JDK15 XX:+UseParallelGC ? Или по дефолту jvm сможет принять более оптимальное решение? app_env_set = { CATALINA_OPTS = "-XX:InitialRAMPercentage=30 -XX:MaxRAMPercentage=100 -XX:+UseContainerSupport -XX:+UseParallelGC" CATALINA_OUT = "/dev/stdout" JAVA_OPTS = "-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -server" }
есть некоторый процесс долгий, который приложение запускает в отдельном подпроцессе без докера он выполяется 4 минуты и нагружает CPU на 60% (htop/top) внутри докера он выполняется 8 минут и нагружает CPU на 30% (htop на хостовой машине)
пробовал разные варианты 2,4,8,16 результат не менялся или менялся незначительно в рамках погрешности скажем так выдавал через --cpu-shares позволяя JVM посчитать самой и через флаг XX:ActiveProcessorCount
совсем не отличаются, один в один от дефолтных отличие в основном в AJP коннекторе
Продолжение истории Попробовали запустить на другом типе EC2 и да результат получился другой. думаю что T3 семейство плохо подходит для сильных нагрузок на CPU если используются контейнеры. перешли на C5 и дела стали получше К сожалению совсем чистого эксперимента не вышло. Нашлась проблема связанная с самой тестовой задачей. Но в результате получилось даже быстрее чем на старом окружении, что лучше в любом случае спасибо @lex_it и @centralhardware
Обсуждают сегодня