Könnte jemand Anweisungen zur Konfiguration der Speicherallokation geben?
Angesichts der sporadischen Kernel-Meldungen „out of memory"/Dumps, der dreifach erhöhten Swap-Nutzung und der zunehmend verschlechterten Antwortzeiten der Anwendung scheint unsere App gelegentlich den Speicher zu erschöpfen. Unser System verfügt derzeit über 8 GB RAM und 2 GB Swap. Details siehe unten.
Ich habe die Anweisungen zum Hinzufügen von mehr physischem Speicher und Swap unter ("Cannot allocate memory" when upgrading) geprüft, konnte jedoch keine Details dazu finden, wie dieser zugewiesen wird.
Bei den Speicherkonfigurationen verwenden wir derzeit alle Standardeinstellungen. Das System erholt sich nach einigen Minuten, aber bei steigender Nutzung sind wir der Meinung, dass es an der Zeit ist, uns über Leistungsverbesserungen zu informieren. Ich bin mir jedoch unsicher, wo und wie dies konfiguriert werden soll. Soll die für die Docker-Instanz zugewiesene Speichergröße erhöht werden, oder die Anzahl der Ruby-Unicorns (oder beides)?
Ich bin Systemadministrator ohne Ruby- und mit begrenzten Docker-Erfahrungen. Daher wäre es sehr hilfreich, wenn Sie mir den Weg zur Konfigurationsdatei und die entsprechende Syntax aufzeigen könnten.
Hast du discourse-setup nach dem RAM-Upgrade erneut ausgeführt? Es passt die Speichereinstellungen entsprechend an. Du kannst auch die Kommentare in app.yml lesen und sie anpassen.
Hallo Rafael und Team, mein Name ist Serge, und ich arbeite mit Mr. Happy Lee zusammen, der gerade in den lang erwarteten Urlaub aufgebrochen ist. Ich werde mich daher um dieses Problem kümmern.
Als Ergänzung zur Beschreibung: Der Server wurde ursprünglich mit 8 GB RAM und 2 GB Swap-Speicher gebaut. Seitdem wurde er nicht aktualisiert.
In der Systemprotokolldatei sehe ich Hinweise darauf, dass Ruby der Prozess ist, der den gesamten Speicher verbraucht und einen Kernel-OoM (Out-of-Memory) verursacht:
Killed process 2960 (ruby) total-vm:10031472kB, anon-rss:7438148kB, file-rss:0kB
Da ich kein Ruby-Experte bin, bin ich mir nicht sicher, wie ich herausfinden kann, welcher Teil von Ruby so viel Speicher verbraucht.
Wir nutzen zwar das benutzerdefinierte Plugin Scheduled Digest, aber es läuft auch auf unseren beiden anderen Installationen, wo es keine Probleme gibt.
die Entwicklung des Plugins wurde von unserer Organisation bezahlt, daher darf ich den Quellcode hier leider nicht offenlegen. Da das Plugin auf anderen Instanzen jedoch problemlos funktioniert, vermute ich, dass die Server-Ressourcen für diese spezifische Instanz erhöht werden müssen. Die Maschine ist eine VM, sodass ich den Arbeitsspeicher einfach verdoppeln und prüfen kann, ob dies das Problem behebt.
Es gibt nicht viel, was wir tun können, um Code zu debuggen, den wir auf unserer Seite nicht sehen können. Du könntest das Prometheus-Exporter-Plugin für Discourse einrichten, um Metriken auf deiner Instanz zu verfolgen.
Laufen die anderen Instanzen ebenfalls mit Ruby 2.3.1-2~ubuntu16.04.14?
Vielleicht ist das nicht relevant, aber:
Das war also eindeutig ein Ruby-Bug. Wir haben mehrere Ruby-Versionen getestet und festgestellt, dass nur Ruby 2.3.x und 2.4.x den Speicherleck aufweisen (anscheinend wurde dies in Ruby 2.5.0**** behoben).
Hallo Benjamin, die anderen Instanzen laufen ebenfalls mit Ruby 2.3.1-2~ubuntu16.04.14. Ich werde ein Update testen, um zu prüfen, ob es unsere Docker-Umgebung nicht stört.
