Tentei atualizar no prompt de 3.2.0.beta3-dev para 3.2.0.beta3 e isso quebrou minha instância do Discourse devido à falta de memória durante o build do ember dos ativos. Tentei ./launcher rebuild app com o mesmo resultado.
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9 [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1] INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Estou rodando em uma instância da DigitalOcean com 1GB para uma organização sem fins lucrativos, então não posso me dar ao luxo de redimensioná-la com mais memória. 1GB é o tamanho mínimo para o discourse e versões anteriores costumavam rodar sem problemas. Alguma ideia de como fazê-lo funcionar novamente?
Meu site de teste DO de 1 GB também tem tido problemas de memória durante as reconstruções recentemente. Eu o atualizei temporariamente para 2 GB apenas para conseguir concluir.
Adicionar 1G de swap deve ser funcionalmente o mesmo que adicionar 1G de RAM, se você tiver espaço em disco para isso. (Provavelmente levará mais tempo para executar a atualização, mas isso é desempenho, em vez de função. O que você deseja é evitar a situação de falta de memória.)
Tenho informações adicionais caso ajudem a mitigar o problema do lado do Discourse. Minha instância (DigitalOcean ~1GB droplet com 2GB de swap) recentemente começou a demorar significativamente mais para reconstruir e relatar o mesmo erro fatal cerca de 3 em cada 4 vezes (a sorte parece melhorar após executar ./launcher cleanup, mas não tenho tamanho de amostra suficiente para confirmar isso).
Pouco antes do erro de falta de memória heap, estas linhas são registradas:
Node.js heap_size_limit (491.0) é menor que 1024MB. Definindo --max-old-space-size=1024.
Node.js heap_size_limit (491.0) é menor que 2048MB. Desabilitando a paralelização do Webpack com JOBS=0 para conservar memória.
Estou fora do meu domínio aqui, então peço desculpas se eu errar algo. Alguma pesquisa rápida indica que o ember-cli depende do node.js, que é por isso que acho que isso é relevante. O sinalizador --max-old-space-size pode potencialmente ser definido mais alto que a RAM (ele apenas entraria no espaço de swap, o que, como mencionado, está bom para este caso), então talvez 1024 seja um teto artificial que estamos atingindo contra o qual as reconstruções do Discourse não podem mais ser contidas.
Notas paralelas: aparentemente --optimize-for-size é um sinalizador do node.js que ajuda a reduzir o uso de memória (não tenho certeza se está sendo usado pelo Discourse/ember, talvez já esteja), e há uma anedota por aí de que o coletor de lixo não está ativado para certos usos do node.js, o que pode ser um problema.
Se algo disso for relevante e controlável do lado do Discourse do uso do ember/node.js, pode valer a pena alguém investigar. Se não, sem problemas, farei a solução temporária de upgrade de 2GB proposta acima.
Esse é um ótimo ponto! No momento, aumentamos para 1024mb em máquinas com pouca RAM aqui. Certamente poderíamos experimentar aumentar isso para 1500 ou 2000 e ver se ajuda.
Se você tiver tempo/inclinação para experimentar por conta própria, poderá configurá-lo adicionando uma nova variável à seção env: do seu arquivo app.yml:
Editar: este é agora o padrão do Discourse. Não é necessário configurar sozinho
Como o erro fatal não acontece toda vez, e uma reconstrução leva cerca de 25 minutos ultimamente (em vez de 5-10), pode levar algum tempo até que eu saiba se aumentar esse número resolve o problema de memória para essas especificações de servidor.
Mas, já posso confirmar que os dois avisos de Node.js heap_size_limit não aparecem mais no log de reconstrução, e minha primeira reconstrução foi bem-sucedida, então isso é promissor.
EDIT: Consegui reconstruir várias vezes sem problemas, graças à configuração NODE_OPTIONS acima em meu app.yml. Yay!
EDIT2: Essa solução provavelmente deveria fazer parte do Discourse, aumentando esse número mágico (link da postagem de David) para que outras máquinas com pouca RAM continuem operando. Se alguém ler isto e souber como fazer isso, seria ótimo.
Executamos ./launcher rebuild app algumas vezes e falhou com vários problemas.
Primeiro, tivemos problemas com bundle install reclamando de rbtrace (terminando com An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.).
Eventualmente, tivemos esse problema de OOM:
I, [2023-12-12T07:50:59.497921 #1] INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
<--- Last few GCs --->
[3683:0x5dab130] 279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.
E finalmente, executá-lo com ./discourse_doctor conseguiu passar por isso eventualmente (mas por quê? mais coisas no cache em execuções subsequentes que fizeram com que usasse menos memória? )
I, [2023-12-12T08:02:50.556442 #1] INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets
Mas isso foi um atrito que não deveríamos ter encontrado. Espero que isso melhore no futuro.
A título de informação:
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.3Gi 87Mi 138Mi 593Mi 394Mi
Swap: 2.0Gi 337Mi 1.7Gi
Com certeza, é por isso que estamos reunindo informações aqui.
Parece que ajustar nossa variável de ambiente NODE_OPTIONS é tudo o que é necessário, então eu adivinharias que uma dependência do aplicativo ou uma alteração no V8 fez com que nosso valor anterior lá não funcionasse mais.
Parece bom para mim! Obviamente, reconstruções de mais de 30 minutos ainda não são ideais, então espero que possamos melhorar as coisas em um futuro não muito distante. Mas esta parece ser uma boa solução para estancar a sangria.
Vale ressaltar que o aumento da versão do postgres 16 em comparação com a versão 13 consome menos espaço e é muito melhor otimizado. Isso pode reduzir a quantidade total de memória do servidor consumida.
este é agora o padrão do Discourse. Não é necessário configurar sozinho
)