Ho provato ad aggiornare al prompt da 3.2.0.beta3-dev a 3.2.0.beta3 e ha interrotto la mia istanza Discourse a causa di memoria insufficiente durante la compilazione di ember degli asset. Ho provato ./launcher rebuild app con lo stesso risultato.
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.
Sto eseguendo su un’istanza DigitalOcean con 1GB per un’organizzazione no-profit, quindi non posso permettermi di ridimensionarla con più memoria. 1GB è la dimensione minima per discourse e le versioni precedenti funzionavano senza problemi. Ci sono idee su come farlo funzionare di nuovo?
Anche il mio sito di test DO da 1 GB ha recentemente riscontrato problemi di memoria durante le ricompilazioni. L’ho temporaneamente aggiornato a 2 GB solo per superare il problema.
Aggiungere 1G di swap dovrebbe essere funzionalmente equivalente all’aggiunta di 1G di RAM, se si dispone di spazio su disco sufficiente. (Probabilmente l’aggiornamento richiederà più tempo, ma questa è una questione di prestazioni, non di funzionalità. Ciò che si desidera è evitare la situazione di esaurimento della memoria.)
Ho informazioni aggiuntive nel caso in cui aiutino a mitigare il problema dal lato di Discourse. La mia istanza (DigitalOcean ~1GB droplet con 2GB di swap) ha recentemente iniziato a impiegare molto più tempo per ricostruire e segnalare lo stesso errore fatale circa 3 volte su 4 (la fortuna sembra migliorare dopo aver eseguito ./launcher cleanup, ma non ho abbastanza campioni per confermarlo).
Poco prima dell’errore di heap out of memory, vengono registrate queste righe:
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
Sono fuori dal mio campo, quindi mi scuso se sbaglio qualcosa. Alcune ricerche rapide indicano che ember-cli dipende da node.js, motivo per cui penso che questo sia rilevante. Il flag --max-old-space-size può potenzialmente essere impostato più in alto della RAM (andrebbe semplicemente nello spazio di swap, che come menzionato va bene in questo caso), quindi forse 1024 è un soffitto artificiale che stiamo colpendo e che le ricostruzioni di Discourse non possono più contenere.
Note a margine: apparentemente --optimize-for-size è un flag di node.js che aiuta a ridurre l’utilizzo della memoria (non sono sicuro se sia utilizzato da Discourse/ember, forse lo è già), e c’è un aneddoto in giro sul garbage collector che non viene attivato per certi usi di node.js, il che potrebbe essere un problema.
Se qualcosa di tutto ciò è rilevante e controllabile dal lato Discourse dell’utilizzo di ember/node.js, potrebbe valere la pena che qualcuno ci dia un’occhiata. Altrimenti, nessun problema, adotterò la soluzione temporanea di aggiornamento a 2GB proposta sopra.
Questo è un ottimo punto! Al momento lo aumentiamo a 1024 MB su macchine con poca RAM qui. Potremmo certamente sperimentare aumentando questo valore a 1500 o 2000 e vedere se aiuta.
Se hai il tempo/inclinazione per provarlo tu stesso, potresti configurarlo aggiungendo una nuova variabile alla sezione env: del tuo file app.yml:
Modifica: questo è ora il default di Discourse. Non è necessario configurarlo da soli
Dato che l’errore fatale non si verifica ogni volta e una ricompilazione richiede circa 25 minuti ultimamente (rispetto ai 5-10), potrebbe passare del tempo prima che io sappia se aumentare quel numero risolve il problema di memoria per queste specifiche del server.
Tuttavia, posso già confermare che i due avvisi Node.js heap_size_limit non compaiono più nel log di ricompilazione e la mia prima ricompilazione è andata a buon fine, quindi è promettente.
EDIT: Sono riuscito a ricompilare più volte senza problemi, grazie all’impostazione NODE_OPTIONS sopra nel mio app.yml. Evvai!
EDIT2: Questa soluzione dovrebbe probabilmente entrare a far parte di Discourse aumentando quel numero magico (link dal post di David) in modo che altre macchine con poca RAM possano continuare a funzionare. Se qualcuno legge questo e sa come farlo, sarebbe fantastico.
Abbiamo eseguito ./launcher rebuild app alcune volte e ha fallito con vari problemi.
Inizialmente abbiamo avuto problemi con bundle install che si lamentava di rbtrace (terminando con An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.)
Poi alla fine abbiamo avuto questo problema di 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 infine, eseguendolo con ./discourse_doctor siamo riusciti a superare quel problema (ma perché? più cose nella cache nelle esecuzioni successive che hanno fatto usare meno memoria? )
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
Ma questo è stato un attrito che non avremmo dovuto incontrare. Speriamo che in futuro migliori.
A titolo informativo:
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.3Gi 87Mi 138Mi 593Mi 394Mi
Swap: 2.0Gi 337Mi 1.7Gi
Certamente, ecco perché stiamo raccogliendo informazioni qui.
Sembra che la modifica della nostra variabile d’ambiente NODE_OPTIONS sia tutto ciò che è necessario, quindi suppongo che una dipendenza dell’app o una modifica di V8 abbia reso il nostro valore precedente lì non più funzionante.
Sembra buono! Ovviamente le ricostruzioni di oltre 30 minuti non sono ancora ideali, quindi spero che potremo migliorare le cose in un futuro non troppo lontano. Ma questa sembra una buona soluzione per fermare le perdite.
Vale la pena notare che l’aumento della versione postgres 16 rispetto alla versione 13 consuma meno spazio ed è molto meglio ottimizzato. Questo può ridurre la quantità totale di memoria del server consumata.
questo è ora il default di Discourse. Non è necessario configurarlo da soli
)