Как обойти ошибку памяти с помощью karma & phantomjs

Question

Мы запускаем тесты с использованием karma и phantomjs На прошлой неделе наши тесты таинственным образом начали сбой phantomJS с ошибкой -1073741819.

Based on this thread for Chutzpah Похоже, что код указывает на сбой собственной памяти с помощью PhantomJS.

При дальнейших исследованиях мы постоянно видим фантомный сбой вокруг 750 МБ памяти.

Есть ли способ сконфигурировать Карму, чтобы она не противостояла этому пределу? Или способ рассказать это, чтобы очистить фантом?

У нас только около 1200 тестов. Мы около 1/4 пути через наш проект, поэтому 5000 тестов пользовательского интерфейса, похоже, не могут быть и речи.

Answer 1

Благодаря феномену StackOverflow, когда вы отправляете вопрос и быстро обнаруживаете ответ, мы решили это, добавив gulp задач. До того, как мы только что запустили karma start в командной строке. Это создало единый экземпляр фантомов, которые разбились, когда было достигнуто 750 МБ.

Теперь у нас есть команда gulp для каждого из наших разделов тестов, например. gulp common-tests и gulp admin-tests и gulp customer-tests

Тогда один gulp karma, который работает каждый из этих группировок. Это позволяет каждой команде gulp иметь собственный экземпляр фантома и, следовательно, оставаться под этим порогом.

Answer 2

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

Я провел некоторое расследование и нашел причину роста памяти (по крайней мере, в нашем случае). Оказывается, когда вы используете:

beforeEach(inject(SomeActualService)){ .... } 

памяти, занимаемую SomeActualService не получает выпущен в конце описания блока, и если у вас есть несколько файлов тесты, где Вы вводите ту же услугу (или другие инъекционные объекты) более память будет выделена для него снова.

У меня есть пара идей о том, как этого избежать: 0: 1. Создайте имитирующие объекты и никогда не используйте инжекцию для получения реальных объектов, если вы не находитесь в тесте, который проверяет этот модуль. Это потребует написания тонны дополнительного кода. 2. Создайте свой собственный трекер (только для тестов) для инъекционных объектов. Таким образом, они могут загружаться только один раз и повторно использоваться между тестовыми файлами.

Забыл упомянуть: Мы используем угловой 1.3.2, Жасмин 2.0 и ударяем по этой проблеме около 1000 тестов.

Answer 3

Это проблема с PhantomJS. Согласно another source, PhantomJS запускает сборщик мусора, когда страница закрыта, и это происходит только после запуска ваших тестов. Другие браузеры работают нормально, потому что их сборщики мусора работают должным образом.

Проведя несколько дней на этом вопросе, мы пришли к выводу, что лучшим решением было разделить тесты на группы. У нас хватало динамический профиль для каждого каталога и создала команду, которая запускает все эти профили. Для всех целей и задач он работает точно так же.

Answer 4

Я также сталкивался с этой проблемой после 1037 тестов в Windows 10 с помощью PhantomJS 1.9.18.

Он появится как ERROR [launcher]: PhantomJS crashed. после того, как ОЗУ для процесса превысит около 800-850 МБ.

Там, как представляется, временное решение здесь:

• https://github.com/gskachkov/karma-phantomjs2-launcher
• https://www.npmjs.com/package/karma-phantomjs2-launcher

Вы установите его с помощью npm install karma-phantomjs2-launcher --save-dev

Но тогда нужно использовать его в karma.conf.js через

config.set({ 
    browsers: ['PhantomJS2'], 
    ... 
}); 

Кажется, что этот же набор тестов работает только при использовании между 250-550 МБ ОЗУ и без сбоев.

Обратите внимание, что это исправление работает из окна Windows и OS X, но не Linux (двоичные файлы PhantomJS2 не запускаются). Это влияет на толкает Travis CI.

Чтобы обойти эту проблему на Debian/Ubuntu:

sudo apt-get install libicu52 libjpeg8 libfontconfig libwebp5

Answer 5

В ответ на старый вопрос, но надеюсь, что это помогает ...

У меня есть процесс сборки, который проходит работа CI в командной строке только linux box. Итак, кажется, что PhantomJS - мой единственный вариант. Я столкнулся с этой проблемой памяти локально на своем Mac, но так или иначе это не происходит в окне linux. Мое решение состояло в том, чтобы добавить еще одну тестовую команду в мой пакет.json для запуска кармы с помощью Chrome и запустить ее локально для запуска моих тестов. Когда он подтолкнется, Дженкинс начнет обычную тестовую команду, запустив PhantomJS.

Установите этот плагин: https://github.com/karma-runner/karma-chrome-launcher

Добавить это package.json

"test": "karma start", "test:chrome": "karma start --browsers Chrome"

Answer 6

У нас была аналогичная проблема на Linux (Ubuntu), что оказалось количество сегментов памяти, что процесс может управлять:

$ cat /proc/sys/vm/max_map_count 
65530 

Затем запустите это:

Обратите внимание, что число было умножено на 100. Это изменит настройки сеанса. Если это решает проблему, вы можете настроить его для всех будущих сессий:

$ sudo bash -c 'echo vm.max_map_count = 6553000 > /etc/sysctl.d/60-max_map_count.conf'