java.lang.OutOfMemoryError: GC overhead limit exceeded

Доброго времени суток!
Коллеги, нужна помощь!

Проект автотестов развернул на Ubuntu и сходу отхватил java.lang.OutOfMemoryError: GC overhead limit exceeded

Следует отметить, что етот же проект лежит на Jenkins-e, который так же на Ubuntu, - отлично работает. На Windows-e таких приключений не было. Предпологаю что что-то с настройками ide…

И так, по порядку. Дано:

  1. Ubuntu 16.04;
  2. JDK 1.8;
  3. CPU i5, RAM 4Gb;
  4. IntelliJ IDEA 2016.2.4
  5. maven-3.3.9

Настройки OC:
/etc/environment - JAVA_OPTS=“-server -Xms1024m -Xmx1024m”

Настройки IDE:
Maven → Runner → VMOptions: -Xms1024m -Xmx1024m

Частично помогла (тесты стали отрабатывать) установка
<argLine>-Xmx1024M</argLine>
в pom.xml, но в аллюр репорте перестали отображаться аттачменты.

Стек трейс: https://drive.google.com/open?id=0B9f-Gdzdysy7dmJRQXhLZHhfV28

З.Ы. С убунтой знаком очень-очень поверхностно, так что не стесняйте себя в елементарных советах.

Заранее благодарен.

А почему у вас initial / max pools имеют одинаковое значение? Это вы где такое вычитали?

Показывайте pom. И что за файлы атачите? Размер / контент?

Често говоря, ето моя “инициатива”. Исправил. Оставил только -Xmx1024m. Не помогло.

pom.xml: https://drive.google.com/open?id=0B9f-Gdzdysy7V2x0dkhxS0RQOGc.

Может помник и не идеален, но таких трудностей на других “убунту” не возникало.

Версию плагина бы обновили. :wink: Тут недавно жаловались на 2.2. А у вас вообще версия двухлетней давности. Ну и сам Allure не последний. Есть уже 1.4.23.HOTFIX1. Хотя, я бы рекомендовал собрать самый свежий из исходников. К тому же, если вы на уровне плагина явно не указываете версию, он автоматом тянет самую высокую (1.5.0.RC2), которая, к слову, не является последней, как бы странно это не звучало. :slight_smile:

И что за файлы атачите? Размер / контент?

Аттачится строка, которая формируется с помощью StringBuilder. Ее размер не значителен… ну… макс 500 символов.

В общем для начала обновите плагин + явно укажите свежую версию. Но проблема не в этом на самом деле.

Еще раз взглянул на стек… Ноги то у проблемы растут из RestAssured:

	at com.jayway.restassured.internal.assertion.AssertParameter.notNull(AssertParameter.groovy:21)
	at com.jayway.restassured.config.SSLConfig.<init>(SSLConfig.java:192)
	at com.jayway.restassured.config.SSLConfig.<init>(SSLConfig.java:184)
	at com.jayway.restassured.config.RestAssuredConfig.<init>(RestAssuredConfig.java:41)
	at com.jayway.restassured.RestAssured.<clinit>(RestAssured.java:423)
	at core.modules.RestAssuredHttp.get(RestAssuredHttp.java:18)
	at core.CommonPage.httpSendGETRequest(CommonPage.java:2377)
	at steps.APISteps.APISteps.get_all_campaigns_columns(APISteps.java:619)
	at APITest.ApiCampaignsTest.tmp(ApiCampaignsTest.java:24)

И вивер, к слову, плюет дамп в лог.

Sep 20, 2016 5:40:39 PM org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to /PROJECT_PATH/./ajcore.20160920.174037.859.txt
Sep 20, 2016 5:40:40 PM org.aspectj.weaver.tools.Jdk14Trace info
INFO: Dumping to /PROJECT_PATH/./ajcore.20160920.174040.742.txt

Желательно и туда заглянуть. Но подозреваю, что проблема в том, что ваш запрос улетает в глубокий таймаут, что приводит к OutOfMemory. Вы чекали вообще доступность / работоспособность end-point’а с вашей убунты? С network никаких проблем нет?

Уверен что с сетью все ок т.к. только раскоменчиваю в помнике <argLine>-Xmx1024M</argLine> - все отрабатывает норм (ну кроме аллюра).
К слову, замерял макс размер хипа с помощью Runtime.getRuntime().maxMemory(). Если -Xmx1024M указан только в идее и в ОС - то макс размер не увеличивается (где-то 800 мб). Как только указанный параметр прописываю в помник - сразу видно результат - увеличение больше 1 гб.

Так алюр на каком этапе кидает эксепшен? После вызова site или раньше? Судя по логу, это просиходит в момент прогона теста. Так что тогда отрабатывает “норм”?

Да, падение происходит во время прогона теста.
“Норм” значит, что при указании в maven-surefire-plugin конфига<argLine>-Xmx1024M</argLine>, - тест проходит. При “сайт” аллюр репорт - успешно билдится, только в нем нет аттачментов.
Полный код конфига maven-surefire-plugin:

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.18.1</version>
                <configuration>
                    <argLine>
                        -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                    </argLine>
                    <argLine>
                           -Xmx1024M
                    </argLine>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjweaver</artifactId>
                        <version>${aspectj.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>

Имхо ОС просто не дает джаве нужно колличество ОЗУ. А параметр <argLine>-Xmx1024M </argLine> “обеспечивает” выделение памяти, хоть и ломает аллюр.

Просто сделайте так:
<argLine>-Xmx1024M -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"</argLine>

удалено

А откуда вы взяли такой синтакис?

                    <argLine>
                        -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                    </argLine>
                    <argLine>
                           -Xmx1024M
                    </argLine>

Несколько аргументов пишутся одной строкой, разделенные пробелами, как заметили выше. И скорее всего атачи не подтягиваются из-за того, что вивер не отрабатывает в вашем случае. А когда вы все пишете одной строкой, он как раз-таки отрабатывает, но вызывает OutOfMemory из RestAssured. Запустите любой другой тест без использования RestAssured, но с атачами.

Так и есть. “Синтаксис” в две строки - появился методом тыка. Благодаря ему RestAssured нормально отрабатывает. Как только параметр -Xmx1024M оказывается в одной строке с -javaagent - тесты уходят в жесткий ступор с дальнейшей перезагрузкой пк.

Тесты, которые не используют RestAssured и для которых я убираю второй тег <argLine> - работают корректно, с аллюром тоже проблем не возникает.

Но, опять же, все ети чудеса происходят исключительно на локальной машине… На 2 серверах (на одном тоже убунту 16.04, на другом что-то из “линуксов”) - никаких проблем.

Да без разницы. Если тачка вешается от простого реквеста, значит у вас в приложении (либо в самом RestAssured) закрался серьезный лик. И то, что он не проявляется на других машинах означает лишь то, что верхний порог памяти позволяет с этим жить. Т.е. проблема просто скрывается. Вам следует определиться - хотите ли вы залатать дыру, или навесить workaround, увеличив памяти.

На етой же машине, только под управлением Windows 7 (которая стояла до ubuntu) таких вопросов не возникало…
Не совсем понимаю механизм происхоящего когда добавляется вторая строка <argLine>, но етот костыль позволяет нормально отрабатывать RestAssured…

Не вижу смысла трогать нормально работающую, до етого момента, либу.

Пока кроме как перебить ОС идеи нету (.

А плохо, что не понимаете.

Я не зря ведь писал о том, что нужно указывать аргументы в одну строку.
А что происходит в случае двух argLine можно легко проверить следующим тестом. :wink:

                    <argLine>
                        -Dkey1=val1
                    </argLine>
                    <argLine>
                        -Dkey2=val2
                    </argLine>
@Test
public void argCheckTest() {
    System.out.println("key1 = " + System.getProperty("key1") + "; key2 = " + System.getProperty("key2"));
}

Хм, а почему же key1 = null? :smirk:

А давайте теперь попробуем сделать так, как я уже устал повторять?!

                    <argLine>
                        -Dkey1=val1 -Dkey2=val2
                    </argLine>

Все еще есть сомнения, что проблема у вас в коде, а не в Allure, который ничего не атачит?

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

1 лайк

Спасибо за объяснение с <argLine>, сам не допетрал так попробовать.

Я еще никогда не сталкивался с проблемой утечки памяти…
Даж не знаю, хватит ли скила ее разрулить.

привет, получилось ли решить проблему с ошибкой? Такая же возникла при запуске на дженкинсе java.lang.OutOfMemoryError: GC overhead limit exceeded

Привет!
Ох давно ето было…

И так, что мне помогло: корректная настройка “swap” раздела при установки Ubuntu. В тот раз, когда я столкнулся с етой проблемой, мне ОС ставили сторонние люди, которые почему-то посчитали что файл подкачки на ноуте с 4 ГБ ОЗУ не сильно нужен… Попробуйте настроить swap, должно помочь.

В чем была причина: в тестах использовалась либа restassured. Я “присел” на нее когда только начинал разбираться с хттп клинентом, она реально оч удобная. Но… Заюзал java профайлер (кажись етот https://www.ej-technologies.com/products/jprofiler/overview.html) - restassured при старте плодит огромное количество объектов. Аналогичное поведение наблюдалось и на “форточке” (windows 10), но видать она с памятью лучшее работает (или файл подкачки нормального размера).

1 лайк

Может не Вам, но кому еще пригодится. Да, это из-за Rest Assured или чего-то аналогичного (с генерацией кучи временных объектов в памяти).
Решение - в конфигурации surefire плагина, в argLine перед javaagent дописать -Xms1024M -Xmx1024M.
Получится:

-Xms1024M -Xmx1024M -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar

Должно этого хватить.

2 лайка