Высокие требования к памяти при пересборке: издание за апрель 2025 года

Поддержка Самостоятельное хостинг
21

Хорошо, следующий тест завершен.

Я собрал с использованием следующих плагинов:

https://github.com/discourse/docker_manager.git
https://github.com/discourse/discourse-data-explorer
https://github.com/communiteq/discourse-legal-compliance
https://github.com/pfaffman/discourse-allow-pm-to-staff
https://github.com/singerscreations/discourse-stopforumspam
https://github.com/discourse/discourse-cakeday

Подкачка была отключена, поэтому доступно только 4 ГиБ/3,8 ГБ ОЗУ.

Максимальное использование памяти во время сборки составило 3,4 ГБ. Время сборки — 6 минут 48 секунд.

22

На пути к решению проблема заключалась в файле подкачки. После увеличения его размера с 0 до 2 ГБ всё работает нормально.

sudo fallocate -l 2G /swapfile        
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

в терминале вашего сервера. После этого выполните пересборку.

23

Я столкнулся с резким увеличением потребления памяти при пересборке. У меня 8 ГБ оперативной памяти, и даже после добавления файла подкачки объёмом 8 ГБ на этом шаге заканчивается место: cd /var/www/discourse && sudo -E -u discourse bundle exec rake multisite:migrate.

Это установка с поддержкой нескольких сайтов, включающая четыре форума. Раньше мне не приходилось добавлять файл подкачки.

редактирование Теперь попробовал с 16 ГБ подкачки, но памяти всё равно не хватает.

Это происходит в Linux с минимальным набором включённых плагинов. Процесс убивается ядром.

24

Хм… интересно, стоит ли обновить документацию, чтобы отразить повышенные требования к памяти? Помогла ли эта ссылка: Introducing pre-compiled JS assets for self-hosters снизить нагрузку? Мне казалось, что с этим изменением требуется меньше ОЗУ :thinking:.

25

Возможно, прошло несколько месяцев с момента моей последней переустановки, но ранее всё работало нормально с 8 ГБ оперативной памяти и без файла подкачки. Я до сих пор не решил эту проблему, и поэтому все четыре сайта недоступны.

Не знаю, связано ли это, но сборка не удавалась, пока я не установил переменную окружения HOME: /var/www/discourse — иначе она пыталась записывать данные в /root и выдавала ошибку отказа в доступе.

26

Хм, я вижу более ста таких процессов:

node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm/exe --no-dangerously-allow-all-builds --config.node-linker=hoisted --config.bin=bin

Это что-то вроде бомбы-форка?

27

Определенно добавьте МНОГО файла подкачки, даже если это нужно только для того, чтобы снова запустить систему. Преимущество использования файла подкачки здесь в том, что сборки создают лишь временный пик нагрузки.

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

28

Я добавил 40 ГБ подкачки, но этого всё ещё недостаточно.

Я вижу сотни процессов node, похоже, это и есть проблема?

Начинаю думать, что коренная причина та же, что и в моей предыдущей проблеме, когда мне приходилось указывать HOME: /var/www/discourse, иначе система пыталась записывать файлы в /root. Не знаю, что с этим делать.

29

Что-то явно не так. Я бы также рассмотрел вариант создания резервной копии и повторного запуска с нуля.

30

Как мне это сделать?

31

См.:

32

Спасибо, думаю, сначала я откатю весь сервер к последнему известному рабочему состоянию и сделаю резервную копию с рабочей системы.
У кого-нибудь есть идеи, что могло пойти не так?

33

Проблема действительно заключалась в том, что переменная HOME была установлена некорректно. Добавление флага -H к команде sudo для миграции мультисайта решило проблему, как подробно описано здесь:

https://meta.discourse.org/t/multisite-configuration-with-docker/14084/184?u=yaxu