Échec du démarrage en raison du tueur de mémoire insuffisante

Salut à tous,

Je souhaite mettre à jour mon Discourse avec la commande ./launcher rebuild app. Cela fonctionnait parfaitement depuis environ un an. Je procède à cette mise à jour toutes les 2 à 4 semaines si nécessaire.

Je suis sous 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

Aujourd’hui, le processus s’arrête avec l’erreur suivante :

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 ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.

La première erreur avant ce message était :

<--- 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 ne fonctionne plus après cela. Il ne redémarre que si je redémarre le serveur. Mais dans ce cas, je ne peux plus exécuter rebuild app à nouveau. Même erreur.

Pourriez-vous m’aider à résoudre ce problème ?

Cordialement

Votre serveur manque de mémoire pendant le démarrage. Pouvez-vous partager la sortie de free -m ?

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

Hm, je me demande pourquoi je manque de mémoire même après un redémarrage. Je n’ai rien installé de nouveau depuis la dernière mise à jour.

J’ai le même problème. Pas assez de mémoire pour Node.js.
J’ai utilisé “export NODE_OPTIONS=”–max_old_space_size=4096 --some_other_option"", mais cela ne donne aucun résultat.

J’ai également eu la même trace de pile lors de la tentative de reconstruction. L’installation est relativement récente ; je l’utilise uniquement pour le développement et les tests, donc il devrait encore y avoir pas mal d’espace libre, je pense ?

Système d’exploitation : Ubuntu 20.04.1 LTS
Sortie 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 « J'aime »

C’est un peu en dessous du minimum de 1 Go. Vous pouvez essayer d’augmenter un peu la mémoire d’échange, mais je recommande davantage de RAM.

Si vous rencontrez cette erreur, vous avez besoin de plus de RAM (ou peut-être de mémoire d’échange, mais la RAM est préférable).

3 « J'aime »

D’accord, mais pouvez-vous nous expliquer la raison de ce nouveau comportement ? Cela fonctionnait depuis plus d’un an avec cette configuration. Qu’est-ce qui rend Discourse différent aujourd’hui par rapport au passé ?

1 « J'aime »

Merci pour la recommandation. Oui, c’est un peu étrange : j’ai généralement pu me contenter du fichier d’échange par défaut de 2 Go sur un droplet Digital Ocean à 5 $. Je vais surveiller si cela devient plus courant avec les dernières mises à jour ou autre.

Quoi qu’il en soit, j’ai ajouté beaucoup plus d’espace d’échange (4 Go) dans un fichier séparé.

Mais la mise à niveau a quand même échoué. Peut-être que plus de RAM est incontournable. C’est inattendu car l’instance ne compte pour le moment qu’un seul sujet et un seul utilisateur. Je me demande aussi s’il faut faire quelque chose pour s’assurer que Discourse sache utiliser l’espace d’échange, ou s’il est accessible par défaut.

Voici la nouvelle sortie de free -m :

              total        used        free      shared  buff/cache   available
Mem:            981         138         576           0         266         703
Swap:          6143         109        6034
1 « J'aime »

Ouais, j’utilise aussi un Droplet Digital Ocean avec 1 vCPU et 1 Go de RAM virtuelle :slight_smile:

1 « J'aime »

J’ai augmenté la mémoire Swap à 3 Go. Cela ne fonctionne toujours pas avec la même erreur.

1 « J'aime »

Je peux reconstruire mon instance de test avec seulement 2,5 Go de RAM + swap. Cependant, il est possible que votre instance nécessite davantage.

Avez-vous installé des plugins ? Je soupçonne que l’un d’eux provoque une consommation massive de mémoire pendant la compilation.

Pouvez-vous reconstruire sans plugins et vérifier si cela résout le problème ?

Merci d’avoir donné votre avis-

Par curiosité, quelle est la répartition entre RAM et swap ? Et ne comptez-vous que l’espace « libre » sur les deux, ou la taille totale du fichier swap + la RAM totale de l’instance ?

Ah, bien sûr — j’avais oublié de préciser que j’espérais installer le plugin d’authentification Discourse OpenID Connect.

J’ai également déjà installé le plugin Data Explorer.


  • J’ai réessayé avec uniquement Data Explorer + Docker Manager, sans succès ; même trace de pile que précédemment.
  • J’ai réessayé sans aucun plugin (seul Docker Manager), mais la reconstruction n’a toujours pas fonctionné.

Je continuerai à chercher, car en dehors de la tentative d’ajout du plugin ConnectID, je n’ai rien changé depuis l’installation initiale.

Je rencontre un problème qui pourrait être lié à celui-ci sur Trouble with `tests/test_helper`? - #2.

J’ai essayé de reconstruire l’application sans aucun plugin. Aucun changement. La même erreur.

Je ne comprends pas, mais cela ressemble à un bug. J’essaie de faire un bootstrap sur ce site. Aucun plugin non standard. J’ai simplement déplacé des assets d’un bucket à un autre et tout fonctionne. Je faisais une dernière reconstruction pour ajouter DISCOURSE_S3_UPLOAD_BUCKET à l’ENV afin qu’il n’apparaisse pas dans l’UX. Lorsque cela a échoué la première fois, j’ai commenté cette ligne et j’ai réessayé avec la même configuration qui fonctionnait il y a 3 jours.


Compression terminée pour embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js : 0,17 sec

844614.350963717 Compression : 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'"
Tué
rake aborted !
Errno::ENOENT : Aucun fichier ou répertoire @ 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>'
Tâches : TOP => assets:precompile
(Voir la trace complète en exécutant la tâche avec --trace)
I, [2021-04-26T18:38:36.072881 #1]  INFO -- : Mise à jour du curseur de chargement de Discourse...
Téléchargement de MaxMindDB...
Compression du Javascript et génération des cartes de source

Je me demandais s’il y avait un problème avec l’URL du CDN, mais toutes les lignes ci-dessus l’incluaient et fonctionnaient bien.

Cela signifie-t-il qu’il y a du CSS défectueux dans leur thème ? Si oui, aïe. Il n’y a que du CSS dans leur thème principal. Également ces composants : https://github.com/discourse/DiscoTOC.git et https://github.com/davidtaylorhq/discourse-loading-slider.git

Est-ce un droplet de taille minimale ? Il semble que ce fichier soit assez difficile à compresser pour terser, car il provoque une forte pression mémoire.

Oh. C’est étonnamment petit. C’est un site que vous avez, je pense, configuré il y a quelques années (à l’époque où vous hébergiez encore des sites sans utiliser votre propre infrastructure).

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. C’est un droplet DO de 2 Go, et j’ai accès à leur panneau de contrôle. Je vais leur dire qu’il faut passer à 4 Go et les migrer vers un processeur AMD.

MODIF : Mais si l’objectif est juste de compresser ce seul fichier, un droplet de 2 Go ne devrait-il pas suffire ?

Ce fichier d’aide aux tests est très exigeant pour la compression.

  • UglifyJS utilise 1,5 Go de RAM pour le compresser.

  • Terser utilise un peu plus de 1 Go. Cela prend 40 secondes. À titre de comparaison, le même serveur prend 8 secondes sur Ember+jQuery :scream:

@eviltrout Devrions-nous même avoir ce fichier en production ?

Ah, il semble qu’il provienne de cette modification de @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 « J'aime »

Pour ajouter un autre point de données : je rencontre toujours des échecs de reconstruction après avoir supprimé les deux composants de thème. J’utilise donc uniquement le thème Light par défaut.

Aussi, d’où provient cette sortie ? Je cherche à vérifier/déboguer un peu de mon côté également. Est-ce une option verbose sur ./launcher rebuild app ?

Corriger cela correctement va prendre un peu de temps, je vais donc revenir sur ce changement pour l’instant.

9 « J'aime »