Ich weiß das zu schätzen, aber das Neubauen der App dauert etwa 3 Stunden!
Und das auf einem riesigen VPS.
Wäre es nicht cool, Plugins genauso entfernen zu können, wie wir Themes hinzufügen und entfernen können?
Vielleicht etwas, das man für zukünftige Funktionen in Betracht ziehen kann?
Danke!!
Entschuldigung?! Das sollte ~20 Minuten dauern?!
nicht hier
Die ursprüngliche Installation dauerte 2 Stunden.
Jetzt ist der ./launcher rebuild app so weit fortgeschritten:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
Und nach der letzten Zeile blinkt es nur noch (der Prozess läuft noch).
Das ist jetzt ungefähr seit 30 Minuten so.
Das letzte Mal, als ich das gemacht habe, hat es volle 160 Minuten gedauert.
Server Total Memory: 4.657GiB, Kernel Version: 5.15.0-43-generic, Operating System: Ubuntu 22.04 LTS, 50GB SSD drive, 2.5 Cores, 5 Threads Intel® Xeon® CPUs
…
Ich bin mir nicht sicher, was daran falsch sein könnte, außer dass es sehr lange dauert 
3 Stunden klingen in der Tat sehr falsch. Sie müssen dieses Problem untersuchen und es als erste Priorität lösen.
Es gibt ‘visuelle Pausen’ im Build-Logging, das ist normal, aber diese Verzögerung nicht.
Ich vermute, dass Sie während des Builds irgendwie anfangen, Swap zu verwenden, aber ich bin kein SA. Führen Sie noch etwas anderes auf dieser Maschine aus?
Downloads erfordern das Entpacken, und das ist rechenintensiv, aber es sind dieselben Images für alle.
Zur Referenz, ich habe gerade jetzt eine Website neu erstellt, und es dauerte 13 Minuten und 46 Sekunden auf einer 2 GB 2 vCPU-Maschine auf https://scaleway.com.
Nein, dies ist ein VPS, der ausschließlich für diese Discourse-Instanz bestimmt ist. Und ich betreibe viele andere VPS bei demselben Unternehmen, die alle reibungslos laufen (aber es sind keine Discourse-Instanzen, es sind andere Apps wie benutzerdefinierte PHP- oder WP/CP-CMS-Instanzen usw.).
Ich bin mir keiner Swap-Nutzung bewusst und kann auch keine Spitzen bei der Ressourcennutzung erkennen, die dies auch nur rechtfertigen würden.
Jetzt steht es auf building.... - es scheint etwas schneller zu sein als letztes Mal, aber es dauert immer noch deutlich über 20 Minuten.
Ich werde die Serveranbieter fragen, ob sie auf ihrer Seite etwas Ungewöhnliches feststellen können. Ich erinnere mich jedoch, dass sie mir persönlich gesagt haben, dass ihre eigene Discourse-Instanz ebenfalls etwa 2 Stunden zum Erstellen benötigte. (PS Diese VPS befinden sich auf Hetzner-Maschinen, die über einen Drittanbieter gemietet wurden. Ich bezweifle, dass ich etwas Besseres bekommen kann.)
Auf jeden Fall bleibt mein Vorschlag bestehen, dass es fantastisch wäre, Plugins hinzufügen und entfernen zu können, so wie wir Themes hinzufügen und entfernen können. Vielleicht ist das etwas, das man in Betracht ziehen sollte?
Ich weiß wirklich nichts, aber meines Wissens ist das nicht möglich, da Discourse viele kompilierte JavaScripts sind. Wenn etwas hinzugefügt oder entfernt werden muss, das die Funktionsweise des Kerns verändert, muss es neu aufgebaut werden.
Sehr ähnliche Situation wie bei Varnish zum Beispiel.
Ok…
Übrigens habe ich mich mit den Server-Leuten in Verbindung gesetzt und tatsächlich haben wir 100 % Speicher erreicht.
5 GB ??? 5 GB RAM sind für alles wirklich ein bisschen viel.
Die Discourse-Anforderungen besagen, dass 1 GB RAM benötigt wird!
Und es hängt jetzt an Folgendem:
104:M 04 Okt 2022 07:19:27.251 # Redis ist jetzt bereit zum Beenden, auf Wiedersehen...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Entferne alten Container
+ /usr/bin/docker rm app
app
Daher kann ich den Server nicht einmal aufrüsten, da der Prozess unterbrochen würde.
Wirklich, ich glaube nicht, dass dies überhaupt ein Serverproblem ist. Wenn wir 1 GB brauchen, sollten 5 GB mehr als genug sein.
Hier stimmt etwas ganz und gar nicht.
Ich verstehe, dass andere eine bessere Erfahrung haben müssen (ich schaue @merefield an, der sagte, er habe auf 2 GB aufgerüstet…), aber es funktioniert für uns nicht so, wie es sollte.
Wie auch immer, das ist wahrscheinlich ein Off-Topic für diesen Thread.
Ich habe gerade eine weitere Website neu erstellt, 4 GB, 3 vCPU, wieder weniger als 15 Minuten (d. h. der zusätzliche Arbeitsspeicher/die zusätzliche CPU hat in meinem Fall nicht viel geholfen, aber immer noch weit von Stunden entfernt!).
Das einzige, das mir gerade aufgefallen ist, ist, dass mein VPS vfs anstelle des vorgeschlagenen aufs oder overlay verwendet.
Laut diesem Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david sollte das jedoch nichts Wichtiges sein, und daher führen wir den Launcher mit --skip-prereqs aus, da wir sonst Discourse nicht einmal ausführen können.
Ich frage mich jedoch, ob es mehr zu dieser Anforderung an den Storage-Treiber gibt.
Das ist ein bisschen… überoptimistisch. Zum Testen kann es ausreichen, und selbst dann ist es etwas knapp. 2 GB sind schon realistischer.
4 GB reichen für größere Instanzen aus. Aber auch die Anzahl und Leistung der Kerne spielen eine wichtige Rolle.
Und trotzdem… wenn Sie 5 GB haben und der Wiederaufbau so lange dauert, muss etwas falsch sein.
Ich bin auf DigitalOcean/4 GB/2 Intel vCPU und der Wiederaufbau dauert etwa 25 Minuten.
Was genau ist Ihr System, plus app.yml — gibt es etwas Benutzerdefiniertes?
Hallo, das Einzige, was benutzerdefiniert ist, ist das, was ich zuvor erwähnt habe (vfs anstelle von aufs/overlay).
Der Rest ist Vanilla.
Server:
Gesamtspeicher des Servers: 4,657 GiB, Kernel-Version: 5.15.0-43-generic, Betriebssystem: Ubuntu 22.04 LTS, 50 GB SSD-Laufwerk, 2,5 Kerne, 5 Threads Intel® Xeon® CPUs
yaml ist original, abgesehen von diesen zusätzlichen Plugins:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
Ich sehe anhand dieser Daten nicht, warum der Wiederaufbau so lange dauern würde.
Ich würde einen Ubuntu-VPS gleicher Größe woanders aufsetzen. Nur um herauszufinden, ob das Problem vom Hosting-Unternehmen stammt. Es kostet Sie ein paar Euro und ein bis zwei Stunden Arbeit.
Zum Vorverkompilieren von JavaScript wird viel Speicher benötigt. Versuchen Sie, Swap hinzuzufügen.
Das Overlay
Ich denke, dieser Test ist aus einem bestimmten Grund vorhanden. Das könnte Ihr Problem sein.
Warum 5 GB RAM mit Vanilla Discourse mehr Swap benötigen würden, wenn kleinere völlig zufrieden sind mit dem, was sie automatisch bekommen haben?
Weil es einfacher ist, als das zu tun, was man wirklich tun muss.
Das Hinzufügen von Swap könnte helfen, aber es ist nicht Ihr größtes Problem.
Ich nehme an, ich hätte das vor dem Bereitstellen des Discourse-Containers versuchen sollen: How to change the Docker storage driver – Webdock
Anscheinend ist es möglich, den Storage-Treiber zu ändern – im Gegensatz zu dem, was der Host mir damals bei der Bereitstellung des Containers geraten hat (nämlich entweder die Loader-Datei zu bearbeiten oder die Prüfung zu ignorieren).
Duh, jetzt ist es wohl zu spät.
Danke trotzdem, wenn dies die Ursache der Probleme ist, dann ist es wohl Anwenderverschulden. Mea culpa 
Das würde ich nicht denken.
Außerdem hat das Zwei-Container-Setup die Ausfallzeit reduziert, da Sie den neuen Web-Container neu erstellen, während der alte weiterläuft.
Wie groß ist Ihre Website? Ich würde Swap trotzdem hinzufügen, um das Speicherproblem zu beheben.
Eine leere 1-GB-Instanz mit 1 GB Swap funktioniert gut für eine kleine Test-Community, aber sobald sie wächst, reicht das nicht mehr aus. Der Swap macht absolut einen Unterschied.
Wenn das Neuerstellen auf einem „riesigen“ VPS, der in einem Rechenzentrum mit einer fetten Internetverbindung steht, 3 Stunden dauert und das Neuerstellen meiner Installation auf https://discourse-on-a-pi.falco.dev, die auf einem kreditkartengroßen Board auf meinem Schreibtisch läuft und über einen Standard-Heimplan in einem Entwicklungsland mit dem Internet verbunden ist, nur 14 Minuten (+4 Minuten, wenn es ein neues Container-Image gibt) dauert, dann stimmt etwas nicht mit dem Produkt, das sie Ihnen verkaufen…
Wie ist die Speicherauslastung auf dem Server? Wenn Sie bereits am oder nahe am Limit sind, bevor Sie mit dem Wiederaufbau beginnen, wird es viel Swapping geben, und das wird sicherlich dazu führen, dass alles übermäßig lange dauert.
Wenn dies der Fall ist, würde ich vorschlagen, alles andere, was möglicherweise auf dem Server läuft, vorübergehend zu deaktivieren, wenn möglich.