ruby-on-rails - validator - pipelines deploy




Сокращение потребления памяти в рейк-активах: прекомпиляция (2)

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

Проблема:
У меня заканчивается ОЗУ при выполнении rake assets:precompile задачи в автоматическом сборке. Существуют ли какие-либо стратегии для инкрементного прекомпиляции или каким-либо другим способом выполнить этап прекомпиляции без использования как можно большего количества ОЗУ? Похоже, что эта задача занимает около 850 МБ больше, чем базовая линия для сборки.

Контекст :
Я пытаюсь получить одну версию Docker контейнера Bitbucket Pipelines для нашей автоматической сборки. В стек приложений входят Rails 4.2.7, PostgreSQL 9.3, Java 8, Maven 3.3.9 и JRuby 9.1.2.0. Я попытался создать образ, основанный на Debian Jessie, а также на Alpine Linux, но он не имеет большого значения в базовой памяти.


Короткий ответ

Используйте NodeJS в качестве интерпретатора JavaScript для предварительной компиляции (или другого интерпретатора JavaScript, характеризующегося низким потреблением памяти).

Более длинный ответ

Для контекста я использую NodeJS 4.5.0 по сравнению с therubyracer v0.12.2 и therubyrhino v2.0.4

Можете ли вы увеличить объем оперативной памяти?

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

Можете ли вы переключить интерпретаторы JavaScript?

Использование высокопроизводительного ОЗУ, как представляется, является фундаментальной характеристикой как therubyrhino (интерпретатор Rhino для Mozilla Rhino), так и therubyracer (интерпретатор V8 JavaScript). Как представляется, не существует эффективного способа значительно сократить объем оперативной памяти, потребляемой на этапе предварительной компиляции активов. Наиболее жизнеспособные пути, по-видимому, предкомпилируют активы за пределами жизненного цикла сборки и кэшируют их где-то, чтобы их можно было извлечь, а не прекомпилировать, как это было предложено @ user4776684 . Как следует из комментариев по этому вопросу, обе версии Rails и Ruby имеют влияние, но не так сильно, как интерпретатор JavaScript.

Если все остальное не удается

Как упоминалось выше в @ slowjack2k , при использовании Bundler параллельная конфигурация может быть использована для вызова NodeJS только для задачи прекомпиляции и сохранения исходной сборки относительно нетронутой. Я не смотрел на это, так как было проще переключать интерпретаторы, но пока я мог прекомпилировать активы с помощью рейка и NodeJS, они, похоже, не считались предварительно скомбинированными, когда речь шла о вызове rake + therubyrhino, поэтому они были повторно прекомпилирована. Я выполнил это с помощью программно заданной переменной среды BUNDLE_GEMFILE которая указала на полностью отдельный gemfile, который использовал MRI Ruby и NodeJS вместо JRuby и therubyrhino.





bitbucket-pipelines