Agradeço, mas reconstruir o aplicativo leva cerca de 3 horas!
E isso em um VPS enorme.
Não seria legal poder remover plugins assim como podemos adicionar e remover temas?
Talvez algo a ser considerado como um recurso no futuro?
Obrigado!!
1 curtida
Desculpe?! Deveria levar ~20 minutos?!
1 curtida
não aqui
A instalação original levou 2 horas.
Agora, o ./launcher rebuild app está preso em:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
E após a última linha, ele fica piscando (o processo está em andamento)
Isso já faz uns 30 minutos.
Da última vez que fiz isso, levou 160 minutos completos.
Memória Total do Servidor: 4.657GiB, Versão do Kernel: 5.15.0-43-generic, Sistema Operacional: Ubuntu 22.04 LTS, disco SSD de 50GB, 2.5 Cores, 5 Threads Intel® Xeon® CPUs
…
Não tenho certeza do que pode estar errado, além de demorar muito tempo 
3 horas parece muito errado mesmo. Você precisa investigar esse problema e resolvê-lo como primeira prioridade.
Existem ‘pausas visuais’ no log de build, isso é normal, mas esse atraso não é.
Minha suspeita é que de alguma forma você está começando a usar swap durante o build, mas não sou um SA. Você está executando mais alguma coisa nessa máquina?
Downloads exigem descompactação, e isso é computacionalmente caro, mas são as mesmas imagens para todos.
Como referência, acabei de reconstruir um site agora mesmo e levou 13 minutos e 46 segundos em uma máquina de 2GB 2vCPU em https://scaleway.com
4 curtidas
Não, este é um VPS que é exclusivamente para esta instância do Discourse. E eu executo muitos outros VPS com a mesma empresa, que funcionam perfeitamente (mas não são instâncias do Discourse, são outros aplicativos como instâncias personalizadas de PHP ou CMS WP/CP, etc.).
Não estou ciente de nenhum uso de swap e não consigo ver nenhum pico no uso de recursos que justificaria.
Agora está em building.... - parece um pouco mais rápido do que da última vez, no entanto, ainda está claramente acima de 20 minutos.
Vou perguntar aos provedores de servidor se eles podem detectar algo incomum em seus sistemas, no entanto, lembro-me que eles me disseram pessoalmente que a própria instância do Discourse deles levou cerca de 2 horas para ser construída. (PS Estes VPS estão em máquinas Hetzner alugadas através de terceiros, duvido que eu possa conseguir algo melhor.)
Em qualquer caso, minha sugestão permanece que seria incrível poder adicionar e remover plugins como podemos fazer com temas. Talvez seja algo a considerar?
Eu realmente não sei nada, mas AFAIK não é possível, porque o Discourse é feito de muitos javascripts compilados. Quando há necessidade de adicionar ou remover algo que muda como o núcleo está agindo e funcionando, é preciso reconstruir.
Situação muito semelhante à do Varnish, por exemplo.
1 curtida
Ok…
A propósito, verifiquei com o pessoal do servidor e, de fato, atingimos 100% de memória.
5 GB ??? 5 GB de RAM é um pouco demais para consumir em qualquer coisa.
Os requisitos do Discourse dizem que ele precisa de 1 GB de RAM!
E agora está travado no seguinte:
104:M 04 Oct 2022 07:19:27.251 # O Redis está pronto para sair, tchau tchau...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Removendo contêiner antigo
+ /usr/bin/docker rm app
app
Assim, não consigo nem atualizar o servidor, pois o processo seria interrompido.
Realmente, não acho que isso seja um problema de servidor. Se precisarmos de 1 GB, então 5 GB deveriam ser mais do que suficientes.
Algo está errado com isso, imensamente errado.
Entendo que outros devem ter uma experiência melhor (olhando para @merefield que disse para atualizar em um de 2 GB…), mas não está funcionando para nós como deveria.
De qualquer forma, isso está fora do tópico desta thread, eu acho.
1 curtida
Acabei de reconstruir outro site, 4 GB, 3 vCPU, novamente em menos de 15 minutos (ou seja, a memória/CPU extra não ajudou muito no meu caso, mas ainda longe de horas!).
A única coisa que notei é que meu VPS usa vfs em vez de aufs ou overlay sugeridos.
No entanto, de acordo com isto Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david, não deveria ser nada importante, e assim executamos o launcher com --skip-prereqs, porque de outra forma nem conseguimos executar o Discourse.
Fico a pensar se há mais nesse requisito do driver de armazenamento.
1 curtida
Isso é um pouco… otimista demais. Para fins de teste pode ser o suficiente, e pode ser um pouco apertado mesmo assim. 2 GB é muito mais próximo da realidade.
4 GB é o suficiente para instâncias maiores, no entanto. Mas a quantidade e a potência dos núcleos também desempenham um papel importante.
E ainda assim… se você tem 5 GB e a reconstrução leva tanto tempo, deve haver algo errado.
Estou no DigitalOcean/4 GB/2 vcpu Intel e a reconstrução leva cerca de 25 minutos.
Qual é o seu sistema exatamente, mais o app.yml — há algo personalizado?
Olá, o único customização é o que mencionei antes (vfs em vez de aufs/overlay)
O resto é vanilla.
Servidor:
Memória Total do Servidor: 4.657GiB, Versão do Kernel: 5.15.0-43-generic, Sistema Operacional: Ubuntu 22.04 LTS, SSD de 50GB, 2.5 Cores, 5 Threads Intel® Xeon® CPUs
yaml é original, exceto por estes plugins adicionais:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
Não vejo, com base nesses dados, por que a reconstrução levaria tanto tempo.
Eu faria um teste em um VPS Ubuntu de mesmo tamanho em outro lugar. Apenas para descobrir se o problema vem da empresa de hospedagem. Isso custa alguns trocados e uma ou duas horas de trabalho.
Muita memória é necessária para pré-compilar o javascript. Tente adicionar swap.
A sobreposição
Acho que esse teste pode estar lá por um motivo. Este pode ser o seu problema.
1 curtida
Por que 5 GB de RAM com Discourse vanilla precisariam de mais swap se outros menores estão totalmente satisfeitos com o que receberam automaticamente?
Porque é mais fácil do que fazer o que você realmente precisa fazer.
Adicionar swap pode ajudar, mas não é o seu maior problema.
3 curtidas
Presumo que eu deveria ter tentado isso antes de implantar o contêiner do discourse: How to change the Docker storage driver – Webdock
Aparentemente é possível alterar o driver de armazenamento - ao contrário do que o host me instruiu quando implantamos o contêiner (que era editar o arquivo do loader ou ignorar a verificação)
Duh, agora é tarde demais, suponho.
Obrigado de qualquer forma, se esta for a causa dos problemas, acho que é erro do usuário. Mea culpa 
Eu não pensaria assim.
Além disso, a configuração de dois contêineres reduziu o tempo de inatividade, pois você reconstrói o novo contêiner da web via CSV enquanto o antigo continua em execução.
1 curtida
Qual o tamanho do seu site? Eu adicionaria swap independentemente para resolver o problema de memória.
Uma instância em branco de 1 GB com 1 GB de swap funciona bem para uma pequena comunidade de teste, mas assim que ela crescer, isso não será suficiente. O swap faz absolutamente a diferença.
Se reconstruir em um VPS “enorme”, localizado em um data center com uma conexão robusta à internet leva 3 horas, e reconstruir minha instalação em https://discourse-on-a-pi.falco.dev que roda em uma placa do tamanho de um cartão de crédito na minha mesa, conectada à internet via um plano doméstico padrão em um país do terceiro mundo leva apenas 14 minutos (+4 minutos quando há uma nova imagem de contêiner) há algo errado no produto que estão te vendendo…
15 curtidas
Como está o uso de memória no servidor? Se você estiver no limite ou perto dele antes de começar a reconstruir, terá muita paginação e isso certamente fará com que tudo demore excessivamente.
Se for esse o caso, sugiro que você desabilite temporariamente qualquer outra coisa que possa estar rodando no servidor, se possível.
3 curtidas