Discourse verbraucht nicht viel RAM

Hallo!
Ich habe Discourse in Docker laufen, und es scheint bei zu hohem RAM-Verbrauch niemals Swap zu nutzen. Das führt dazu, dass die Anwendung abstürzt oder die Meldung fatal error: out of memory allocating heap arena map ausgegeben wird, wenn ich einen Neuaufbau versuche. Es scheint nicht zu funktionieren, es sei denn, ich starte alle paar Stunden neu.

Weiß jemand, wie man das beheben kann?

Danke,
Kian

Angenommen, Sie arbeiten unter Linux: Was zeigt free -h an? (Vorzugsweise unmittelbar nach dem Neustart und kurz vor dem Fehler.)

2 „Gefällt mir“

Vielleicht ist Swappiness auf 0 gesetzt?
cat /proc/sys/vm/swappiness

2 „Gefällt mir“

Hallo!
Es lag bei 40, ich habe es jetzt auf 60 gesetzt.

Screenshot_440

Das System zwischenspeichert immer große RAM-Abschnitte, und Swap wird selbst bei hoher RAM-Auslastung nie verwendet.

Ich denke, die beiden Teile der Ausgabe, auf die man sich konzentrieren sollte, sind die 5,5 GB verfügbaren Speichers und die 0 GB genutzten Swap-Speichers. Oder vielleicht die 9 GB freien Swap-Speichers. 5,5 GB + 9 GB zeigen Ihnen, wie viel Spielraum Sie haben. Die Menge des für Puffer und Cache verwendeten Speichers ist dynamisch und sollte niemals zu einem Mangel führen.

Bei einer Ausfallzeit von nur wenigen Stunden würde ich vmstat 5 ausführen und die Ausgabe so erfassen, dass Sie die letzten Momente sehen können. Früher habe ich einen Cron-Job verwendet, der alle 10 Minuten vmstat 5 5 in eine Protokolldatei geschrieben hat.

Es ist möglich, dass fehlerhafte Software sehr schnell alle verfügbaren Ressourcen verbraucht. In diesem Fall könnte ein Protokoll von ps uax alle paar Minuten – um einige Momentaufnahmen in den entscheidenden Momenten zu erhalten – sehr nützlich sein.

Es ist auch möglich, dass andere Grenzen greifen. Geht man davon aus, dass dies eine Standardinstallation auf einem Standard-Betriebssystem ist, bei der nichts anderes läuft und keine spezielle Konfiguration vorliegt?

2 „Gefällt mir“

Hallo!
Wie kann ich vmstat 5 alle 10 Minuten in ein Log schreiben? Und wie kann ich ps uax alle paar Minuten in ein Log schreiben?

Ja, es ist eine reine Installation von Ubuntu Server 18.04. Es sind nur Dinge wie Apache, Docker usw. installiert.

Ich habe gerade auch daran gedacht, dass ich Varnish Cache installiert habe, was den zwischengespeicherten RAM erklärt. Aber ich verstehe nicht, warum Discourse keinen Swap verwenden sollte. Ich habe vor einigen Tagen mit einem Docker-Befehl die Swap-Grenze festgelegt, aber das hat nichts bewirkt.

Hier ist eine One-Liner-Lösung, die einfach und effektiv ist (cron wäre zwar der bessere Weg):

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' &

Sie läuft unendlich weiter: Um sie zu stoppen, führe touch /tmp/stop aus.
Das Log erscheint in /var/log/monitor.log. Verwende tail -99, um die letzten Einträge zu sehen, oder less, um es Seite für Seite zu durchblättern. Irgendwie musst du die Abschnitte im Log finden, die zeigen, wie sich das Problem entwickelt.

Es hat den Anschein, als würdest du dir hier die falsche Frage stellen. Es ist der Linux-Kernel, der für das virtuelle Speichermanagement zuständig ist, einschließlich der Nutzung von Puffern und Swap. Wenn free meldet, dass Swap konfiguriert ist, ist das völlig normal, und du musst nichts unternehmen.

Deine eigentliche Frage sollte lauten: Warum läuft mein Discourse nicht gut, warum muss es neu gestartet werden und warum sehe ich den fatal error?

Ich würde dir sehr empfehlen, dieses Thema umzubenennen in:
Warum „fatal error: out of memory allocating heap arena map“?

Aber ich mache mir auch Sorgen, dass du mehrere unterschiedliche Beobachtungen zu haben scheinst:

  • Manchmal stürzt Discourse ab.
  • Manchmal sehe ich „fatal error: … heap arena map“ beim Neuaufbau (Rebuild).
  • Manchmal muss ich alle paar Stunden neu starten.

Mir ist nicht ganz klar, wie diese Beobachtungen zusammenhängen.

  • Was lässt dich glauben, dass Discourse abgestürzt ist? Was ist die konkrete Beobachtung?
  • Siehst du „fatal error:“ immer beim Neuaufbau?
  • Warum führst du einen Neuaufbau durch?
  • Was veranlasst dich zum Neustart, und meinst du damit den Neustart des Servers?

Es wäre gut, die Antworten darauf zu hören!

1 „Gefällt mir“

Hmm, was hast du genau gemacht? Was zeigt

docker stats --no-stream --no-trunc

für MEM USAGE / LIMIT und MEM % an?

(In meinem Fall liegt das LIMIT etwas unter dem physischen Arbeitsspeicher der Maschine. Vielleicht bedeutet das, dass nichts innerhalb des Containers ausgelagert wird, und ein Prozess könnte dennoch scheitern, wenn er Speicher anfordern möchte, auch wenn kaum oder kein Swap genutzt wird.)

Hallo!
Ich vermute, dass Discourse abgestürzt ist, da ich beim Aufruf der Domain eine Nginx 502 Bad Gateway-Fehlermeldung erhalte. Der Docker-Container läuft jedoch noch.

Ja, außer in seltenen Fällen.

Ich habe ihn neu erstellt, da dies das 502 Bad Gateway-Problem oft eine Weile behoben hat.

Ich habe den Server auch neu gestartet, um zu sehen, ob das den Fehler behebt. Das funktioniert oft, aber höchstwahrscheinlich nicht. Ein Neuaufbau behebt das Problem meist für eine gewisse Zeit.

Ich werde auch bald das Fehlerprotokoll erhalten.

Wenn ich /var/log/monitor.log mit tail -99 ausführe, erhalte ich die Meldung: -bash: /var/log/monitor.log: Zugriff verweigert

(In Ihrem Screenshot sehe ich, dass der Container mit dem Namen „app

Ich denke, 100 % entsprechen einem Kern, da das System einwandfrei läuft.

log.txt|Anhang (25,0 KB)
199 Zeilen des Protokolls.

monitor.txt|Anhang (39,3 KB)
Hier ist das vollständige Protokoll :slight_smile:

Danke. Das sieht alles gesund aus, aber es ist nur ein einzelner Schnappschuss. Eigentlich sollte alle 10 Minuten ein weiterer Abschnitt an das Protokoll angehängt werden. Warte, bis du das Problem mit deinem Discourse festgestellt hast, und teile dann die letzten paar Abschnitte.

Ich muss sagen, ich weiß nicht, was los ist.

Mir ist aufgefallen, dass deine drei Unicorns viel CPU verbrauchen, und ich weiß nicht, warum das so sein sollte.

USER       PID %CPU %MEM     VSZ    RSS TTY  STAT START  TIME 
 COMMAND
x          434 51.9  2.8  443732 234144 ?    Sl   18:26  0:11  \_ unicorn master -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  |   \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x          731 94.3  3.6 8873312 294368 ?    Rl   18:26  0:05  |   \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x          744 77.2  3.3 8873312 276788 ?    Rl   18:26  0:03  |   \_ unicorn worker[2] -E production -c config/unicorn.conf.rb

Sie können top ausführen und shift+m drücken, um nach RAM-Verbrauch zu sortieren und zu sehen, was den meisten RAM verbraucht. Können Sie das Ergebnis hier posten?