Impossible de redémarrer pour le moment, je vous tiendrai informé une fois que j’aurai eu l’occasion de le faire. Cela prendra au moins quelques jours.
Dois-je m’inquiéter ? Ce n’est pas grave si je dois allouer plus de ressources.
Oui, vous devriez vous inquiéter.
Vous avez à peine de marge de manœuvre et il n’y a presque pas de place pour la mise en cache sur disque non plus.
Mais avant d’allouer plus de ressources, vous devriez essayer de découvrir ce qui cause cette utilisation de mémoire tout à fait extraordinaire.
1 « J'aime »
Je ne peux pas faire grand-chose pour le moment, je suis en déplacement. Je reprendrai ce week-end et j’essaierai certainement de comprendre ce qui se passe. Merci pour l’indication 
3 « J'aime »
On dirait que c’était juste un redémarrage en retard qui causait cela. J’ai réussi à redémarrer le serveur et les chiffres sont beaucoup, beaucoup mieux à l’heure actuelle
root@discourse:~# free
total used free shared buff/cache available
Mem: 3927308 977624 2246208 42880 703476 2646836
Swap: 2097148 0 2097148
2 « J'aime »
Il pourrait être utile, si vous vous retrouvez à nouveau dans une situation similaire, de demander à Discourse quels processus utilisent la mémoire - la sortie à
https://example.com/admin/upgrade#/processes
est triée par utilisation de la RAM. Cela n’affichera, je pense, que les processus s’exécutant dans le conteneur. À la ligne de commande, vous pourriez utiliser
ps aux | sort -nr -k 4 | head -22
ou similaire, pour voir l’utilisation de tous les processus, y compris ceux de tous les conteneurs.
Si un redémarrage résout un problème de manque de mémoire, il y a de fortes chances que vous ayez une sorte de processus incontrôlable quelque part qui va monter en charge (peut-être lentement) jusqu’à causer des problèmes.
Edit : Hmm, je vois que je mentionne la lecture des processus selon l’utilisation de la RAM (RSS). Cela peut être utile, mais dans ce cas, nous nous intéressons davantage à l’utilisation de la mémoire virtuelle : nous devrions trier par la colonne VSZ, colonne 5, pour cela.
2 « J'aime »
Cette instance Discourse a été configurée pour la première fois il y a de nombreuses années, donc peut-être avant que la vérification du fichier swap ne soit effectuée. J’ai appliqué manuellement ces lignes de code et le fichier swap est maintenant créé. Merci.
Pour que Docker utilise le fichier swap, dois-je appliquer ceci ? Ou plutôt, à quoi sert cette recommandation ?
J’ai trouvé ceci qui discute de ce qu’est vm.overcommit_memory, mais je ne comprends pas pourquoi un tel changement serait nécessaire :
Cela a à voir avec l’exécution de Redis, pas avec la mise à niveau de Discourse.
Je pense que c’est plus que cela - laissez-moi essayer d’expliquer. La recommandation vient de Redis, et Redis la recommande car la création d’un processus fils (forking) demande beaucoup de mémoire virtuelle, et Redis crée des processus fils pour effectuer des sauvegardes en arrière-plan, et pourtant la mémoire virtuelle réclamée ne sera jamais nécessaire.
C’est typique pour de nombreuses applications Unix : elles créeront des processus fils, mais n’auront pas besoin de doubler leur utilisation de mémoire. Parce que c’est typique pour beaucoup, et parce qu’il s’agit d’un paramètre du noyau qui modifie le comportement de tous les processus dans tous les conteneurs, cela peut transformer un échec en succès lorsque la mémoire virtuelle est sous pression.
Sur les petites instances bon marché que beaucoup d’entre nous utilisent, la mémoire virtuelle est souvent sous pression. Et encore plus lors des mises à niveau ou des reconstructions.
Donc, modifier ce paramètre pourrait bien être lié à la réussite ou à l’échec d’une mise à niveau, surtout s’il y a eu récemment un changement qui augmente la demande de mémoire virtuelle.
Tel quel, le noyau rejettera les allocations qu’il ne peut pas satisfaire. Avec ce réglage, il acceptera ces allocations, et l’échec pourrait être évité, ou il pourrait se produire plus tard lorsque l’allocation deviendra une utilisation.
Si votre total de RAM et de swap est suffisamment important, vous n’aurez jamais besoin de modifier ce paramètre. Si votre total n’est pas important, le modifier pourrait aider.
2 « J'aime »
La commande free vous indiquera la quantité de swap configurée et la quantité utilisée. Je pense que vous constaterez qu’elle est utilisée dès que vous aurez exécuté ces commandes.
Il s’agit d’augmenter la quantité de mémoire virtuelle disponible (c’est-à-dire la somme de la RAM et du swap). Si vous manquez de RAM, vous commencez à avoir des problèmes de performance. Mais si vous manquez de mémoire virtuelle, les processus ne parviennent pas à démarrer, meurent ou sont tués. C’est brutal.
Ceux d’entre nous qui ont peu de RAM et peu de disque ne sont peut-être pas libres d’ajouter beaucoup de swap, mais 2G semble être un bon minimum. (Si vous aviez 16 Go de RAM, vous n’auriez peut-être pas besoin de swap, mais c’est une autre histoire. C’est la somme des deux qui compte, lorsque le problème est que les choses échouent.)
2 « J'aime »
Aha. Je pense que j’ai à peu près compris, mais c’est une très bonne explication. C’est donc pour cela que je l’ai configuré sur chaque installation que j’ai faite VM que j’ai créée pour les clients.
Je me demande si nous devrions faire en sorte que discourse-setup modifie ces paramètres lorsqu’il crée le swap.
1 « J'aime »
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.