Quelqu’un pourrait-il fournir des instructions pour configurer l’allocation de mémoire ?
Étant donné les messages sporadiques du noyau « out of memory » / dump, le triplement des échanges (swap) et la dégradation croissante de la réponse des applications, il semble que notre application manque parfois de mémoire. Notre système dispose actuellement de 8 Go de mémoire et de 2 Go d’espace d’échange. Détails ci-dessous.
J’ai examiné les instructions pour ajouter plus de mémoire physique et d’espace d’échange à l’adresse ("Cannot allocate memory" when upgrading), mais je n’ai pas pu trouver de détails sur la façon de l’allouer.
En ce qui concerne les configurations de mémoire, nous utilisons tous les paramètres par défaut. Le système se rétablit après quelques minutes, mais avec une utilisation accrue, nous pensons qu’il est temps de nous informer sur la façon d’améliorer les performances. Je ne suis cependant pas sûr de l’endroit et de la manière de configurer cela. Augmenter la mémoire allouée à l’instance Docker, ou le nombre de processus Ruby Unicorn (ou les deux) ?
Je suis administrateur système sans expérience Ruby et avec une expérience limitée de Docker, donc me diriger vers le fichier de configuration et la syntaxe à utiliser m’aiderait grandement.
Avez-vous relancé discourse-setup après avoir augmenté votre RAM ? Cela ajustera automatiquement les paramètres de mémoire. Vous pouvez également consulter les commentaires dans app.yml et les modifier si nécessaire.
Bonjour Rafael et l’équipe, je m’appelle Serge et je travaille avec M. Happy Lee, qui vient de partir pour ses vacances tant attendues. Je vais donc prendre en charge ce problème.
Pour compléter la description : le serveur a été initialement configuré avec 8 Go de RAM et 2 Go d’espace d’échange (swap). Nous ne l’avons pas mis à niveau depuis.
Dans le journal système, je constate des preuves que Ruby est le processus qui consomme toute la mémoire, provoquant ainsi un OoM (Out of Memory) du noyau :
Killed process 2960 (ruby) total-vm:10031472kB, anon-rss:7438148kB, file-rss:0kB
Je ne suis pas expert en Ruby, aussi je ne sais pas comment identifier quel processus Ruby consomme autant de mémoire.
Nous utilisons bien le plugin personnalisé Scheduled Digest, mais il fonctionne également sur nos deux autres installations, qui ne rencontrent aucun problème.
Notre organisation a financé le développement de ce plugin, je ne suis donc malheureusement pas autorisé à rendre le code source accessible ici. De plus, comme le plugin fonctionne sans problème sur d’autres instances, cela me fait penser à augmenter les ressources mémoire du serveur pour celui-ci. La machine est une VM, je peux donc facilement doubler la quantité de mémoire et voir si cela résout le problème.
Il n’y a pas grand-chose que nous puissions faire pour déboguer du code que nous ne pouvons pas voir de notre côté. Vous pourriez envisager d’installer le plugin d’export Prometheus pour Discourse afin de suivre les métriques de votre instance.
Les autres instances exécutent-elles également Ruby 2.3.1-2~ubuntu16.04.14 ?
Peut-être sans rapport, mais :
il s'agissait donc clairement d'un bug de Ruby. Nous avons testé sur plusieurs versions de Ruby et déterminé que seules les versions 2.3.x et 2.4.x présentaient la fuite (apparemment, cela a été corrigé dans Ruby 2.5.0****).
Et le fichier README de Discourse demande [Ruby 2.6+]
Salut Benjamin, les autres instances exécutent également Ruby 2.3.1-2~ubuntu16.04.14. Je vais tester une mise à jour pour voir si cela ne casse pas notre configuration Docker.
