Falha ao inicializar devido ao "out of memory killer"

Ei pessoal,

Quero atualizar meu Discourse com ./launcher rebuild app. Estava funcionando bem há cerca de um ano. Faço a atualização sempre que necessário, a cada 2 a 4 semanas.

Estou no Ubuntu 18.04.5 LTS

***@***:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic

Hoje ele parou com o seguinte erro:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' failed with return #<Process::Status: pid 726 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
db6d1b1dd685de69942a3df05c9cbd622860faaa286b042635878519d5b69b7b
** FAILED TO BOOTSTRAP ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.

O primeiro erro acima dessa mensagem foi:

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0xa04200 node::Abort() [node]
 2: 0x94e4e9 node::FatalError(char const*, char const*) [node]
 3: 0xb7978e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xb79b07 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xd34395  [node]
 6: 0xd46c01 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 7: 0xd0c472 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
 8: 0xd086c2 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
 9: 0xd08774 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
10: 0xf4ef4b v8::internal::OrderedHashTable<v8::internal::OrderedHashSet, 1>::Allocate(v8::internal::Isolate*, int, v8::internal::AllocationType) [node]
11: 0xf4f0df v8::internal::OrderedHashTable<v8::internal::OrderedHashSet, 1>::Rehash(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashSet>, int) [node]
12: 0x103eb98 v8::internal::Runtime_SetGrow(int, unsigned long*, v8::internal::Isolate*) [node]
13: 0x1401219  [node]
Aborted (core dumped)
rake aborted!
Errno::ENOENT: No such file or directory @ rb_file_s_size - /var/www/discourse/public/assets/discourse/tests/test_helper-a9cbc4e1abdd1f2e9afced86d051cbd63c2e224dafe782533646a01592cc1f42.js
/var/www/discourse/lib/tasks/assets.rake:290:in `size'
/var/www/discourse/lib/tasks/assets.rake:290:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:281:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:272:in `each'
/var/www/discourse/lib/tasks/assets.rake:272:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:269:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2021-04-26T13:10:13.996101 #1]  INFO -- : Downloading MaxMindDB...
Compressing Javascript and Generating Source Maps

I, [2021-04-26T13:10:14.018697 #1]  INFO -- : Terminating async processes
I, [2021-04-26T13:10:14.020721 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 55
I, [2021-04-26T13:10:14.022854 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 172
172:signal-handler (1619442614) Received SIGTERM scheduling shutdown...
2021-04-26 13:10:14.023 UTC [55] LOG:  received fast shutdown request
2021-04-26 13:10:14.030 UTC [55] LOG:  aborting any active transactions
2021-04-26 13:10:14.043 UTC [55] LOG:  background worker "logical replication launcher" (PID 64) exited with exit code 1
2021-04-26 13:10:14.045 UTC [59] LOG:  shutting down
2021-04-26 13:10:14.073 UTC [55] LOG:  database system is shut down
172:M 26 Apr 2021 13:10:14.122 # User requested shutdown...
172:M 26 Apr 2021 13:10:14.123 * Saving the final RDB snapshot before exiting.
172:M 26 Apr 2021 13:10:14.270 * DB saved on disk
172:M 26 Apr 2021 13:10:14.271 # Redis is now ready to exit, bye bye...

O Discourse não está rodando após isso. Só volta a funcionar se eu reiniciar o servidor. Mas aí não consigo rodar o rebuild app novamente. Mesmo erro.

Conseguem me ajudar a resolver isso?

Atenciosamente

Seu servidor está ficando sem memória durante o bootstrap. Você pode compartilhar a saída de free -m?

1 curtida
**@**:~# free -m
              total        used        free      shared  buff/cache   available
Mem:            985         777          70          49         136          44
Swap:          2047         228        1819

Hmm, estou me perguntando sobre a falta de memória também após a reinicialização. Além disso, não instalei nada adicional desde a última atualização.

Tenho o mesmo problema. Memória insuficiente para o nodejs.
Usei “export NODE_OPTIONS=”–max_old_space_size=4096 --some_other_option"", mas não funcionou.

Também tive o mesmo rastreamento de pilha ao tentar reconstruir. É uma instalação relativamente nova que estou usando apenas para desenvolvimento e testes, então ainda deve haver bastante espaço, certo?

SO: Ubuntu 20.04.1 LTS
saída de free -m:

root@discourse-test-environment:/var/discourse# free -m
              total        used        free      shared  buff/cache   available
Mem:            981         136         581           0         263         698
Swap:          2047         113        1934
1 curtida

Isso está um pouco abaixo do mínimo de 1 GB. Você pode tentar aumentar um pouco a área de swap, mas recomendo mais RAM.

Se você está recebendo esse erro, precisa de mais RAM (ou talvez swap, mas RAM é melhor).

3 curtidas

Ok, mas você pode nos dizer qual é o motivo desse novo comportamento? Isso funcionou por mais de um ano com essa configuração. O que torna o Discourse diferente agora em comparação ao passado?

1 curtida

Obrigado pela recomendação. Sim, é um pouco estranho. Normalmente, consigo me virar com o arquivo de swap padrão de 2 GB em um droplet Digital Ocean de $5. Vou ficar de olho para ver se isso se torna mais comum com as atualizações mais recentes ou algo assim.

De qualquer forma, adicionei muito mais swap (4 GB) em um arquivo separado](https://askubuntu.com/questions/927854/how-do-i-increase-the-size-of-swapfile-without-removing-it-in-the-terminal)

mas a atualização ainda falhou. Talvez mais RAM seja indispensável. É inesperado, pois a instância tem apenas 1 tópico e 1 usuário no momento. Também estou curioso se preciso fazer algo para garantir que o Discourse saiba usar o swap ou se ele está acessível por padrão?

Minha nova saída do free -m

              total        used        free      shared  buff/cache   available
Mem:            981         138         576           0         266         703
Swap:          6143         109        6034
1 curtida

Sim, também estou em um Droplet da Digital Ocean com 1 vCPU e 1GB de vRAM :slight_smile:

1 curtida

Aumentei a memória Swap para 3 GB. Ainda não está funcionando, com o mesmo erro.

1 curtida

Consegui reconstruir minha instância de teste com apenas 2,5 GiB de RAM+swap. No entanto, é possível que sua instância exija mais do que isso.

Você tem algum plugin instalado? Suspeito que um deles esteja causando um uso massivo de memória durante a compilação.

Você pode reconstruir sem os plugins e verificar se isso resolve o problema?

Obrigado por participar-

Por curiosidade, qual é a distribuição entre RAM e swap? E você está considerando apenas o espaço “livre” em ambos ou o tamanho total do arquivo de swap mais a RAM total da instância?

Ah, claro, esqueci de mencionar que eu esperava instalar o plugin de autenticação Discourse OpenID Connect.

Atualmente, também já tenho o plugin Data Explorer instalado.


  • Tentei novamente apenas com o Data Explorer + Docker Manager, sem sucesso; o mesmo stacktrace relatado anteriormente.
  • Tentei novamente sem plugins (apenas Docker Manager), mas a reconstrução ainda não funcionou.

Vou continuar procurando, já que, além de tentar adicionar o plugin ConnectID, não alterei nada desde a instalação original.

Estou tendo um problema que pode estar relacionado no Trouble with `tests/test_helper`? - #2.

Tentei reconstruir o aplicativo sem nenhum plugin. Sem mudança. Mesmo erro.

Não entendi isso, mas parece um bug. Estou tentando fazer um bootstrap neste site. Sem plugins não padrão. Apenas movi os assets de um bucket para outro e tudo está funcionando. Eu estava fazendo mais uma rebuild para adicionar DISCOURSE_S3_UPLOAD_BUCKET ao ENV, para que ele não apareça na UX. Quando isso falhou na primeira vez, comentei essa linha e tentei novamente com a mesma configuração que funcionou há 3 dias.


Done compressing embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js : 0.17 secs

844614.350963717 Compressing: discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js
terser '/var/www/discourse/public/assets/discourse/tests/_test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js' -m -c -o '/var/www/discourse/public/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js' --source-map "base='/var/www/discourse/public/assets/discourse/tests',root='/assets/discourse/tests',url='https://CORRECT_CDN_ADDRESS.b-cdn.net/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js.map'"
Killed
rake aborted!
Errno::ENOENT: No such file or directory @ rb_file_s_size - /var/www/discourse/public/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js
/var/www/discourse/lib/tasks/assets.rake:290:in `size'
/var/www/discourse/lib/tasks/assets.rake:290:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:281:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:272:in `each'
/var/www/discourse/lib/tasks/assets.rake:272:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:269:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2021-04-26T18:38:36.072881 #1]  INFO -- : Updating Discourse Loading Slider...
Downloading MaxMindDB...
Compressing Javascript and Generating Source Maps

Perguntei-me se haveria algum problema com a URL do CDN, mas todas as linhas acima a incluíam e funcionaram bem.

Isso significa que há CSS defeituoso no tema deles? Se sim, ai. Há apenas algum CSS no tema mestre deles. Além desses componentes: https://github.com/discourse/DiscoTOC.git e https://github.com/davidtaylorhq/discourse-loading-slider.git

Este é um droplet de tamanho mínimo? Parece que esse arquivo é um pouco difícil para o terser comprimir, pois causa muita pressão de memória.

Ah. É surpreendentemente pequeno. É um site que, acho, vocês configuraram há alguns anos (quando ainda rodavam um site não na sua infraestrutura).

root@community:/var/discourse# free -h
              total        used        free      shared  buff/cache   available
Mem:           1.9G        1.2G        101M        259M        655M        354M
Swap:          2.0G        1.2G        773M

Ah. OK. É um droplet DO de 2GB, e tenho acesso ao painel de controle deles. Vou avisar que precisamos fazer upgrade para 4GB e movê-los para um AMD.

EDIT: Mas se isso é apenas para compactar aquele arquivo, um droplet de 2GB não deveria ser suficiente?

Esse arquivo de teste-helper é pesado para a compressão.

  • O UglifyJS usa 1,5 GB de RAM para comprimi-lo.

  • O Terser usa um pouco mais de 1 GB. Leva 40s. Para comparação, o mesmo servidor leva 8s no Ember+jQuery :scream:

@eviltrout, devemos mesmo ter esse arquivo em produção?

Ah, parece que vem dessa mudança do @Osama

-rw-r--r-- 1 discourse discourse  14M Apr 26 19:13 _test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js
-rw-r--r-- 1 discourse discourse 6.6M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js
-rw-r--r-- 1 discourse discourse 1.1M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.br
-rw-r--r-- 1 discourse discourse 1.5M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.gz
-rw-r--r-- 1 discourse discourse 5.7M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.map
8 curtidas

Só para adicionar outro dado: ainda estou enfrentando falhas na reconstrução após remover os dois componentes do tema. Então, estou usando apenas o tema Light padrão.

Também, de onde vem essa saída? Estou procurando verificar/depsurar um pouco do meu lado também. Isso seria algo como uma opção verbosa no ./launcher rebuild app?

Corrigir isso corretamente vai levar um pouco de tempo, então vou reverter essa alteração por enquanto.

9 curtidas