Parece que 2+2 pode não ser mais suficiente… Estou gerenciando uma instância Discourse bastante modesta (sem plugins grandes/sofisticados, etc.) que, a partir de hoje, está falhando ao inicializar porque o Ember está consumindo toda a RAM que encontra, e todo o swap, e travando a máquina até a falta de resposta. Adicionar mais 2GB de swap permitiu que a inicialização fosse concluída, com um pico de uso de swap de cerca de 2,5GB.
Nossa, isso está na lista do @david para investigar.
5 curtidas
@david tem investigado, confirmamos que, no momento, 2 GB é suficiente para reconstruções do Docker, mas não o suficiente para o atualizador da web funcionar.
Uma ideia que discuti é simplesmente desligar todos os processos Ruby durante o atualizador da web para economizar mais 300-500 MB, o que seria suficiente para a pré-compilação de ativos.
Uma abordagem de longo prazo que provavelmente precisaremos adotar para auto-hospedeiros é enviar contêineres inicializados, o que é uma caixa de Pandora, pois como um atualizador da web seria capaz de realizar isso. Não queremos montar soquetes Docker…
É realmente um dilema.
2 curtidas
Bem, não foi para mim.
Isso é comparado entre uma instalação pura básica contra situações do mundo real?
De fato, não é perfeitamente consistente. Mesmo com todo o resto desligado, ainda pode falhar.
Infelizmente, estamos lutando uma batalha perdida contra as ferramentas modernas de build de JS. Tudo é projetado para rodar em 8GB+ de RAM em máquinas de desenvolvedor modernas, não em VPSs de 1GB 
Temos algumas soluções em mente. Por exemplo: fornecer assets pré-compilados que podem ser baixados automaticamente. O grande desafio que temos são os plugins, porque eles variam em cada site, e no momento eles estão integrados de forma rígida ao build principal.
Mas, por enquanto, fazer uma reconstrução completa da CLI deve ter uma taxa de sucesso maior do que uma atualização da interface web.
8 curtidas
Assim como Jagster, 2 GB de RAM + 2 GB de swap não são suficientes para minha reconstrução do Docker acionada por CLI. Verificando mais a fundo, os únicos plugins nesta instalação são docker_manager e discourse-prometheus – nenhum dos quais, eu esperaria, colocaria uma carga inesperada no ember.
Se as especificações mínimas tiverem que mudar, isso seria ruim, mas seria muito melhor do que a situação atual, onde as máquinas inesperadamente param de funcionar em cada atualização.
7 curtidas
Se esse for o caso, acho que ainda seria melhor aumentar um pouco as especificações recomendadas. Pessoalmente, não me importo em adicionar mais 2 GB (ou até 4 GB) de swap se isso tornar as reconstruções mais confiáveis - pelo menos enquanto as operações diárias ainda estiverem bem com 2-4 GB de RAM (para comunidades pequenas a médias).
2 curtidas
De fato, a instalação inicial falhou na minha instalação recente em uma instância 4c 4g. Ed sugeriu a criação de um arquivo de swap. Encontrei o tópico para criar um swap e criei um swap de 4 GB. Agora tudo está funcionando como esperado na atualização/upgrade pela web ou CLI.
Na minha opinião, talvez precisemos apenas aceitar que o Discourse requer mais RAM do que costumava.
3 curtidas
O zram faria sentido?
Nós acabamos de aplicar este commit que esperamos que melhore a situação. Por favor, nos diga como você se sai! (chegará aos testes aprovados nos próximos ~30 minutos)
Ao testar com um contêiner docker com restrição de memória localmente, agora consigo uma compilação bem-sucedida com -m 1600m. Antes desta alteração, o mínimo que eu conseguia era -m 3000m.
12 curtidas
Fiz uma reconstrução de teste (instalação limpa), que ocorreu sem problemas. Agora essa máquina tem 4GiB de RAM (Hetzner CAX11) e um arquivo de paginação do mesmo tamanho, então certamente há menos restrições do que a configuração de 2+2 GB mencionada acima. No entanto, o uso de swap foi mínimo durante toda a compilação e o uso máximo de RAM que vi foi de ~3,1 GB. E na maior parte do tempo, ficou em torno de ~2 GB, então não parece tão ruim (o tempo de compilação foi mais ou menos o mesmo, ou seja, cerca de 8 minutos).
4 curtidas
Gostaria muito de fazer alguns experimentos controlados, com instalações e reconstruções limpas, em uma variedade de configurações e, em particular, gostaria de ver a diferença (se houver) de rodar com vm overcommit, mas receio que me faltou tempo.
(Sem overcommit, um processo grande que faz fork terá um aumento instantâneo na pegada de memória que pode ser fatal, e não aparecerá em um monitor com polling. Mesmo com overcommit, o aumento de memória pode ser rápido o suficiente para não aparecer em um polling, seja htop, vmstat ou outra ferramenta.)
Não acho que já vi alguém se voluntariar sobre se está rodando com ou sem overcommit, embora, na minha opinião, seja um aspecto importante da configuração do host.
1 curtida
Aposto que a maioria das pessoas não o faz.
Eu o configurei automaticamente em minhas instalações. Ainda recebo esse aviso sobre isso, no entanto.
O overcommit é irrelevante aqui, porque o problema não são os processos sendo encerrados prematuramente pelo OOM (Out Of Memory), é apenas tentar colocar dez quilos de memória alocada em um saco de cinco quilos.
Não é praticamente possível executar uma reconstrução do Discourse com overcommit_memory=2, porque o Ember (entre outras coisas, sem dúvida) pré-aloca massas de memória virtual (se bem me lembro, cerca de 80 GB foi o que vi), então isso sempre cairá em qualquer configuração razoável de overcommit_ratio. Definir overcommit_memory=1 também não ajudará, porque, novamente, o problema não é um VMM (Virtual Memory Manager) excessivamente zeloso matando processos, é um gerenciamento de memória terrivelmente ruim do compilador Ember.
1 curtida
Não tenho certeza se concordo totalmente com sua análise! Pelo que entendi, o overcommit permite que os processos aloquem memória que eles não usam. Não se trata apenas do comportamento do OOM-killer. Mas, como disse, gostaria de realizar alguns experimentos controlados, essa é uma maneira melhor de ver o que faz e o que não faz diferença.
Eu tenho 4GB de RAM e muitos plugins (sem arquivo de swap do que estou ciente). Quantos plugins você tem e você acha que apenas 4GB de RAM é suficiente?
Parcialmente correto, mas mesmo assim, é irrelevante, porque o problema discutido neste tópico são processos alocando memória que eles usam, e usando mais do que o sistema tem disponível, o que causa interrupções visíveis para o cliente.
Você pode confirmar que após as alterações do @david os requisitos de memória diminuíram? Devemos estar em um estado razoável agora.
O próximo grande salto será a pré-compilação e os ativos pré-compilados distribuídos, é uma mudança bem grande para chegar lá, mas apagará um grande monte de trabalho da Internet quando concluída.
2 curtidas
Com todo o respeito, não tenho certeza sobre isso. Já vi arquivos de log mostrando falhas na criação de processos (forking). Estamos dizendo neste tópico que são “requisitos de memória”, mas isso inclui, na minha opinião, as táticas do kernel para memória virtual. Claramente, um ou três experimentos mostrarão se estou certo ou não sobre o overcommit.
Essa foi uma construção nova sem qualquer plugin. Posso tentar outra com alguns plugins ativados e talvez desabilitar temporariamente o swap para confirmar se a construção passa (provavelmente levará alguns dias até eu ter tempo, porém).
2 curtidas