Okay, das kann ich verstehen. Wäre es nicht möglich, den Bootstrapping-/Kompilierungsprozess zu optimieren, sodass er länger dauert (CPU/serialisiert), aber innerhalb begrenzter Ressourcen (d. h. RAM)?
1 „Gefällt mir“
Ich denke, das wäre eine großartige Idee. Und ein Grund dafür ist dieser: Wenn man auf einem winzigen Server nicht neu aufbauen kann, dann kann man auch nicht auf einem winzigen Server installieren. Und wenn man auf einem mittelgroßen Server installiert, wird man die Swap-Datei nicht erstellen, die auf dem winzigen Server benötigt wird. (Idealerweise würde das Installationsskript die Swap-Datei trotzdem erstellen und auch die beiden Kernel-Parameter festlegen, die festgelegt werden sollten.)
Das ist auch eine großartige Idee. Auf die gleiche Weise, wie ein Software-Engineering-Prozess idealerweise die Build-Zeiten überwacht, da die Build-Zeiten sonst immer länger werden, würde der Prozess für Discourse idealerweise die Installierbarkeit auf kleinen Instanzen testen und überwachen. Machen Sie es zu einem Ziel.
1 „Gefällt mir“
Ich habe mit der Erstellung von Bootstrapped-Images experimentiert, die Assets beim Start migrieren und vorkompilieren (mit ENV-Einstellungen, um diese Aufgaben zu überspringen). Dies funktioniert größtenteils (nicht so sehr für riesige Websites und für Dinge, die darauf angewiesen sind, dass der Start in einer bestimmten Zeit erfolgt).
Diese sind jedoch auf das Vorhandensein von Redis und Postgres angewiesen.
Mit einer größtenteils standardmäßigen 2-Container-Installation könnte es möglich sein, dies größtenteils zum Laufen zu bringen.
Ooooooooooooooooooooooh, aber das Vorkompilieren von Assets ist wohl der Schritt, der die Probleme verursacht. . .
Ich lese von diesem Ember 5 Upgrade, das gerade im System ist. Welche Auswirkungen hätte das auf die Build-Ressourcen?
Ich denke, die Dokumentation muss aktualisiert werden, discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- Die Standardeinstellung von 1 GB RAM funktioniert gut für kleine Discourse-Communities.
1 GB ist keine Option mehr. Die Mindestanforderung für den Aufbau von Discourse sind 2 GB.
1 „Gefällt mir“
Ich habe eine Reihe von Websites, die ich kürzlich mit 1 GB RAM aufgerüstet habe. Ich habe ihren Swap jedoch auf 3 oder 4 GB erhöht.
Ich empfehle es sicherlich nicht, aber für manche Leute ist es eine riesige Kostenbarriere und sie kommen damit zurecht. Aber vielleicht ist „funktioniert gut“ eine Übertreibung.
3 „Gefällt mir“
Ja, vielleicht sollten Sie das spezifizieren: 1 GB RAM + 4 GB Swap. Es ist mit 2 GB Swap fehlgeschlagen.
Haben Sie Plugins? Viele Themes?
9 Plugins und nur 1 Theme. Wieder hat alles bis 3.1.x auf den 1GB RAM mit 2 GB Swap gut funktioniert (es war ein wenig langsam, vielleicht 20 Minuten zum Neuaufbau, aber es hat immer funktioniert).
Der Versuch, auf 3.2.0 zu aktualisieren, schlug durchgängig fehl (siehe oben).
Ja. Definitiv keine Plugins mit 1 GB RAM. Das scheint etwas zu sein, das man in die Installationsdokumentation aufnehmen sollte.
Ich wäre daran interessiert zu erfahren, ob es ohne die Plugins funktioniert hat.
Als extreme Kurzform kann ich sehen, warum Sie das sagen, aber stimmen Sie nicht zu, dass das Go/No-Go für den Betrieb von Discourse RAM+Swap ist? 1+3 ist aus der Sicht von Go/No-Go genauso gut wie 2+2.
Nur die Leistung (Reaktionsfähigkeit) kümmert sich darum, wie viel RAM Sie haben.
RAM+Swap ist das Richtige, um zu überprüfen und zu testen. Speicher = RAM+Swap.
Übrigens, wenn etwas nicht offensichtlich funktioniert und Sie insbesondere einen Speichermangel vermuten, lohnt es sich, nach dem Out-of-Memory-Killer, auch bekannt als OOM-Killer, zu suchen. Ich empfehle
dmesg|egrep -i "memory|oom|kill"
Bearbeiten: Der Einfachheit halber füge ich dies meiner Liste der Standard-Sofortdiagnosen hinzu:
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
5 „Gefällt mir“
Ich bin auf das gleiche Problem gestoßen, allerdings nicht während eines Upgrades, sondern bei der Neuinstallation der Version 3.2.0.
Ich verwende AWS EC2, genau wie @RBoy.
Ich suche nach einer Lösung, um stattdessen Version 3.1.5 anstelle von 3.2.0 zu installieren, da das alte Forum keine Hilfe bot.
UPDATE:
Entschuldigung, ich habe Folgendes gefunden:
1 „Gefällt mir“
Ich wäre sehr daran interessiert zu erfahren, ob Sie eine Neuinstallation von 3.1.5 mit der in Ihrem Link erwähnten Tag-Methode durchführen konnten. Bitte posten Sie zurück, wenn Sie es ausprobieren.\n\nWas die Installation von 3.2.0 auf einem 1-GB-System betrifft, könnten Sie Folgendes versuchen: Stellen Sie Ihre SWAP-Größe auf 8 GB ein und sehen Sie, ob das funktioniert. Es wird wahrscheinlich KRIECHEN, aber es könnte funktionieren.
Vielen Dank für Ihre durchdachte Anleitung.
Ich habe kürzlich eine Neuinstallation der Docker-Version von Discourse 3.15 abgeschlossen und wollte mitteilen, wie unkompliziert der Prozess war, insbesondere für diejenigen, die wie ich die kostenlose Stufe von AWS EC2 nutzen.
Hier ist eine kurze Anleitung, die auf meiner Erfahrung basiert:
-
Navigieren Sie zu Ihrer Discourse-Konfigurationsdatei unter
/var/discourse/containers/app.yml. -
Aktualisieren Sie im Abschnitt
paramsden Parameterversion, um die gewünschte Discourse-Version anzugeben. Zum Beispiel:params: # ... ## Geben Sie die Git-Revision für diesen Container an (Standard: tests-passed) version: v3.1.5 # Verwenden Sie hier den spezifischen Tag-Namen -
Speichern Sie Ihre Änderungen und beenden Sie den Editor. Führen Sie dann den folgenden Befehl aus, um Ihre Discourse-Anwendung neu zu erstellen:
/var/discourse/launcher rebuild app
Der Prozess hat für mich nahtlos funktioniert und bewiesen, dass die Aufrechterhaltung einer kostengünstigen oder sogar budgetfreien Discourse-Installation durchaus machbar ist.
Ich hoffe, diese Anleitung hilft anderen, die ihre Discourse-Installationen effizient und kostengünstig verwalten möchten.
2 „Gefällt mir“