Nicht mein Problem, aber bedeutet das, dass es nichts weiter gibt?
1 „Gefällt mir“
Vielleicht nicht absichtlich, aber es könnte sich lohnen, den Inhalt des Hosts auf Krypto-Mining-Prozesse usw. zu überprüfen…
3 „Gefällt mir“
Schritt 1: Beheben Sie das bereits identifizierte Leistungsproblem bei der Verwendung des vfs-Treibers
7 „Gefällt mir“
Was diesen Wechsel zu (idealerweise) overlay2 betrifft, muss ich meine aktuelle Installation löschen und alles neu installieren. Das liegt daran, dass der Host, auf dem ich mich gerade befinde, nur fuse-overlayfs oder vfs unterstützt, was von beidem nicht empfohlen wird.
Sie werden jedoch bald KVMs aktivieren, die overlay2 unterstützen.
Mein Vorhaben wäre es also, dies zu nutzen, anstatt des ebenfalls nicht empfohlenen fuse-overlayfs.
Nun kann ich in der Discourse-App selbst Backups erstellen. Was wird dabei genau gesichert?
Würde ich irgendetwas vom aktuellen Discourse-Forum verlieren (ich meine Nachrichten, Chats, Einstellungen, Benutzer, hochgeladene Bilder usw.), wenn ich ein Backup erstelle, ein neues Discourse auf einem neuen Server neu installiere und es dann nach der anfänglichen Discourse-Einrichtung mit dem Backup überschreibe?
Würde das funktionieren?
Ja, das würde funktionieren.
Das Einzige, was Sie nicht erwähnt haben, ist, sicherzustellen, dass Sie die gleichen Plugins auf dem neuen Discourse haben wie auf dem aktuellen. Wenn Sie Ihre app.yml wiederverwenden, wäre das auch in Ordnung.
3 „Gefällt mir“
Okay, danke für den Hinweis, ich wette, ich wäre direkt hineingelaufen.
Okay, also…
- Backup im Discourse-Adminbereich erstellen
- Nur zur Sicherheit, natürlich, Backup des Servers erstellen
- Kopie der YAML-Datei erstellen
- Server dumpen
- Neuen Server mit unterstützter Technologie einrichten
- Docker mit entsprechendem Storage Driver installieren
- Eine komplett neue Discourse-Instanz neu erstellen unter Verwendung der gesicherten YAML-Datei
- Discourse aus dem Backup wiederherstellen
Etwas überrascht, dass das Backup nur 19,2 MB groß ist.
Wir haben bereits mehrere Bilder usw. hochgeladen… aber ich schätze, alles, was ich tun kann, ist es zu versuchen.
Ich werde das am Wochenende in Angriff nehmen und berichten, ob die Änderung des Storage Drivers das Problem gelöst hat.
1 „Gefällt mir“
Überprüfen Sie, ob dies eingestellt ist:
1 „Gefällt mir“
Bitte beachte, dass diese spezielle Einstellung nur für geplante Backups gilt, nicht für manuelle. Bei manuellen Backups erhältst du immer eine explizite Auswahl.
Eine weitere zu aktivierende Einstellung ist Vorschaubilder in Backups einschließen
@smileBeda Ich würde #4 verschieben, bis alles in Ordnung ist.
3 „Gefällt mir“
Es ist tatsächlich aktiviert, aber Include generated thumbnails in backups. Disabling this will make backups smaller, but requires a rebake of all posts after a restore. war es nicht.
@RGJ … richtig, gute Idee, es wird mehr Schritte erfordern, da ich einen Server unter einer neuen Entität erstellen muss, aber es ist geringfügig im Vergleich zum Risiko.
Ich werde das automatisierte Backup auslösen lassen, damit ich alle Daten darin habe, da ich verstehe, dass das manuelle Backup die Bilder usw. nicht enthalten würde.
Danke…
Das ist eine falsche Annahme.
Wenn Sie ein Backup manuell erstellen, erhalten Sie in einem Popup die Wahl, ob Sie nur die Datenbank sichern möchten oder ob Sie Uploads einschließen möchten.
Wenn Sie geplante Backups erstellen, entscheidet die Einstellung Backup mit Uploads darüber.
4 „Gefällt mir“
Ok, ich habe Ihre vorherige Aussage falsch verstanden: „Bitte beachten Sie, dass diese spezielle Einstellung nur für geplante Backups gilt, nicht für manuelle.“
Danke…
2 „Gefällt mir“
Hallo, ich greife dieses Thema wieder auf, da es noch offen ist und wir nach der Migration auf einen neuen virtuellen Server das gleiche Problem haben. Wie alle anderen sagen, hat es nie länger als 20 Minuten gedauert, unser Discourse neu zu erstellen, aber auf diesem neuen Server dauert es Stunden, und er hat doppelt so viele Ressourcen wie der vorherige. 
Ich habe andere Themen über stundenlange Upgrades auf Meta überprüft, aber ich kann nicht herausfinden, was das Problem bei uns ist:
Server: 4 GB RAM, 2 CPU, 50 GB Festplatte.
Swap:
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Sieht für mich normal aus, aber vielleicht übersehe ich etwas. Wo können wir noch nachsehen?
Vielleicht ist ein störender Nachbar dafür verantwortlich, dass Ihr neuer VM langsamer ist als der alte, weil er die gesamte CPU nutzt, die Sie nicht erhalten?
1 „Gefällt mir“
Ja, danke, es ist beruhigend, dass ein erfahrener Administrator wie Sie nichts Offensichtliches in den obigen Informationen sieht. Und ja, wir beginnen, uns den physischen Server und unsere virtuelle Nachbarschaft anzusehen. Zumindest funktioniert das Forum ohne für Benutzer wahrnehmbare Probleme. Wir stoßen nur bei Rebuilds auf dieses ernsthafte Leistungsproblem. Gestern hat es uns 4 Stunden gedauert, bis wir fertig waren. 
1 „Gefällt mir“
Wenn ich dieses Problem hätte, würde ich zwei oder drei Terminalfenster offen haben. Eines, um den Rebuild auszuführen, eines, um Notizen über die verstrichene Zeit zu machen und festzuhalten, wo die langen Verzögerungen zwischen den Log-Updates auftreten, und das letzte, um die Maschinenaktivität aufzuzeichnen: wahrscheinlich mit vmstat 5 ausgeführt.
Wenn Sie an einen Punkt gelangen, an dem das Protokoll für eine verdächtig lange Zeit nicht aktualisiert wird, machen Sie sich Notizen über die von vmstat gemeldete Aktivität.
Posten Sie hier geeignete Auszüge aus dem Protokoll mit Ihren Notizen und der entsprechenden vmstat-Ausgabe.
Es ist sehr wahrscheinlich, dass es sich um bestimmte Teile des Rebuilds handelt, die Zeit in Anspruch nehmen: Das Ziel ist es, herauszufinden, welche Teile das sind und was die Maschine zu diesen Zeiten tut.
Ich würde wahrscheinlich auch während der Pausen mit ps auxf einen Schnappschuss der Maschinenaktivität machen.
4 „Gefällt mir“
Vielen Dank, das ist ein sehr guter Rat. Nächstes Mal, wenn wir neu aufbauen müssen, werden wir es so machen.
2 „Gefällt mir“