Impossibile avviare a causa dell'out of memory killer

Ciao a tutti,

Voglio aggiornare il mio Discourse con ./launcher rebuild app. Funzionava perfettamente da circa un anno. Lo aggiorno, se necessario, ogni 2-4 settimane.

Sono su 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

Oggi si blocca con questo errore:

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 ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

Il primo errore prima di questo messaggio era:

<--- 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...

Discourse non è più attivo dopo questo. Funziona solo se riavvio il server, ma poi non riesco più a eseguire rebuild app. Stesso errore.

Potreste aiutarmi a risolvere il problema?

Cordiali saluti

Il tuo server sta esaurendo la memoria durante l’avvio. Puoi condividere l’output di free -m?

1 Mi Piace
**@**:~# free -m
              totale       usato       libero    condiviso  buffer/cache   disponibile
Mem:            985         777          70          49         136          44
Swap:          2047         228        1819

Hm, mi chiedo perché si esaurisca la memoria anche dopo il riavvio. Inoltre, non ho installato nulla di nuovo dall’ultimo aggiornamento.

Ho lo stesso problema. Memoria non sufficiente per nodejs.
Ho usato “export NODE_OPTIONS=”–max_old_space_size=4096 --some_other_option"", ma non ha dato risultati.

Ho riscontrato anche la stessa stacktrace quando ho provato a ricostruire. L’installazione è relativamente recente e la sto usando solo per sviluppo e test, quindi dovrei ancora avere una buona quantità di spazio, penso?

OS: Ubuntu 20.04.1 LTS
Output di 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 Mi Piace

È un po’ sotto il minimo di 1 GB. Puoi provare ad aumentare leggermente lo swap, ma ti consiglio di aggiungere più RAM.

Se ricevi quell’errore, hai bisogno di più RAM (o forse di più swap, ma la RAM è meglio).

3 Mi Piace

Va bene, ma puoi dirci qual è la ragione di questo nuovo comportamento? Funziona con quella configurazione da oltre un anno. Cosa rende Discourse diverso ora rispetto al passato?

1 Mi Piace

Grazie per il consiglio. Sì, è un po’ strano; di solito mi sono arrangiato con il file di swap predefinito da 2 GB su un droplet DigitalOcean da 5 $. Continuerò a monitorare se questo diventerà più comune con gli ultimi aggiornamenti o per qualche altro motivo.

Comunque, ho proceduto ad aggiungere molto più swap (4 GB) in un file separato

ma l’aggiornamento è comunque fallito. Forse più RAM è indispensabile. È inaspettato, dato che l’istanza ha al momento solo 1 argomento e 1 utente. Sono anche curioso di sapere se devo fare qualcosa per assicurarmi che Discourse sappia utilizzare lo swap o se è accessibile di default.

Il mio nuovo output di free -m..

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

Sì, anch’io sono su un Droplet Digital Ocean con 1 vCPU e 1 GB di vRAM :slight_smile:

1 Mi Piace

Ho aumentato la memoria Swap a 3 GB. Non funziona ancora, con lo stesso errore.

1 Mi Piace

Riesco a ricreare la mia istanza di test con solo 2,5 GiB di RAM+swap. Tuttavia, è possibile che la tua istanza richieda più di così.

Hai installato dei plugin? Sospetto che uno di essi stia causando un consumo eccessivo di memoria durante la compilazione.

Puoi provare a ricreare l’istanza senza i plugin e verificare se questo risolve il problema?

Grazie per aver risposto-

Per pura curiosità, qual è la ripartizione tra RAM e swap? Stai contando solo lo spazio “libero” su entrambi o la dimensione totale del file di swap più la RAM totale dell’istanza?

Ah, certo, scusa: avevo dimenticato di menzionare che speravo di installare il plugin di autenticazione Discourse OpenID Connect.

Attualmente ho già installato anche il plugin Data Explorer.


  • Ho riprovato con solo Data Explorer + Docker Manager, ma senza successo; lo stack trace è lo stesso condiviso in precedenza.
  • Ho riprovato senza plugin (solo Docker Manager), ma la ricostruzione non ha funzionato comunque.

Continuerò a cercare, dato che, a parte il tentativo di aggiungere il plugin ConnectID, non ho apportato alcuna modifica dall’installazione originale.

Sto riscontrando un problema che potrebbe essere correlato qui: Trouble with `tests/test_helper`? - #2.

Ho provato a ricostruire l’app senza alcun plugin. Nessun cambiamento. Stesso errore.

Non capisco, ma sembra un bug. Sto cercando di eseguire un bootstrap su questo sito. Nessun plugin non standard. Ho appena spostato le risorse da un bucket all’altro e tutto funziona. Stavo facendo un’ulteriore ricompilazione per aggiungere DISCOURSE_S3_UPLOAD_BUCKET all’ENV in modo che non appaia nell’interfaccia utente. Quando è fallito la prima volta, ho commentato quella riga e ho riprovato con la stessa configurazione che funzionava 3 giorni fa.


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

Mi chiedevo se ci fosse qualche problema con l’URL del CDN, ma tutte le righe sopra lo includevano e funzionavano correttamente.

Significa che c’è un CSS difettoso nel loro tema? Se è così, che disastro. C’è solo un po’ di CSS nel loro tema master. Inoltre questi componenti: https://github.com/discourse/DiscoTOC.git e https://github.com/davidtaylorhq/discourse-loading-slider.git

Si tratta di un droplet di dimensioni minime? Sembra che quel file sia piuttosto difficile da comprimere per terser, poiché causa un’elevata pressione sulla memoria.

Oh. È sorprendentemente piccolo. È un sito che penso abbiate impostato voi qualche anno fa (quando gestivate ancora un sito non sulla vostra infrastruttura).

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. È un droplet DO da 2 GB e ho accesso al loro pannello di controllo. Dirò loro che dobbiamo passare a 4 GB e spostarli su un processore AMD.

MODIFICA: Ma se si tratta solo di comprimere quel singolo file, non dovrebbe essere sufficiente un droplet da 2 GB?

Questo file di test-helper è pesante per la compressione.

  • UglifyJS utilizza 1,5 GB di RAM per comprimerlo.

  • Terser ne usa poco più di 1 GB. Ci mette 40 secondi. Per confronto, sullo stesso server, la compressione per Ember+jQuery impiega 8 secondi :scream:

@eviltrout dovremmo davvero mantenere questo file in produzione?

Ah, sembra che provenga da questa modifica di @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 Mi Piace

Aggiungo un altro dato: sto ancora riscontrando fallimenti nella ricostruzione dopo aver rimosso i due componenti del tema. Quindi sto usando solo il tema Light predefinito.

Inoltre, da dove proviene questo output? Sto cercando di verificare e fare un po’ di debug anche dal mio lato. È qualcosa come un’opzione dettagliata per ./launcher rebuild app?

Riparare questo correttamente richiederà un po’ di tempo, quindi per ora procederò a annullare quella modifica.

9 Mi Piace