# Чрезмерное потребление памяти из-за предварительной компиляции ассетов

**URL:** https://meta.discourse.org/t/excessive-consumption-of-memory-due-to-precompiling-assets/402139
**Category:** Support
**Tags:** unsupported-install
**Created:** [04.Май.2026 14:16:45 UTC](https://meta.discourse.org/t/excessive-consumption-of-memory-due-to-precompiling-assets/402139 "2026-05-04T14:16:45Z")
**Posts on this page:** 1
**Showing post:** 12

<div class="post-metadata">

### Author: ![trobiyo](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/trobiyo/32/311872_2.png) [@trobiyo](https://meta.discourse.org/u/trobiyo)
#### Post date: [05.Май.2026 19:47:13 UTC](https://meta.discourse.org/t/excessive-consumption-of-memory-due-to-precompiling-assets/402139/12 "2026-05-05T19:47:13Z")

</div>

Привет, ребята,

Большое спасибо за все советы, которые вы нам предоставили, мы очень ценим это. Мы считаем, что нам удалось выявить корневую причину недавних проблем с памятью.

Ранее запуск `bundle exec rake assets:precompile:build` во время сборки (от имени root) не требовал наличия Redis или подключения к базе данных. Это поведение изменилось (см.: [Introducing pre-compiled JS assets for self-hosters](https://meta.discourse.org/t/introducing-pre-compiled-js-assets-for-self-hosters/376700) и [Introducing a new build system for plugins](https://meta.discourse.org/t/introducing-a-new-build-system-for-plugins/398713)).

Чтобы учесть это, мы перенесли шаг `bundle exec rake assets:precompile:build` в инициализационный контейнер во время выполнения (перед выполнением `db:migrate` и т. д.). Это позволяет запускать его от имени пользователя discourse с необходимым доступом к сервисам Redis и базы данных.

Однако во время выполнения процесс попадает в цикл в [`lib/plugin/js_manager.rb`](https://github.com/discourse/discourse/blob/main/lib/plugin/js_manager.rb). Просмотрев вывод `ps -fe`, мы видим, что `pnpm` неоднократно пытается добавить сам себя, что приводит к исчерпанию памяти:

```bash
...
discour+ 704 688 5 11:00 pts/0 00:00:00 node /usr/bin/pnpm -C=frontend/asset-processor node build.js
discour+ 718 704 5 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 729 718 6 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 740 729 6 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 754 740 7 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
...
# и список начинает расти и продолжает расти, вызывая исчерпание памяти

```

В наших тестах мы обнаружили, что запуск инициализационного контейнера от имени root, а затем выполнение `npm uninstall -g pnpm`, за которым следует `npm install -g pnpm@10.28.0`, устраняет цикл и позволяет завершить компиляцию плагинов успешно:

```bash
...
[Plugin::JsManager] Compiling 49 plugins...
[Plugin::JsManager] Finished initial compilation of plugins in 5.82s

```

Поэтому, прежде чем усложнять нашу инфраструктуру и, возможно, менять наш дизайн, я думаю, что этот вопрос больше для @david: есть ли планы восстановить предыдущее поведение для `assets:precompile:build`, чтобы он мог работать без подключения к Redis или базе данных (аналогично тому, что вы делаете с потоком [`DISCOURSE_DOWNLOAD_PRE_BUILT_ASSETS: 0`](https://meta.discourse.org/t/introducing-pre-compiled-js-assets-for-self-hosters/376700#p-1826075-can-i-opt-out-3))?

Кстати, и из любопытства: почему запуск процесса `node` от имени не root-пользователя вызывает этот рекурсивный цикл установки pnpm, тогда как запуск от root, похоже, его избегает?

С уважением,  
Исмаэль

---

_[View the full topic](https://meta.discourse.org/t/excessive-consumption-of-memory-due-to-precompiling-assets/402139)._
