Vorkompilieren von Assets dauert 20 Minuten

Installation
1

Ich baue das Image auf einem Digital Ocean Droplet neu auf und etwas dauert ewig:

I, [2024-01-10T09:47:14.854311 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (492.75) ist kleiner als 2048MB. Setze --max-old-space-size=2048.
[WARN] (broccoli-terser-sourcemap) Minifying "assets/admin.js" dauerte: 25461ms (mehr als 20.000ms)
[WARN] (broccoli-terser-sourcemap) Minifying "assets/plugins/chat.js" dauerte: 47818ms (mehr als 20.000ms)
Lösche temporäre Dateien
Bündele Assets
I, [2024-01-10T10:06:07.644096 #3264]  INFO -- : Schreibe /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js

Das Droplet hat 1 GB RAM und läuft ansonsten einwandfrei mit Discourse. Mache ich etwas falsch? Kann ich etwas tun, um den Neuaufbau zu beschleunigen? Danke!

1 „Gefällt mir“
2

Ich glaube, das wird dich jetzt sehr speicherbeschränkt machen.

Es ist mittlerweile so weit, dass ich mindestens 4 GB für eine Discourse-Instanz (plus Swap!) empfehlen würde (selbst mit 2 GB + 2 GB Swap finde ich Online-Updates schmerzhaft langsam).

3 „Gefällt mir“
3

Danke! Leider ist das etwa viermal so teuer für eine Verbesserung, die ich wahrscheinlich nur bei Updates spüren würde. Außerdem steht in der Cloud-Installationsanleitung immer noch:

Die Standardeinstellung von 1 GB RAM funktioniert gut für kleine Discourse-Communities. Wir empfehlen 2 GB RAM für größere Communities.

Wissen wir, woher der Speicherbedarf in diesem Schritt kommt? Vielleicht wäre es möglich, ein schlechteres Kompressionsverhältnis oder etwas Ähnliches gegen geringere Speicheranforderungen einzutauschen?

4

Es kommt von ember-cli.

Sie erleben bereits einen Kompromiss zwischen Zeit und Speicherplatz (mangelnder Speicherplatz führt dazu, dass der Prozess länger dauert).

3 „Gefällt mir“
5

Verwandtes Thema:

1 „Gefällt mir“
6

Ich denke, für mein nächstes Update auf meinen beiden Servern werde ich die Flexibilität des Hosting-Anbieters nutzen, um zu größerem RAM zu migrieren, bevor ich aktualisiere, und danach sofort zu meinem jetzigen Minimum zurückmigrieren. Es gibt eine geringe zusätzliche Ausfallzeit, aber wenn der Neuaufbau viel schneller geht, könnte es ein Gesamtsieg sein. Die zusätzlichen Kosten sollten unter 1 US-Dollar oder vielleicht sogar nur 1 Cent liegen, für eine Stunde zusätzlichen RAM (in meinem Fall von 6 US-Dollar pro Monat auf 12 US-Dollar pro Monat, stündlich abgerechnet bei Digital Ocean zu 1 Cent bzw. 2 Cent).

Wie im verlinkten Thread erwähnt, ist manchmal ein Neustart ohnehin hilfreich, daher ist es für mich eine gute Zeit, OS-Pakete zu aktualisieren und neu zu starten.

Ich hoffe, dass dies auch für mich weniger Verschleiß bedeutet.

Ich werde vielleicht sogar von 1 GB auf 8 GB erhöhen, was zusätzliche 6 Cent pro Stunde kostet, um mir die Freiheit zu geben, meine Swap-Datei vorübergehend zu löschen und den Festplattenspeicher zu entlasten.

Alles erreicht seinen Höhepunkt zur Update-Zeit – zwischendurch scheint die aktuelle minimale Konfiguration immer noch ausreichend zu sein.

Ich kann mir 6 Cent pro Upgrade-Zyklus durchaus leisten.

4 „Gefällt mir“
7

Das ist sehr cool! Wer ist Ihr Hosting-Anbieter?

8

Digital Ocean in einem Fall (1G RAM), Hetzner im anderen (2G RAM).

9

Ermöglichen beide Online-, In-Place-Erhöhungen des RAMs vorübergehend?

Oder müssen Sie zwischen „Droplets“/Instanzen wechseln?

Oder nur ein Neustart?

10

Nein,

Es ist herunterfahren - vergrößern - starten - neu erstellen - herunterfahren - zurück vergrößern - starten

4 „Gefällt mir“
11

OK, aber immer noch vor Ort. Das ist eine großartige Option, aber ja, zusätzlicher Aufwand … und Ausfallzeit.

Da die Neuerstellungszeit auf einer 1-GB-Maschine so lange dauert, könnten Sie das genauso gut tun, denn sie wird sowieso 30 Minuten lang nicht verfügbar sein!

Und sicher, wenn Sie bereit sind, das zu tun, könnte sogar ein temporäres Upgrade einer 16-GB-Maschine kostentechnisch in Ordnung sein :slight_smile:

Ich vermute, viele werden ihre Zeit für wertvoller halten und sollten wahrscheinlich anfangen, dauerhaft über 4 GB nachzudenken.

1 „Gefällt mir“
12

Es ist sicherlich Teil eines Kompromisses zwischen Kosten und Zeit. Ich persönlich habe mich bereits verpflichtet, eine Stunde Babysitting für die Upgrades zu machen, und ich weiß genau, wie dieser Sysadmin-Tanz funktioniert, daher ist die Zeit bereits gebucht. Ich ziehe es vor, die monatlichen laufenden Kosten so niedrig wie möglich zu halten, auch wenn es mich etwas Zeit kostet – andere werden andere Kompromisse eingehen.\n\nSicher, wenn Geld leicht ausgegeben wird, besorgen Sie sich eine komfortabel große Instanz!

1 „Gefällt mir“
13

Nur zur Referenz, ich habe gerade meine beiden Foren aktualisiert, beide innerhalb einer Stunde abgeschlossen. In beiden Fällen habe ich sie vorübergehend auf 8 GB RAM vergrößert und dann wieder verkleinert. Dieser spezielle Schritt dauerte etwa 5 Minuten mit (vorübergehend) 4 CPUs und 8 GB RAM.

I, [2024-01-10T16:07:58.323464 #1]  INFO -- : cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300]  INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js

Hier sehen wir, dass Ember (Spalte 12) 2,5 GB RAM (Spalte 6) und mehr als eine CPU (Spalte 3) verwendet.

# ps auxfc|egrep -A29 containerd
root      1097  0.2  0.5 1510892 44924 ?       Ssl  16:00   0:01 containerd
root      4507  0.1  0.0 717892  7556 ?        Sl   16:03   0:00  \_ containerd-shim
root      4530  0.1  0.3 312292 30512 ?        Ssl  16:03   0:00      \_ pups
systemd+  4609  0.0  0.3 213236 28608 ?        S    16:03   0:00          \_ postmaster
systemd+  4617  0.0  0.8 213340 67288 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4618  0.0  0.0 213236  5876 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4619  0.0  0.1 213236 10076 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4620  0.0  0.1 213904  8860 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4621  0.0  0.0  68004  5592 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4622  0.0  0.0 213796  7100 ?        Ss   16:03   0:00          |   \_ postmaster
message+  4682  0.2  0.4  87976 35724 ?        Sl   16:03   0:00          \_ redis-server
1000      7722  1.1  0.0      0     0 ?        Z    16:07   0:01          \_ esbuild <defunct>
root      7736  0.0  0.0   2476   520 ?        S    16:07   0:00          \_ sh
root      7737  0.0  0.0   9296  4156 ?        S    16:07   0:00          |   \_ su
1000      7738  8.3  0.0   2476   580 ?        Ss   16:07   0:12          |       \_ sh
1000      7835  0.4  0.9 929524 78416 ?        Sl   16:08   0:00          |           \_ node
1000      7857  0.0  0.0   2484   524 ?        S    16:08   0:00          |               \_ sh
1000      7858  156 30.5 67413228 2491796 ?    Sl   16:08   3:37          |                   \_ ember
1000      7876 39.0  1.7 11486300 145476 ?     Ssl  16:08   0:44          |                       \_ node
1000      7882 36.7  1.5 11466956 122648 ?     Ssl  16:08   0:41          |                       \_ node
1000      7889 37.1  4.1 11647592 340908 ?     Ssl  16:08   0:42          |                       \_ node
1000      7761  1.5  0.0      0     0 ?        Z    16:08   0:02          \_ esbuild <defunct>

Wahrscheinlich wären 4 GB RAM für mich ausreichend gewesen, aber wie erwähnt, hat das Ganze nur ein paar Cent gekostet. (Ich sehe jetzt, dass ich für einen Cent mehr schnellere CPUs hätte wählen können.)

Bearbeiten: Ich habe vor Beginn ein Backup gemacht und ein weiteres, nachdem die Aufgabe erledigt war. Dazwischen lagen 35 Minuten. Die Ausfallzeit für die Benutzer war also nicht länger.

Bearbeiten: Beachten Sie, dass das Digital Ocean Control Panel besagt, dass der Größenänderungsvorgang bis zu 1 Minute pro GB Daten auf der Festplatte dauern kann – in meinem Fall nur 14 GB und wie sich herausstellte, nur 2 Minuten für jede Größenänderung. Wenn Sie jedoch viele Daten auf der Instanz haben, kann dieser Größenänderungstanz länger dauern. (Andererseits, wenn Sie viele Daten haben, versuchen Sie vielleicht nicht, mit weniger als 4 GB RAM zu arbeiten.)

3 „Gefällt mir“
14

4 GB RAM reichen in manchen Fällen immer noch nicht aus. Ich habe zum Beispiel eine 8 GB RAM-Sandbox mit praktisch keinem Traffic, aber es ist eine Multisite-Einrichtung, die es ermöglicht, 5 Einweg-Sandboxes zu haben. Der Wiederaufbau schlug heute aufgrund von Fehler 137 (OOM) fehl und ich hatte den Trick ausprobiert, den @richard oben vorgeschlagen hat. Um mir jedoch die Mühe zu ersparen, dies jedes Mal tun zu müssen, habe ich einen größeren Swap (4 GB) erstellt, der es vorerst ermöglicht hat, die Wiederaufbauten durchzuführen. Es scheint, dass wir im letzten Jahr nur Server aufrüsten, weil Discourse-Wiederaufbauten aus irgendeinem Grund wirklich RAM-hungrig werden.

2 „Gefällt mir“
15

Interessant. Haben Sie die Kernel-Einstellungen, wie sie in MKJ’s Opinionated Discourse Deployment Configuration dargelegt sind?

(Es lohnt sich immer, Swap zu haben, 2G oder 4G oder was auch immer freier Speicherplatz zulässt. Ich habe minimalen Swap, weil ich minimalen Speicherplatz habe.)

16

Wenn ich darüber nachdenke, beschränkt sich der Vorteil wirklich auf vollständige Neuinstallationen – ich kann derzeit keine Online-Upgrades in einer 2+2-Konfiguration verwenden :frowning: … und ich glaube nicht, dass ich diesen Upgrade/Downgrade-Tanz nur zum Aktualisieren z. B. eines einzelnen Plugins machen werde …

Ich persönlich bin der Meinung, dass ein permanentes Upgrade auf mindestens 4 GB der einzige Weg ist …

Hinweis: Ich beschwere mich nicht wirklich darüber, mit der Zeit gehen zu müssen … aber wir sollten die Realität vielleicht in der Dokumentation und den Ratschlägen für Administratoren widerspiegeln?

Es macht Discourse leider etwas weniger zugänglich für neue, insbesondere jüngere Leute :thinking:

1 „Gefällt mir“
17

Ich bin tatsächlich mit dieser Idee einverstanden: Behalten Sie die aktuelle minimale empfohlene Konfiguration als Ziel bei und untersuchen Sie Tweaks im Code oder Änderungen Upstream, um die Dinge im Zaum zu halten. Es ist eine große Änderung im Angebot, wenn die Mindestkonfiguration jetzt doppelt so teuer ist. Deshalb habe ich anderswo geäußert, dass übermäßige Speicheranforderungen ein Fehler sind.

2 „Gefällt mir“
18

Beim Versuch, auf die neueste Version zu aktualisieren, treten jetzt fehlgeschlagene Upgrades auf:

...[@embroider/webpack]
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands.rb:18:in `<main>'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 1 Unicorn worker(s) that were stopped initially

Ich gehe davon aus, dass dies ein Out-of-Memory-Fehler ist? Bedeutet das, dass 1-GB-Maschinen offiziell ausgedient haben?

19

Das ist in der Tat ein Out-of-Memory-Fehler. Wenn Sie genügend Festplattenspeicher haben, um Swap hinzuzufügen, wird das ausreichen, obwohl der Prozess länger dauern wird, als wenn Sie RAM hinzufügen würden. Ihr Hosting-Anbieter bietet möglicherweise die Möglichkeit, RAM vorübergehend zu erweitern und dann zurückzusetzen, was Sie wahrscheinlich ein paar Neustarts, etwas Ausfallzeit und ein paar Cent zusätzliche Kosten kostet.

Bearbeiten: Um es klarzustellen, Speicher = RAM + Swap. RAM ist schnell und Swap ist billig.

2 „Gefällt mir“