Ok, eu entendo isso. Não seria possível otimizar o processo de bootstrapping/compilação para demorar mais (CPU/serializar), mas dentro de recursos limitados (ou seja, RAM)?
Acho que seria uma ótima ideia. E um dos motivos é este: se não se pode compilar em um servidor pequeno, então não se pode instalar em um servidor pequeno. E se se instala em um servidor de tamanho médio, não se criará o swapfile que será necessário no servidor pequeno. (Idealmente, o script de instalação criaria o swapfile de qualquer maneira, e também definiria os dois parâmetros ajustáveis do kernel que deveriam ser definidos.)
Esta também é uma ótima ideia. Da mesma forma que, idealmente, um processo de engenharia de software monitora os tempos de compilação, porque, caso contrário, os tempos de compilação ficam cada vez mais longos, para o Discourse o processo idealmente testaria e monitoraria a instalabilidade em instâncias pequenas. Torne isso uma meta.
Eu experimentei criar imagens inicializadas que migram e pré-compilam ativos no lançamento (com configurações de ENV para pular essas tarefas). Isso funciona na maioria das vezes (não tanto para sites enormes e para coisas que dependem do lançamento para acontecer em um certo período de tempo).
No entanto, essas dependem da existência de redis e postgres.
Com uma instalação de 2 contêineres, na maioria dos casos, pode ser possível fazer com que funcione na maioria das vezes.
Ooooooooooooooooooooooh, mas a pré-compilação de ativos, acho que é a etapa que está causando os problemas. . .
Estou lendo sobre esta atualização do Ember 5 que está passando pelo sistema. Que impacto isso teria nos recursos de compilação?
Acho que a documentação precisa de uma atualização, discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- O padrão de 1 GB de RAM funciona bem para pequenas comunidades Discourse.
1 GB não é mais uma opção. O requisito mínimo é de 2 GB para construir o Discourse.
Tenho vários sites que atualizei recentemente com 1 GB de RAM. No entanto, aumentei o swap deles para 3 ou 4 GB.
Certamente não recomendo, mas para algumas pessoas é uma barreira de custo enorme e elas conseguem se virar. Mas talvez “funciona bem” seja um exagero.
Sim, talvez especifique isso, 1 GB de RAM + 4 GB de swap. Falhou com 2 GB de swap.
Você tem algum plugin? Muitos temas?
9 plugins e apenas 1 tema. Novamente, tudo isso funcionou bem até a versão 3.1.x com 1 GB de RAM e 2 GB de swap (era um pouco lento, talvez 20 minutos para reconstruir, mas sempre funcionou)
Tentando atualizar para a 3.2.0 falhou consistentemente (veja acima).
Sim. Definitivamente sem plugins com 1 GB de RAM. Isso parece algo a ser adicionado à documentação de instalação.
Eu gostaria de saber se funcionou sem os plugins.
Como uma abreviação extrema, posso ver por que você diria isso, mas você não concorda que o critério de aprovação/rejeição para executar o Discourse é RAM + swap? 1+3 é tão bom quanto 2+2 do ponto de vista de aprovação/rejeição.
É apenas o desempenho (responsividade) que se importa com a quantidade de RAM que você tem.
RAM + swap é a coisa certa a verificar e testar. Memória = RAM + swap.
Aliás, se algo não está funcionando sem evidências óbvias do porquê, e especialmente se você suspeita de falta de memória, vale a pena verificar o “out-of-memory killer”, também conhecido como OOM-killer. Eu recomendo
dmesg|egrep -i "memory|oom|kill"
Editar: por conveniência, adicionarei isso à minha lista de diagnósticos instantâneos padrão:
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
Encontrei o mesmo problema, mas não durante uma atualização, e sim ao realizar uma instalação limpa da versão 3.2.0.
Estou usando AWS EC2, assim como o @RBoy.
Estou buscando uma solução para instalar a versão 3.1.5 em vez da 3.2.0, já que o fórum antigo não ofereceu nenhuma assistência.
ATUALIZAÇÃO:
desculpe, encontrei isto:
Teria muito interesse em saber se você conseguiu fazer uma instalação limpa da versão 3.1.5 usando o método de tag mencionado em seu link. Por favor, poste de volta se você tentar.
Quanto à instalação da versão 3.2.0 em um sistema de 1 GB, você poderia tentar o seguinte: defina o tamanho do seu SWAP para 8 GB e veja se funciona. Provavelmente ficará MUITO LENTO, mas pode funcionar.
Obrigado por sua orientação atenciosa.
Recentemente, concluí uma instalação limpa da versão Docker do Discourse 3.15 e queria compartilhar o quão simples foi o processo, especialmente para aqueles que usam o nível gratuito da AWS EC2, como eu.
Aqui está um guia conciso baseado na minha experiência:
-
Navegue até o arquivo de configuração do Discourse localizado em
/var/discourse/containers/app.yml. -
Na seção
params, atualize o parâmetroversionpara corresponder à versão desejada do Discourse. Por exemplo:params: # ... ## Specify the Git revision for this container (default: tests-passed) version: v3.1.5 # Use o nome da tag específica aqui -
Salve suas alterações e saia do editor. Em seguida, execute o seguinte comando para reconstruir seu aplicativo Discourse:
/var/discourse/launcher rebuild app
O processo funcionou perfeitamente para mim, provando que manter uma configuração de Discourse de baixo custo ou até mesmo sem orçamento é totalmente viável.
Espero que este guia ajude outras pessoas que procuram gerenciar suas instalações do Discourse de forma eficiente e econômica.