Es scheint, dass 2+2 nicht mehr ausreichen könnten… Ich verwalte eine ziemlich unscheinbare Discourse-Instanz (keine großen/schicken Plugins usw.), die heute fehlschlägt, weil Ember den gesamten verfügbaren RAM und den gesamten Swap-Speicher verbraucht und die Maschine unproduktiv macht. Das Hinzufügen weiterer 2 GB Swap ermöglichte den Abschluss des Bootstrap-Vorgangs mit einer maximalen Swap-Nutzung von etwa 2,5 GB.
Puh, das steht auf @david’s Liste zur Untersuchung.
5 „Gefällt mir“
@david hat ermittelt, wir bestätigen, dass 2 GB für Docker-Rebuilds ausreichen, aber nicht genug für den Web-Upgrader.
Eine Idee, die ich in den Raum geworfen habe, ist, alle Ruby-Prozesse während des Web-Upgraders herunterzufahren, um zusätzliche 300-500 MB zu sparen, was genug für die Asset-Kompilierung übrig lassen würde.
Ein langfristiger Ansatz, den wir wahrscheinlich für Self-Hosters verfolgen werden müssen, ist das Ausliefern von bootstrappten Containern, was eine Büchse der Pandora ist, denn wie soll ein Web-Upgrader das schaffen? Wir wollen keine Docker-Sockets einbinden …
Es ist wirklich eine knifflige Angelegenheit.
2 „Gefällt mir“
Nun, für mich war es das nicht.
Wird dies zwischen einer einfachen reinen Installation und realen Situationen verglichen?
In der Tat ist es nicht perfekt konsistent. Selbst wenn alles andere heruntergefahren ist, kann es immer noch fehlschlagen.
Leider führen wir hier einen aussichtslosen Kampf gegen moderne JS-Build-Tools. Sie sind alle darauf ausgelegt, auf modernen Entwicklermaschinen mit 8 GB+ RAM zu laufen, nicht auf 1-GB-VPSs 
Wir haben einige Lösungen im Sinn. Zum Beispiel: Bereitstellung von vorkompilierten Assets, die automatisch heruntergeladen werden können. Die große Herausforderung sind Plugins, da sie auf jeder Website variieren und derzeit eng in den Kern-Build integriert sind.
Aber vorerst sollte ein vollständiger CLI-Neubau eine höhere Erfolgsquote haben als ein Web-UI-Update.
8 „Gefällt mir“
Wie Jagster, 2 GB RAM + 2 GB Swap sind für meinen CLI-gesteuerten Docker-Rebuild nicht ausreichend. Bei genauerer Betrachtung sind die einzigen Plugins bei dieser Installation docker_manager und discourse-prometheus – keines von beiden würde, wie erwartet, unerwartete Last auf Ember legen.
Wenn die Mindestspezifikationen geändert werden müssen, wäre das schlecht, aber es wäre viel besser als die aktuelle Situation, in der Maschinen bei jedem Upgrade unerwartet abstürzen.
7 „Gefällt mir“
Wenn das der Fall ist, denke ich, wäre es trotzdem besser, die empfohlenen Spezifikationen etwas zu erhöhen. Persönlich stört es mich nicht wirklich, 2 (oder sogar 4) GB mehr Swap hinzuzufügen, wenn dies die Wiederherstellungen zuverlässiger macht – zumindest solange der tägliche Betrieb mit 2-4 GB RAM (für kleine bis mittelgroße Communities) weiterhin reibungslos funktioniert.
2 „Gefällt mir“
Tatsächlich schlug die anfängliche Installation in meiner letzten Installation auf einer 4c 4g-Instanz fehl. Ed schlug vor, eine Swap-Datei zu erstellen. Ich fand das Thema zur Erstellung eines Swaps und erstellte einen 4g-Swap. Jetzt funktioniert alles wie erwartet bei Web- oder CLI-Updates/Upgrades.
Meiner Meinung nach müssen wir vielleicht einfach akzeptieren, dass Discourse mehr RAM benötigt als früher.
3 „Gefällt mir“
Wäre zram nicht sinnvoll?
Wir haben gerade diesen Commit eingespielt, der die Situation hoffentlich verbessern wird. Bitte teile uns mit, wie es bei dir läuft! (Er wird die Tests in den nächsten ~30 Minuten bestehen)
Beim Testen mit einem speicherbeschränkten Docker-Container lokal kann ich jetzt einen erfolgreichen Build mit -m 1600m erreichen. Vor dieser Änderung war das Minimum, das ich erreichen konnte, -m 3000m.
12 „Gefällt mir“
Ich habe einen Test-Neubau (Neuinstallation) durchgeführt, der ohne Probleme durchlief. Jetzt hat diese Maschine 4 GiB RAM (Hetzner CAX11) und eine Swap-Datei von gleicher Größe, sodass sie sicherlich weniger eingeschränkt ist als das oben erwähnte 2+2 GB-Setup. Die Swap-Nutzung war jedoch während des gesamten Builds minimal und die maximale RAM-Nutzung, die ich sah, betrug ~3,1 GB. Die meiste Zeit blieb sie bei ~2 GB, sodass es nicht schlecht aussieht (die Build-Zeit änderte sich mehr oder weniger nicht, d.h. etwa 8 Minuten).
4 „Gefällt mir“
Ich würde gerne einige kontrollierte Experimente mit sauberen Installationen und Neuerstellungen auf verschiedenen Systemen durchführen und insbesondere den Unterschied (falls vorhanden) beim Ausführen mit VM-Overcommit sehen, aber ich hatte leider keine Zeit.\n\n(Ohne Overcommit hat ein großer Prozess, der sich verzweigt, eine augenblickliche Zunahme des Speicher-Footprints, die tödlich sein kann und die auf einem abgefragten Monitor nicht angezeigt wird. Selbst mit Overcommit kann die Speichererhöhung schnell genug sein, um nicht auf einer Abfrage angezeigt zu werden, sei es htop, vmstat oder etwas anderes.)\n\nIch glaube nicht, dass ich jemals jemanden gesehen habe, der freiwillig angibt, ob er mit Overcommit arbeitet oder nicht, obwohl dies meiner Meinung nach ein wichtiger Aspekt der Host-Konfiguration ist.
1 „Gefällt mir“
Ich wette, die meisten Leute tun das nicht.
Ich habe es bei meinen Installationen automatisch eingestellt. Ich bekomme trotzdem diese Warnung.
Overcommit ist hier irrelevant, da das Problem nicht darin besteht, dass Prozesse vorzeitig OOM-killed werden, sondern darin, dass versucht wird, zehn Pfund zugewiesenen Speichers in einen Fünf-Pfund-Sack zu stopfen.
Es ist praktisch nicht möglich, einen Discourse-Rebuild mit overcommit_memory=2 durchzuführen, da Ember (neben anderen Dingen, zweifellos) riesige Mengen an virtuellem Speicher vorab zuweist (soweit ich mich erinnere, habe ich etwa 80 GB gesehen), sodass dies immer gegen jede vernünftige overcommit_ratio-Einstellung verstoßen wird. Das Setzen von overcommit_memory=1 wird ebenfalls nicht helfen, da das Problem wiederum nicht ein übereifriger VMM ist, der Prozesse beendet, sondern ein entsetzlich schlechtes Speichermanagement des Ember-Compilers.
1 „Gefällt mir“
Ich bin mir nicht sicher, ob ich Ihrer Analyse vollständig zustimme! Soweit ich weiß, ermöglicht Overcommit Prozessen, Speicher zuzuweisen, den sie nicht berühren. Es geht nicht nur um das Verhalten des OOM-Killers. Aber wie gesagt, ich möchte einige kontrollierte Experimente durchführen, das ist ein besserer Weg, um zu sehen, was einen Unterschied macht und was nicht.
Ich habe 4 GB RAM und viele Plugins (keine Swap-Datei, soweit ich weiß). Wie viele Plugins hast du und glaubst du, dass reine 4 GB RAM ausreichen?
Teilweise richtig, aber trotzdem irrelevant, da das Problem, das in diesem Thema diskutiert wird, Prozesse sind, die Speicher zuweisen, den sie berühren, und zwar mehr, als das System verfügbar hat, was zu kundenrelevanten Ausfällen führt.
Können Sie bestätigen, dass sich die Speicheranforderungen nach den Änderungen von @david reduziert haben? Wir sollten jetzt in einem vernünftigen Zustand sein.
Der nächste große Sprung wird die Vorabkompilierung und die verteilte Vorabkompilierung von Assets sein. Es ist eine ziemlich große Änderung, um dorthin zu gelangen, aber sie wird eine große Menge Arbeit aus dem Internet löschen, sobald sie erledigt ist.
2 „Gefällt mir“
Mit Verlaub, da bin ich mir nicht sicher. Ich habe Logdateien gesehen, die Fehler beim Forking zeigen. Wir sagen in diesem Thread, dass es sich um „Speicheranforderungen“ handelt, aber das beinhaltet meiner Meinung nach auch die Taktiken des Kernels für virtuellen Speicher. Offensichtlich wird ein oder drei Experimente zeigen, ob ich mit meiner Meinung über Overcommit richtig liege oder nicht.
Das war ein frischer Build ohne Plugins. Ich kann einen weiteren versuchen, bei dem einige Plugins aktiviert sind, und vielleicht vorübergehend Swap deaktivieren, um zu bestätigen, dass der Build durchgeht (es wird vermutlich ein paar Tage dauern, bis ich Zeit habe, allerdings).
2 „Gefällt mir“