Bonjour !
J’utilise Discourse sur Docker, et il ne semble jamais utiliser de swap lorsque la RAM est trop sollicitée, ce qui provoque des plantages ou l’affichage du message fatal error: out of memory allocating heap arena map lorsque j’essaie de reconstruire, sauf si je redémarre toutes les quelques heures. Sinon, cela ne semble pas fonctionner.
Quelqu’un sait-il comment résoudre ce problème ?
Merci,
Kian
En supposant que vous soyez sous Linux, que montre la commande free -h ? (De préférence, immédiatement après le redémarrage, et également peu avant l’erreur.)
peut-être que swappiness est défini à 0 ?
cat /proc/sys/vm/swappiness
Salut !
C’était à 40, je l’ai maintenant réglé à 60.
Le système met toujours en cache de gros blocs de RAM, et l’espace d’échange n’est jamais utilisé, même lorsque l’utilisation de la RAM est élevée.
Je pense que les deux éléments de la sortie sur lesquels il faut se concentrer sont les 5,5 Go de mémoire disponible et les 0 Go d’espace d’échange (swap) utilisé. Ou peut-être les 9 Go d’espace d’échange libre. Les 5,5 Go + 9 Go indiquent la marge dont vous disposez. La quantité de mémoire utilisée pour les tampons et le cache est dynamique et ne devrait jamais entraîner de pénurie.
Compte tenu d’un temps avant défaillance de seulement quelques heures, je lancerais une commande vmstat 5 et capturerais la sortie de manière à pouvoir observer les derniers instants. J’utilisais auparavant un travail planifié (cron) pour exécuter vmstat 5 5 dans un fichier journal toutes les 10 minutes.
Il est possible qu’un logiciel défaillant consomme très rapidement toutes les ressources disponibles. Dans ce cas, un journal de la commande ps uax toutes les quelques minutes — afin d’obtenir quelques instantanés aux moments cruciaux — pourrait être très utile.
Il est également possible que d’autres limites soient en jeu. Je suppose qu’il s’agit d’une installation standard sur un système d’exploitation standard, sans autre service en cours d’exécution et sans configuration particulière ?
Bonjour !
Comment puis-je configurer l’exécution de vmstat 5 dans un journal toutes les 10 minutes ? Et comment faire en sorte que ps aux soit également enregistré dans un journal toutes les quelques minutes ?
Oui, il s’agit d’une installation standard d’Ubuntu Server 18.04. Seuls des services comme Apache, Docker, etc. sont installés.
Je viens de me souvenir que j’ai également installé Varnish Cache, ce qui explique la RAM mise en cache. Cependant, je ne vois pas pourquoi Discourse n’utiliserait pas non plus l’espace d’échange (swap). J’ai défini son allocation il y a quelques jours avec une commande Docker pour limiter son swap, mais cela n’a eu aucun effet.
Voici une ligne de commande simple et efficace (cron étant une meilleure solution) :
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
Elle s’exécutera indéfiniment : pour l’arrêter, tapez touch /tmp/stop.
Le journal apparaîtra dans /var/log/monitor.log — utilisez tail -99 pour voir les derniers événements, ou less pour parcourir le fichier. Vous devrez somehow identifier les sections du journal qui montrent l’apparition du problème.
Il semble que vous vous posiez la mauvaise question ici. C’est le noyau Linux qui gère la mémoire virtuelle, y compris l’utilisation des tampons et de la mémoire swap. Si free indique que la mémoire swap est configurée, c’est normal et vous n’avez rien à faire.
Votre vraie question devrait être : pourquoi Discourse ne fonctionne-t-il pas correctement, pourquoi doit-il être redémarré, et pourquoi vois-je cette erreur fatale ?
Je vous recommande vivement de renommer ce sujet en :
« Erreur fatale : out of memory allocating heap arena map »
Mais je m’inquiète aussi du fait que vous semblez avoir plusieurs observations distinctes :
Et il n’est pas clair pour moi comment ces observations interagissent exactement.
Ce serait bien d’avoir des réponses !
Hmm, qu’avez-vous fait exactement ? Que rapporte la commande
docker stats --no-stream --no-trunc
pour MEM USAGE / LIMIT et MEM % ?
(Dans mon cas, la LIMIT est légèrement inférieure à la mémoire physique de la machine. Cela pourrait signifier que rien à l’intérieur du conteneur n’est susceptible de provoquer un swapping, et vous pourriez constater qu’un processus échoue à allouer de la mémoire même lorsqu’il y a peu ou pas de swap utilisé.)
Bonjour !
Je pense que Discourse a planté, car lorsque je me rends sur le domaine, j’obtiens une erreur Nginx 502 Bad Gateway. Le conteneur Docker est cependant toujours en cours d’exécution.
Oui, sauf occasionnellement.
Je l’ai reconstruit, car cela résout souvent le problème du 502 Bad Gateway pendant un certain temps.
J’ai également redémarré le serveur pour voir si cela corrigeait l’erreur. Cela fonctionne parfois, mais il est plus probable que cela ne fonctionne pas. Une reconstruction règle généralement le problème pour un moment.
Je vous enverrai aussi le journal d’erreur bientôt.
Lorsque j’exécute /var/log/monitor.log avec tail -99, je reçois l’erreur : -bash: /var/log/monitor.log : Permission refusée
(D’après votre capture d’écran, je vois que le conteneur nommé « app » a une limite de mémoire de 7,8 Go et n’en utilise que 3 %, ce qui est correct. Édition : mais le fait qu’il utilise 100 % du processeur pourrait être suspect.)
Nous devons simplement examiner la fin de ce fichier journal, donc
tail -199 /var/log/monitor.log
pourrait nous donner ce dont nous avons besoin. Mais il se peut que nous devions en examiner davantage : peut-être pouvez-vous compresser le fichier journal et le joindre, ou le partager d’une autre manière. Quelle est la taille du fichier journal ?
ls -l /var/log/monitor.log
Je pense que 100 % correspond à 1 cœur. Car le système fonctionne bien.
log.txt|pièce jointe (25,0 Ko)
199 lignes du journal.
monitor.txt (39,3 ko)
Voici le journal complet 
Merci. Tout cela semble sain, mais ce n’est qu’un instantané unique. Ce qui devrait se produire, c’est qu’une nouvelle section soit ajoutée au journal toutes les 10 minutes. Attendez de voir le problème avec votre Discourse, puis partagez les dernières sections.
Je dois dire que je ne sais pas ce qui se passe.
Je remarque que vos 3 unicorns utilisent beaucoup de CPU, et je ne sais pas pourquoi ils devraient le faire.
UTILISATEUR PID %CPU %MEM VSZ RSS TTY STAT DÉBUT TEMPS
COMMANDE
x 434 51,9 2,8 443732 234144 ? Sl 18:26 0:11 \\_ maître unicorn -E production -c config/unicorn.conf.rb
x 662 103 3,6 8877408 301148 ? Rl 18:26 0:08 | \\_ discourse sidekiq
x 686 99,7 3,6 8873312 301916 ? Rl 18:26 0:06 | \\_ travailleur unicorn[0] -E production -c config/unicorn.conf.rb
x 731 94,3 3,6 8873312 294368 ? Rl 18:26 0:05 | \\_ travailleur unicorn[1] -E production -c config/unicorn.conf.rb
x 744 77,2 3,3 8873312 276788 ? Rl 18:26 0:03 | \\_ travailleur unicorn[2] -E production -c config/unicorn.conf.rb
Vous pouvez exécuter top et appuyer sur shift+m pour trier par utilisation de la RAM et voir ce qui consomme le plus de mémoire. Pouvez-vous publier le résultat ici ?
