Consommation excessive de mémoire due à la précompilation des assets

Bonjour @david,

L’utilisation de la mémoire diminue-t-elle dès que la tâche assets:build est terminée ?

Non. J’ai creusé davantage et il y a quelque chose d’étrange.

Avant le précompilation de build, voici la liste des plugins :

/var/www/discourse$ ls plugins/
automation           discourse-akismet           discourse-data-explorer  discourse-hcaptcha           discourse-microsoft-auth  discourse-post-voting  discourse-saved-searches       discourse-user-notes           styleguide
chat                 discourse-apple-auth        discourse-details        discourse-lazy-videos        discourse-narrative-bot   discourse-presence     discourse-solved               discourse-zendesk-plugin
checklist            discourse-assign            discourse-docs           discourse-local-dates        discourse-oauth2-basic    discourse-prometheus   discourse-subscriptions        footnote
discourse-adplugin   discourse-cakeday           discourse-gamification   discourse-login-with-amazon  discourse-openid-connect  discourse-reactions    discourse-templates            msgraph-poll-discourse-plugin
discourse-affiliate  discourse-calendar          discourse-github         discourse-lti                discourse-patreon         discourse-rewind       discourse-topic-trade-buttons  poll
discourse-ai         discourse-chat-integration  discourse-graphviz       discourse-math               discourse-policy          discourse-rss-polling  discourse-topic-voting         spoiler-alert

J’ai remarqué le comportement suivant après avoir débogué le code.

/var/www/discourse$ script/rails runner "AssetProcessor.ember_version"
Le nom du plugin est 'msgraph-polling', mais le répertoire du plugin est nommé 'msgraph-poll-discourse-plugin'

# se bloque ici indéfiniment

AssetProcessor.ember_version correspond à la ligne discourse/lib/plugin/js_manager.rb at latest · discourse/discourse · GitHub

J’ai donc apporté quelques modifications à ce fichier (ci-joint), essentiellement pour afficher où le processus se bloque lors du traitement, et pour supprimer l’appel à AssetProcessor.ember_version à la ligne discourse/lib/plugin/js_manager.rb at latest · discourse/discourse · GitHub, en remplaçant simplement par 5 afin de poursuivre la génération hexadécimale.

Ensuite, j’ai réduit le parallélisme à 1 pour simplifier les choses à la ligne discourse/lib/plugin/js_manager.rb at latest · discourse/discourse · GitHub (parallel_count = [Etc.nprocessors, 1].min).

Après cela, j’ai exécuté bundle exec rake assets:precompile:build, ce qui a donné le résultat suivant :

/var/www/discourse$ bundle exec rake assets:precompile:build
Le nom du plugin est 'msgraph-polling', mais le répertoire du plugin est nommé 'msgraph-poll-discourse-plugin'
[assemble_ember_build] Réutilisation de la build Ember principale existante. Tout est terminé.
Le nom du plugin est 'msgraph-polling', mais le répertoire du plugin est nommé 'msgraph-poll-discourse-plugin'
[Plugin::JsManager] Compilation de 49 plugins...
Compilation de automation...
fin du tri des fichiers
fin du tri des fichiers
        hex_digest 103dc9ebebb80a7065cb8dd41fb3356b30f151f7
########### récursif

# se bloque ici indéfiniment, consommant toute la mémoire

Je soupçonne que cela puisse être lié à la valeur de ulimit (que nous avons définie sur unlimited au lieu de quelque chose comme ulimit -n 1048576;), étant donné que vous ouvrez un grand nombre de fichiers et stockez leur contenu en mémoire (via les appels récursifs).

Faites-moi savoir si cela vous dit quelque chose, ou si vous avez d’autres pistes sur ce qui pourrait causer le problème.

Cordialement,

Ismael

js_manager.rb.txt (7,7 KB)