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. 