La mise à niveau de 3.2.0.beta3-dev vers 3.2.0.beta3 a échoué en raison d'un manque de mémoire

Installation
1

Bonjour,

J’ai essayé de mettre à niveau à la demande de 3.2.0.beta3-dev à 3.2.0.beta3 et cela a cassé mon instance Discourse en raison d’un manque de mémoire lors de la compilation des assets par ember. J’ai essayé ./launcher rebuild app avec le même résultat.

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.

Je fonctionne sur une instance DigitalOcean avec 1 Go pour une organisation à but non lucratif, je ne peux donc pas me permettre de la redimensionner avec plus de mémoire. 1 Go est la taille minimale pour Discourse et les versions précédentes fonctionnaient sans problème. Des idées sur la façon de le faire fonctionner à nouveau ?

2

Avez-vous du Swap ?

Quel est le résultat de

free -h
1 « J'aime »
3 
               total        used        free      shared  buff/cache   available
Mem:           952Mi       321Mi       414Mi       3.1Mi       374Mi       631Mi
Swap:          2.0Gi        75Mi       1.9Gi
4

Vous n’auriez besoin de le redimensionner que lors de la reconstruction.

2 « J'aime »
5

Vous pourriez envisager de passer chez Hetzner qui offre des prix compétitifs et 2 Go de RAM sur son plan de base.

1 « J'aime »
6

Bonjour et bienvenue @andreid :slight_smile:

Mon site de test DO 1 Go a également eu des problèmes de mémoire lors des reconstructions récemment. Je suis temporairement passé à 2 Go juste pour le faire passer.

1 « J'aime »
7

Ne vaudrait-il pas la peine de mettre à jour les exigences minimales dans la documentation à 2 Go de RAM alors ?

2 « J'aime »
9

Je me souviens que c’est arrivé l’année dernière et que quelques ajustements ont été faits JavaScript heap out of memory due to Ember CLI - #4 by JammyDodger. Je ne suis pas sûr si quelque chose peut être fait cette fois-ci aussi, mais je vais demander. :+1:

3 « J'aime »
10

Merci @RGJ et @JammyDodger, le redimensionnement temporaire a fonctionné.

3 « J'aime »
11

Ajouter 1 Go de swap devrait être fonctionnellement identique à ajouter 1 Go de RAM, si vous avez l’espace disque nécessaire. (Il faudra probablement plus de temps pour effectuer la mise à niveau, mais c’est une question de performance, plutôt que de fonction. Ce que vous souhaitez, c’est éviter la situation de manque de mémoire.)

13

J’ai des informations supplémentaires au cas où cela aiderait à atténuer le problème du côté de Discourse. Mon instance (DigitalOcean ~1 Go de gouttelette avec 2 Go d’espace d’échange) a récemment commencé à prendre beaucoup plus de temps à reconstruire et signale la même erreur fatale environ 3 fois sur 4 (la chance semble s’améliorer après avoir exécuté ./launcher cleanup, mais je n’ai pas assez d’échantillons pour confirmer cela).

Peu de temps avant l’erreur de tas manquant de mémoire, ces lignes sont enregistrées :

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.

Je suis hors de mon domaine ici, donc je m’excuse si je me trompe. Des recherches rapides indiquent qu’ember-cli dépend de node.js, c’est pourquoi je pense que c’est pertinent. Le drapeau --max-old-space-size peut potentiellement être défini plus haut que la RAM (il irait simplement dans l’espace d’échange, ce qui, comme mentionné, convient dans ce cas), donc peut-être que 1024 est un plafond artificiel que nous atteignons et que les reconstructions de Discourse ne peuvent plus contenir.

Notes secondaires : apparemment, --optimize-for-size est un drapeau node.js qui aide à réduire l’utilisation de la mémoire (je ne sais pas si Discourse/ember l’utilise, peut-être qu’il l’est déjà), et il y a une anecdote selon laquelle le garbage collector n’est pas activé pour certaines utilisations de node.js, ce qui pourrait être un problème.

Si tout cela est pertinent et contrôlable du côté de Discourse de l’utilisation d’ember/node.js, cela pourrait valoir la peine que quelqu’un s’y penche. Sinon, pas de souci, je vais appliquer la solution temporaire de mise à niveau vers 2 Go proposée ci-dessus. :slight_smile:

1 « J'aime »
14

C’est un très bon point ! Actuellement, nous l’augmentons à 1024 Mo sur les machines à faible quantité de RAM ici. Nous pourrions certainement expérimenter en l’augmentant à 1500 ou 2000 et voir si cela aide.

Si vous avez le temps/l’envie de l’essayer vous-même, vous pourriez le configurer en ajoutant une nouvelle variable à la section env: de votre fichier app.yml :

Modifier : :warning: c’est maintenant la valeur par défaut de Discourse. Pas besoin de configurer vous-même

  NODE_OPTIONS: "--max-old-space-size=2048"
3 « J'aime »
15

Ah, parfait ! Je l’ai essayé.

Comme l’erreur fatale ne se produit pas à chaque fois, et qu’une reconstruction prend environ 25 minutes ces derniers temps (contre 5-10), il faudra peut-être un certain temps avant que je sache si l’augmentation de ce nombre résout le problème de mémoire pour ces spécifications de serveur.

Cependant, je peux déjà confirmer que les deux avertissements Node.js heap_size_limit n’apparaissent plus dans le journal de reconstruction, et ma première reconstruction a été réussie, c’est donc prometteur.

EDIT : J’ai pu reconstruire plusieurs fois sans problème, grâce au paramètre NODE_OPTIONS ci-dessus dans mon app.yml. Youpi !

EDIT2 : Cette solution devrait probablement être intégrée à Discourse en augmentant ce nombre magique (lien du message de David) afin que d’autres machines à faible RAM puissent continuer à fonctionner. Si quelqu’un lit ceci et sait comment faire, ce serait formidable. :slight_smile:

2 « J'aime »
16

Nous avons également rencontré ce problème sur https://caddy.community.

Nous avons exécuté ./launcher rebuild app plusieurs fois et cela a échoué avec divers problèmes.
Tout d’abord, nous avons eu des problèmes avec bundle install se plaignant de rbtrace (se terminant par An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.)

Ensuite, nous avons eu ce problème 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.

Et enfin, en l’exécutant avec ./discourse_doctor, nous avons réussi à passer outre (mais pourquoi ? plus de choses dans le cache lors des exécutions ultérieures, ce qui a réduit l’utilisation de la mémoire ? :thinking:)

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

Mais ce fut une friction que nous n’aurions pas dû rencontrer. J’espère que cela s’améliorera à l’avenir.

Pour information :

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.3Gi        87Mi       138Mi       593Mi       394Mi
Swap:         2.0Gi       337Mi       1.7Gi
1 « J'aime »
17

Absolument, c’est pourquoi nous recueillons des informations ici.

Il semble que la modification de notre variable d’environnement NODE_OPTIONS soit tout ce qui est nécessaire, donc je suppose qu’une dépendance de l’application ou un changement dans V8 a rendu notre valeur précédente inopérante.

@david, qu’en penses-tu ?

1 « J'aime »
18

Ça me semble bien ! Évidemment, les reconstructions de plus de 30 minutes ne sont toujours pas idéales, donc j’espère que nous pourrons améliorer les choses dans un avenir pas trop lointain. Mais cela semble être une bonne solution pour arrêter l’hémorragie.

2 « J'aime »
19

Il convient de noter que l’augmentation de la version 16 de postgres par rapport à la version 13 consomme moins d’espace et est beaucoup mieux optimisée. Cela peut réduire la quantité totale de mémoire serveur consommée.

20

J’ai rencontré un problème de reconstruction similaire aujourd’hui (deux conteneurs) avec une configuration de 2 Go + 2 Go de swap, pour un petit site.

L’extension à 2 Go + 4 Go de swap l’a permis cette fois-ci.

2 « J'aime »
21

2 messages ont été déplacées vers un nouveau sujet : Rebuild affiche « Environment: development » lors de la compilation ember-cli

22

Soit dit en passant, dans mon cas, l’ajout de

à app.yml n’a pas aidé. Ce qui a aidé, c’est simplement


sudo apt update
sudo apt upgrade
2 « J'aime »