Requisitos elevados de memória para reconstrução: edição de abril de 2025

Suporte Instalação
21

Ok, próximo teste concluído.

Compilei com os seguintes plugins:

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

O swap foi desabilitado, então apenas 4GiB/3.8GB de RAM.

O uso máximo de memória durante a compilação foi de 3.4GB. O tempo de compilação foi de 6m 48s.

4 curtidas
22

A caminho o problema é o arquivo de troca (swap file), depois de aumentar de 0 para 2GB, tudo está ok por enquanto.

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

no terminal do seu servidor. Depois disso, reconstrua.

2 curtidas
23

Estou enfrentando um grande aumento na memória necessária para reconstruir. Tenho 8GB de memória e, mesmo adicionando um arquivo de troca (swapfile) de 8GB, ele fica sem espaço nesta etapa: cd /var/www/discourse && sudo -E -u discourse bundle exec rake multisite:migrate

É uma instalação multisite com quatro fóruns. Eu não precisei adicionar um arquivo de troca antes.

edite Agora tentei com 16G de troca e ainda está ficando sem memória.

Isso é em Linux, com plugins mínimos ativados.

2 curtidas
24

Hmm… Eu me pergunto, a documentação deveria ser atualizada para refletir requisitos de memória mais altos? O Introducing pre-compiled JS assets for self-hosters ajudou a diminuir o carregamento? Eu teria pensado que com essa mudança, menos RAM seria necessária :thinking: .

25

Pode ter passado alguns meses desde que fiz uma reconstrução, mas estava tudo bem antes com 8GB de RAM e sem swap. Eu ainda não resolvi isso e, por isso, todos os quatro sites estão fora do ar.

Não sei se isso está relacionado, mas não compilava até que eu definisse a variável de ambiente HOME: /var/www/discourse — caso contrário, ele tentava escrever em /root e recebia permissão negada.

26

Hmm, estou vendo mais de cem desses processos:

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

É algum tipo de bomba de fork?

1 curtida
27

Adicione definitivamente MUITO espaço de troca (swap), mesmo que seja apenas para que você volte a funcionar. A vantagem de usar swap aqui é que as compilações são um pico temporário.

Eu uso a configuração de dois contêineres e a memória fica ainda mais sob pressão durante a inicialização, pois você também tem dois contêineres em execução. :sweat_smile:

28

Adicionei 40GB de swap agora e não é suficiente.

Estou vendo centenas desses processos de nó, isso parece ser o problema?

Estou começando a pensar que a causa raiz é a mesma do meu problema anterior, onde eu tinha que definir HOME: /var/www/discourse, caso contrário, ele tentaria gravar arquivos em /root. Não sei o que fazer a respeito, no entanto.

2 curtidas
29

Ok, algo está muito errado. Eu também consideraria fazer um backup e recriar do zero.

1 curtida
30

Como eu faria isso?

31

Veja:

32

Obrigado, acho que vou reverter o servidor inteiro para um estado conhecido como bom pela última vez e fazer backup a partir de um sistema funcional.
Alguém tem ideias sobre o que pode ter dado errado?

1 curtida
33

O problema era de fato com o HOME não estar configurado corretamente, adicionar -H ao comando sudo para a migração multisite resolveu, conforme detalhado aqui:

6 curtidas