Festplattennutzungsspitze beim Backup, Discourse stürzte hart ab :-(

[pnoeric (Eric)]

Heute Morgen gegen 5:35 Uhr stieg der Festplattenspeicher meiner Foren plötzlich stark an und sie stürzten ab, wodurch sie komplett offline gingen. Ich musste das Digital Ocean-Image vergrößern, um sie wieder zum Laufen zu bringen. Oof.

Hier ist meine Festplattennutzung der letzten 24 Stunden:

Frage: Welche Art von Logs oder Post-Mortem-Analysen kann ich einsehen, um herauszufinden, was zum Teufel passiert ist?! Ich habe die Logs im Discourse-Adminbereich geprüft, aber dort gibt es keine Hinweise… sie enden einfach, als die Seite abstürzte, und setzen sofort wieder ein, als sie wieder online ging.

[bartv (Bart)]

Ich würde zuerst herausfinden, welches Verzeichnis das Problem verursacht. Mein Standardansatz ist, ins Verzeichnis /var/discourse zu wechseln und dann du -h -d 1 auszuführen. Gehe in das größte Verzeichnis, betrete es und wiederhole den Vorgang, bis du den Übeltäter findest. Sobald du ihn hast, könnte das einen Hinweis darauf geben, was los ist.

[markersocial]

Vielleicht ein automatisches Backup?

[riking (Kane York)]

Ja, Backups sind eine häufige Ursache für solche Fehler. Wie sieht die Datennutzung über einen Zeitraum von 7 Tagen aus?

Beachten Sie außerdem, dass lokale Uploads in diesen Backups enthalten sind. Wenn Sie also um 18:00 Uhr einen deutlichen Anstieg der Uploads hatten, würde dies auch die Größe des Backup-Archivs erhöhen.

[pnoeric (Eric)]

Hmm. Ich bin dabei, Dateien von S3 zurück auf meinen lokalen Server zu migrieren, aber der Prozess scheint im laufenden Betrieb zu laufen und verarbeitet nur einige hundert Bilder (jeweils ca. 300 KB) pro Durchgang – also etwa 0,1 GB pro Batch. In der letzten Woche habe ich das Skript vielleicht 20 Mal ausgeführt, also 20 Batches = insgesamt rund 2 GB an Festplattenspeicher. Davon hatte ich mehr als genug Platz.

Gibt es eine Möglichkeit, dass, obwohl das Skript die Dateien im laufenden Betrieb zu verschieben scheint (Herunterladen von S3 und sofortiges Hochladen auf Digital Ocean), es trotzdem eine Art Verzögerung für einen in die Warteschlange gestellten Job gibt, der um 5:30 Uhr morgens ausgelöst wurde und mit dem Verschieben dieser Bilder zusammenhängt?

(Auch: Ich habe diese Batches manuell bis 21 Uhr ausgeführt, also war der Server so weit ich weiß von 21 Uhr bis 5:30 Uhr, als er ausfiel, nur mit normalen Operationen beschäftigt.)

Hier ist meine 7-Tage-Festplattennutzung. Sie stieg stetig durch die importierten Bilder an, aber man sieht, wo sie um 5:30 Uhr auf 100 % gestiegen ist:

Gibt es weitere Logdateien, die Hinweise darauf geben könnten, was um 5:35 Uhr passiert ist, außer den Logdateien, die ich im Reiter „Logs

[pnoeric (Eric)]

Hmm. Meine Backups sind so eingestellt, dass sie alle 2 Tage nach S3 gesendet werden, aber seit dem 9. ist nichts mehr passiert?

Discourse-Ansicht „Backups"

Amazon S3-Ansicht

Übrigens: Nachdem ich das oben Gesehene betrachtet hatte, habe ich in Discourse auf den Button geklickt, um ein Backup auszulösen. Das dauerte 28 Minuten und schien problemlos zu funktionieren; ich sehe jetzt die .tar.gz-Datei sowohl in der Discourse- als auch in der Amazon S3-Ansicht meiner Backups. Warum werden meine automatischen Backups also nicht ausgelöst?! Arggggh.

[pnoeric (Eric)]

@bartv

Ich würde damit beginnen, herauszufinden, welches Verzeichnis den Speicherplatz sprengt. Mein Standardvorgehen ist, in /var/discourse zu wechseln und dann du -h -d 1 auszuführen. Nimm das größte Verzeichnis, gehe hinein und wiederhole den Vorgang, bis du den Übeltäter gefunden hast. Sobald du ihn hast, könnte das einen Hinweis darauf geben, was los ist.

Ich bin ratlos… keines davon ist besonders groß:

root@x-app:/var/www/discourse# du -h -d 1

3.5M	./lib
104K	./bin
8.0K	./.tx
148M    ./public
8.0K	./.bundle
14M     ./plugins
4.3M	./db
4.0K	./log
532M	./tmp
8.9M	./spec
17M     ./config
556M	./vendor
8.0K	./images
329M	./.git
2.0M	./script
80K	    ./docs
2.5M	./test
16K	    ./.github
17M	    ./app
1.6G	.

Und selbst wenn ich mir den gesamten Speicherplatz im Docker-Container ansehe, ist er nicht so groß wie zuvor. Ich hatte einen 80 GB großen DigitalOcean Droplet, der auf 100 % zugegangen ist. Also habe ich ihn auf 160 GB vergrößert, also verdoppelt. Theoretisch müsste dann eines dieser Verzeichnisse bei 50 % liegen, oder?

root@x-app:/var/www/discourse# df -h

Filesystem      Size  Used Avail Use% Mounted on
overlay         155G   58G   98G  38% /
tmpfs            64M     0   64M   0% /dev
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
shm             512M  2.6M  510M   1% /dev/shm
/dev/vda1       155G   58G   98G  38% /shared
tmpfs           3.9G     0  3.9G   0% /proc/acpi
tmpfs           3.9G     0  3.9G   0% /proc/scsi
tmpfs           3.9G     0  3.9G   0% /sys/firmware

[mcdanlj (Michael K Johnson)]

Du hattest fast jede Nacht zuvor Spikes bis zu fast 100 % – es sieht so aus, als hätte dich dieser hier endgültig über die Klinge springen lassen. Ich gehe davon aus, dass die vorherigen Backups aufgrund von Speichermangel beim Erstellen der lokalen Backup-Datei für den Versand an S3 fehlgeschlagen sind, aber lediglich fehlschlugen und dein Forum nicht zerstörten. Du hast es schließlich bemerkt, als der Speichermangel PostgreSQL (oder Redis oder was auch immer – das ist wirklich nicht wichtig) genau im richtigen Moment unzufrieden machte und dein Forum zum Erliegen brachte.

(Bei fast 100 GB Bildern auf meinem Server führe ich Discourse-geplante Backups ohne Uploads, aber mit Thumbnails durch. Anschließend mache ich zuerst ein offsite-basiertes Offset-Backup des Backup-Verzeichnisses und danach des Uploads-Verzeichnisses. Ich habe dies für die Wiederherstellung getestet; es war die Grundlage für eine Website-Migration, die ich letztes Jahr durchgeführt habe. Jeden Nacht 100 GB große Tarballs zu speichern, wäre verrückt.)

[pnoeric (Eric)]

Aha, also diese kleinen Spitzen bedeuten, dass Discourse versucht, ein Backup zu erstellen! Das wirft einiges an Licht auf die Sache.

Hier ist also erneut mein Chart der letzten 7 Tage.

Vielleicht ist das, was wir sehen:

1. Mehrfach in der vergangenen Woche hat Discourse versucht, ein Backup zu erstellen. Dieser Prozess verbraucht vorübergehend viel Festplattenspeicher, und jedes Mal, wenn es versucht hat, ging der Speicher aus, sodass keines dieser Backups tatsächlich funktionierte.

2. Als es gestern Nacht erneut versuchte, ein Backup zu erstellen, kam es weiter, aber leider stürzte die Website dabei ab.

Das ergibt Sinn, da das letzte erfolgreiche Backup am 9. Juli war. Also wartete es 2 Tage (entsprechend meinen Einstellungen) und versuchte es erneut am 11. Juli. Das schlug fehl, also wartete es 24 Stunden und versuchte es am 12., 13. und am 14. mit dem fatalen Wiederholungsversuch.

Wenn das passiert ist, würde ich mir wünschen:

1. Bessere Benachrichtigungen von Discourse, wenn ein Backup fehlschlägt.

2. Vielleicht sollte Discourse ein Backup automatisch als „gescheitert

[mcdanlj (Michael K Johnson)]

Es ist letzte Nacht nicht unbedingt weitergekommen; du hast einfach ein „Rennen verloren

[pnoeric (Eric)]

@mcdanlj

Ich weiß nicht, wie du „unangemessen“ beurteilst – es kommt mir nicht als unangemessen vor.

Das ist fair; wie du richtig anmerkst, spielen viele Variablen eine Rolle.

@mcdanlj

Ein fester Prozentsatz sagt dir nicht wirklich viel; die Datenbank könnte im Vergleich zu den Uploads winzig sein oder umgekehrt, und es gibt Variablen wie, ob Thumbnails einbezogen werden und ob Uploads einbezogen werden. Ich könnte mir eine konfigurierbare Anforderung für den freien Speicherplatz vorstellen, damit du sie für deine Seite anpassen kannst, schätze ich.

Oh, der „richtige“ Weg wäre, die Menge an Speicherplatz zu berechnen, die es für das Backup usw. benötigt. Aber um es super einfach zu halten, ja, einfach ein fester Prozentsatz. Ich denke nur… wenn die beiden Optionen sind „deine Seite könnte komplett abstürzen und offline gehen“ oder „hier ist eine nicht-perfekte, aber schnelle Lösung für das Problem“, dann nehme ich Letzteres, danke.

Und um beim Danken zu bleiben: DANKE dir für deine ganze Hilfe beim Migrations-Prozess und für deine Gedanken dazu.

[mcdanlj (Michael K Johnson)]

Den für ein Backup benötigten Speicherplatz abzuschätzen, ist eines der schwierigen Probleme in der Informatik … Es ist ein entfernter Verwandter der Ladeanzeige.

Im Ernst: Ein Teil davon ist ein Datenbank-Dump, und ich weiß nicht, wie man das im Voraus abschätzen könnte. Wenn Sie so viele Bilder haben, dass der Speicherplatz zum Problem wird, ist deren Aufnahme in Backup-Archive wahrscheinlich außerhalb des Mainstreams.

Typischerweise waren bei der Systemverwaltung die Überwachung des freien Speicherplatzes und die Gesundheit der Backups eine administrative Belastung und keine Anwendungsbelastung. Das ist Teil dessen, wofür die Leute bezahlen, wenn sie CDCK beauftragen, ihr Discourse zu hosten.

Es gibt viele andere Möglichkeiten, den Speicherplatz zu erschöpfen. Ich weiß, dass Sie sich auf den Fall konzentrieren, der Sie betroffen hat, aber das Problem ist allgemeiner, und ich denke, dass dies normalerweise als administrativer Aufwand behandelt wird.

[DBHacker]

Ich möchte nicht die Stimmung verderben, aber beim Lesen der Beiträge gibt es keine eindeutige Bestätigung, dass der Discourse-Backup-Prozess das Problem verursacht.

Warum nicht zu 100 % bestätigen, dass dieses Problem durch den täglichen Backup-Prozess verursacht wird? Auf den Hosts laufen mehrere Prozesse in den täglichen Crontab-Dateien.

Hat @pnoeric ein du auf dem /var/discourse-Dateisystem (außerhalb des Containers) ausgeführt?

In deinen Notizen schreibt @pnoeric:

root@x-app:/var/www/discourse# du -h -d 1

Dieser Befehl hat jedoch das Discourse-Verzeichnis „shared“ inklusive aller Backups und Uploads komplett übersehen! Außerdem wurden alle Docker-Dateien (und Images) auf dem Host übersehen (die groß werden können, wenn Images nicht regelmäßig bereinigt werden).

Der richtige Ort, um diesen Check durchzuführen, ist außerhalb des Containers (nicht im Container!):

Zum Beispiel (außerhalb des Containers):

cd /var/discourse 
/var/discourse# du -sh *
4.0K	bin
4.0K	cids
56K	containers
12K	discourse-doctor
24K	discourse-setup
164K	image
24K	launcher
4.0K	LICENSE
12K	README.md
24K	samples
8.0K	scripts
62G	shared
148K	templates

Man sieht, dass auf diesem Host das Verzeichnis „shared“ 62 GB groß ist.

Und auch aus dem /-Verzeichnis des Dateisystems (außerhalb des Containers):

cd /var
# du -sh *
511M	cache
20K	composetest
62G	discourse
1.6G	docker
8.0K	legacy
52G	lib
4.0K	local
0	lock
4.0K	locks
5.7G	log
24K	logs
64K	mail
4.0K	opt
4.0K	registry
4.0K	shared
1.9M	spool
48K	tmp
25G	 linux_app
2.2G	www

Ich möchte nicht die Stimmung verderben, aber bevor man loszieht und viele „Lösungen“ für Discourse vorschlägt, wäre es sehr gut, zu 100 % sicher zu sein, dass der Discourse-Backup-Cron der eigentliche Verursacher ist.

Wir hatten bisher keinerlei Probleme mit dem aktuellen Discourse-Backup-Prozess, und zudem ist die Verwaltung des Dateisystems auf dem Host keine Discourse-Aufgabe an sich.

Hier:

du

Filesystem     1K-blocks      Used Available Use% Mounted on
udev            32892500         0  32892500   0% /dev
tmpfs            6584232      2136   6582096   1% /run
/dev/md2       470927632 215969956 230966124  49% /
tmpfs           32921160         0  32921160   0% /dev/shm
tmpfs               5120         0      5120   0% /run/lock
tmpfs           32921160         0  32921160   0% /sys/fs/cgroup
/dev/md0          482922     75082    382906  17% /boot
/dev/sda1         244988      4636    240353   2% /boot/efi
tmpfs            6584232         0   6584232   0% /run/user/1000
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/0f8be368b0154285423630ad50148ee2d5fdcb357c46125eafa7374ca34ef29a/merged
shm               524288      1620    522668   1% /var/lib/docker/containers/ca7b55fc5a0c123f7b2b1234ea210aa8286a34167cba9344b7929547bd323c9b/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7cd7e8b5b35b496eaed68753cc995e9303499a24721062055e2f06beb07e26c8/merged
shm                65536         0     65536   0% /var/lib/docker/containers/3cc0c90c3e3a5db6692e7b5d21727fbb1c13c8e07e48e4f6d954214fc03694a9/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/31533fdf68033eed96dab4f9df89025ea3dab172ed48b6ce6431840a8df1c8ea/merged
shm               524288         0    522668   0% /var/lib/docker/containers/631fbabedda9a430dd8204ec66fb45c7514d948025124171b960ea424e28d5d4/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7a3ba2223ee93bc868b52b3707799d0fd7b4ca6dcc0df29f20c2c98a53903ff1/merged
shm                65536         0     65536   0% /var/lib/docker/containers/7a145366268c8ac5543a4555dc1bfc63c1e85a654e4c793e96fc2cc2e8514388/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/add4bdd7bd88df7a0e05dff21896d3ef796f7cf2ff9759e0bb04b1953f16cd95/merged
shm                65536         0     65536   0% /var/lib/docker/containers/123743e122089b94660a6bdd2a9e55055ad91b6f75cce4ac760f36066bcf14d0/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/b376ff32eaac0c58463e8b99b6db9ec0da3405c3f7a9f00b5430f10e07d372b0/merged
shm               524288         0    522668   0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm

Schauen wir uns die Docker-Dateien an:

# cd /var/lib
# du -sh docker
30G	docker

Unsere Docker-Images werden regelmäßig bereinigt und gelöscht.

@bartv hat korrekt vorgeschlagen, hier zu beginnen:

Ich würde zuerst herausfinden, welches Verzeichnis explodiert. Mein Standardansatz ist, in /var/discourse zu wechseln und dann du -h -d 1 auszuführen. Gehe dann in das größte Verzeichnis und wiederhole den Vorgang, bis du den Verdächtigen gefunden hast. Sobald du ihn hast, könnte das einen Hinweis darauf geben, was los ist.

Das ist ein guter Anfang, aber es kann viele andere Stellen auf dem Host-Dateisystem geben, die den Speicherplatz füllen können, einschließlich Docker, Core-Dateien usw.

Ein Diagramm, das einmal täglich einen Anstieg des Prozentsatzes zeigt, reicht nicht aus, um mit Autorität zu behaupten, dass der Discourse-Backup-Cron-Prozess die Ursache ist. Es könnte sein, aber es könnte auch nicht sein – basierend auf den bisherigen Beweisen!

[pnoeric (Eric)]

Das ist großartig. Ich werde alles ausprobieren, was du erwähnt hast. Vielen Dank.

[riking (Kane York)]

@pnoeric

Hier ist meine 7-Tage-Festplattennutzung. Sie stieg stetig durch die importierten Bilder an, aber man sieht deutlich, wo sie um 5:30 Uhr morgens auf 100 % sprang:

Genau, das ist offensichtlich ein Backup.

@DBHacker

Ich möchte die Stimmung nicht verderben, aber beim Lesen der Beiträge gibt es keine feste Bestätigung dafür, dass der Discourse-Backup-Prozess das Problem verursacht.

Warum nicht zu 100 % bestätigen, dass dieses Problem durch einen täglichen Backup-Prozess verursacht wird? Auf den Hosts laufen mehr als ein Prozess in den täglichen Crontab-Dateien.

Nein, es gibt reichlich Bestätigungen: Die Spitzen treten in einem 2-Tage-Intervall auf (mit einer Ausnahme), und die Backup-Häufigkeit ist auf 2 Tage eingestellt. Auch frühere Erfahrungen auf Meta haben genau diesen Fehlermodus gezeigt.

@mcdanlj

(Auf meinem Server befinden sich fast 100 GB Bilder. Ich führe geplante Discourse-Backups ohne Uploads, aber mit Thumbnails durch. Anschließend erstelle ich zunächst ein externes, dateibasiertes Inkremental-Backup des Backup-Verzeichnisses und danach des Upload-Verzeichnisses. Ich habe dies für die Wiederherstellung getestet; es war die Grundlage für eine Site-Migration, die ich letztes Jahr durchgeführt habe. Es wäre verrückt, jede Nacht 100 GB große Tarballs zu speichern.)

Ja, das ist ein solider Plan für die Zukunft. Die erste Empfehlung für Nutzer, die auf ihrem VPS an die Festplattengrenze stoßen, ist jedoch die Speicherung von Uploads außerhalb der Maschine mit dem S3-Mechanismus.

[mcdanlj (Michael K Johnson)]

@riking

Ja, das ist ein solider Plan für die weitere Vorgehensweise. Die erste Empfehlung für Nutzer, die auf ihrem VPS an die Speicherplatzgrenze stoßen, ist jedoch Upload-Speicher außerhalb der Maschine über den S3-Mechanismus.

Da @pnoeric versucht, bei Bildern von S3 wegzuziehen, würde das Speichern von mehreren Kopien aller Bilder in einem Backup, das sich in S3 befindet, den Zweck des Umzugs von S3 nicht erfüllen. @pnoeric, das verwirrt mich – wenn du von S3 wegziehen willst, aber nur einen Bruchteil der Dateien verschiebst, weil du alle Bilder in S3 in mehreren Backup-Kopien speicherst, was ist dann der Sinn?

In jedem Fall wollte ich nur zeigen, wie Alternativen aussehen. Backups sind schwierig, besonders wenn du jemals in der Lage sein willst, aus dem Backup wiederherzustellen (restore).

Ich bin von „S3

[pnoeric (Eric)]

@mcdanlj

Wenn du von S3 wegziehen willst, aber nur einen Bruchteil der Dateien verschiebst, weil du alle Bilder auf S3 in mehreren Backup-Kopien speicherst, was ist dann der Sinn?

Meine Situation ist folgende: Ich habe eine Menge Bilder, was bedeutet, dass bei der Anzeige dieser Bilder durch die Nutzer eine enorme Übertragungsbandbreite anfällt. Als die Bilder noch auf Amazon S3 lagen, war es vor allem die Bandbreitenrechnung, die mich ruiniert hat. Besonders als mir klar wurde, dass ich alle Bilder auf dem DO-Droplet speichern könnte und dies in die bereits gezahlten Bandbreiten- und Speichergebühren einbezogen wäre. (Irgendwann in der Zukunft könnte es sinnvoll sein, die Dinge wieder zu S3 zu verlagern, oder es könnte auch sinnvoller sein, meinen DO-Droplet einfach wieder zu vergrößern…)

Also habe ich mit S3 begonnen, dann meinen Fehler erkannt. Daher meine aktuelle Situation: Ich nutze deinen hervorragenden Code, um alle Bilder von S3 zurück zu DO zu migrieren.

Ein vollständiges Backup (Bilder und alles andere) auf S3 aufzubewahren, ist eine ganz andere Geschichte – es befindet sich auf S3 in „kalter Speicherung“ und wird nur im Problemfall abgerufen. Daher fallen keine hohen Bandbreitenrechnungen an.

Außerdem: Ich habe weiter über die Backup-/Festplattennutzungssituation nachgedacht. Ich bleibe dabei, dass hier etwas fehlt. Vielleicht ist es nur eine Warnmeldung oder eine bessere Dokumentation. Aber mein Discourse nutzte nur 60 % der Festplatte, und meine Offsite-Backups schlugen fehl. Eine Art Schätzung des benötigten Festplattenspeichers oder eine Warnung, wenn nicht genügend Platz vorhanden ist, oder irgendetwas wäre besser als das, was jetzt passiert, wenn nicht genug Platz da ist: mehrere Tage ohne Backup, gefolgt von einem kompletten Absturz, der das Forum vollständig offline brachte. :-\

(@riking hat sogar gesagt: „Backups sind eine häufige Ursache für solche Fehler.“ Stürzen Discourse-Instanzen also regelmäßig ab, weil Backups fehlschlagen, ohne dass vor einem möglichen Problem gewarnt wird?)

Noch einfacher ausgedrückt, aus der 30.000-Fuß-Perspektive: Es scheint ein Designfehler zu sein, wenn eine grundlegende Funktion der Software (automatische Backups) das gesamte System offline bringen kann. Besonders wenn es sich um eine Funktion handelt, die nur Festplattenspeicher nutzt, um das Backup vorzubereiten, und es nicht einmal auf derselben Festplatte speichert.

[codinghorror (Jeff Atwood)]

Nein, er meinte, dass das Erstellen von Backups mit beliebiger Software auf jedem Server potenziell die Festplatte füllen und Probleme verursachen kann.

[Stephen]

@pnoeric

Also, als die Bilder noch auf Amazon S3 lagen, war es vor allem die Bandbreitenrechnung, die mich umbrachte. Besonders als mir klar wurde, dass ich alle Bilder auf dem DO-Droplet speichern und diese Kosten in die bereits gezahlten Bandbreiten- und Speichergebühren einrechnen konnte.

Klar, aber genau dafür frontst du S3 mit einem CDN. Bediene Bilder nicht direkt von S3 – das wird unglaublich teuer . Du kannst S3 ganz einfach mit CloudFront oder sogar CloudFlare fronten. Der kostenlose Tarif von CloudFlare reicht dafür völlig aus.

Und die lokale Speicherung ist ebenfalls eine schlechte Nachricht: Du müsstest deinen VPS unnötig hochskalieren. Lokale SSDs sind deutlich teurer.

[pnoeric (Eric)]

@codinghorror

Nein, er meinte, dass das Erstellen von Backups mit beliebiger Software auf jedem Server den Datenträger füllen und Probleme verursachen kann.

Ah, ok, verstanden.

Also, wie kann ich herausfinden, wie viel Speicherplatz für ein Backup von Discourse benötigt wird? Die Software sagt es mir nicht, also könnte es morgen schon 500 GB sein und meinen Digital-Ocean-Server wieder offline bringen. Wenn ich wenigstens eine grobe Schätzung anstellen kann, kann ich versuchen, den Überblick zu behalten.

@Stephen

…S3 mit einem CDN vorlagern. Bediene Bilder nicht direkt von S3, das wird unglaublich teuer sein . Du kannst S3 ganz einfach mit Cloudfront oder sogar Cloudflare vorlagern. Der kostenlose Tarif von Cloudflare reicht dafür aus.

Wow, das ist eine großartige Idee. Darauf wäre ich nie gekommen. Also würde ich das CDN auf meinen Amazon-Bucket anwenden und dann Discourse anweisen, S3 für alle Assets zu nutzen? (So wie ich es vorher hatte? lol)