Проект автотестов развернул на Ubuntu и сходу отхватил java.lang.OutOfMemoryError: GC overhead limit exceeded
Следует отметить, что етот же проект лежит на Jenkins-e, который так же на Ubuntu, - отлично работает. На Windows-e таких приключений не было. Предпологаю что что-то с настройками ide…
Версию плагина бы обновили. Тут недавно жаловались на 2.2. А у вас вообще версия двухлетней давности. Ну и сам Allure не последний. Есть уже 1.4.23.HOTFIX1. Хотя, я бы рекомендовал собрать самый свежий из исходников. К тому же, если вы на уровне плагина явно не указываете версию, он автоматом тянет самую высокую (1.5.0.RC2), которая, к слову, не является последней, как бы странно это не звучало.
В общем для начала обновите плагин + явно укажите свежую версию. Но проблема не в этом на самом деле.
Еще раз взглянул на стек… Ноги то у проблемы растут из 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:
Просто сделайте так:
<argLine>-Xmx1024M -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"</argLine>
Несколько аргументов пишутся одной строкой, разделенные пробелами, как заметили выше. И скорее всего атачи не подтягиваются из-за того, что вивер не отрабатывает в вашем случае. А когда вы все пишете одной строкой, он как раз-таки отрабатывает, но вызывает OutOfMemory из RestAssured. Запустите любой другой тест без использования RestAssured, но с атачами.
Так и есть. “Синтаксис” в две строки - появился методом тыка. Благодаря ему RestAssured нормально отрабатывает. Как только параметр -Xmx1024M оказывается в одной строке с -javaagent - тесты уходят в жесткий ступор с дальнейшей перезагрузкой пк.
Тесты, которые не используют RestAssured и для которых я убираю второй тег <argLine> - работают корректно, с аллюром тоже проблем не возникает.
Но, опять же, все ети чудеса происходят исключительно на локальной машине… На 2 серверах (на одном тоже убунту 16.04, на другом что-то из “линуксов”) - никаких проблем.
Да без разницы. Если тачка вешается от простого реквеста, значит у вас в приложении (либо в самом RestAssured) закрался серьезный лик. И то, что он не проявляется на других машинах означает лишь то, что верхний порог памяти позволяет с этим жить. Т.е. проблема просто скрывается. Вам следует определиться - хотите ли вы залатать дыру, или навесить workaround, увеличив памяти.
На етой же машине, только под управлением Windows 7 (которая стояла до ubuntu) таких вопросов не возникало…
Не совсем понимаю механизм происхоящего когда добавляется вторая строка <argLine>, но етот костыль позволяет нормально отрабатывать RestAssured…
Не вижу смысла трогать нормально работающую, до етого момента, либу.
И так, что мне помогло: корректная настройка “swap” раздела при установки Ubuntu. В тот раз, когда я столкнулся с етой проблемой, мне ОС ставили сторонние люди, которые почему-то посчитали что файл подкачки на ноуте с 4 ГБ ОЗУ не сильно нужен… Попробуйте настроить swap, должно помочь.
В чем была причина: в тестах использовалась либа restassured. Я “присел” на нее когда только начинал разбираться с хттп клинентом, она реально оч удобная. Но… Заюзал java профайлер (кажись етот https://www.ej-technologies.com/products/jprofiler/overview.html) - restassured при старте плодит огромное количество объектов. Аналогичное поведение наблюдалось и на “форточке” (windows 10), но видать она с памятью лучшее работает (или файл подкачки нормального размера).
Может не Вам, но кому еще пригодится. Да, это из-за Rest Assured или чего-то аналогичного (с генерацией кучи временных объектов в памяти).
Решение - в конфигурации surefire плагина, в argLine перед javaagent дописать -Xms1024M -Xmx1024M.
Получится: