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.)