Backups zu S3 funktionieren seit mehreren Jahren. Seit einem Monat erhalte ich häufiger mehrere Benachrichtigungen, dass das Backup fehlgeschlagen ist. Dann versucht es erneut, und etwa eine Stunde später schlägt es wieder fehl, sodass ich eine zweite Benachrichtigung bekomme, und oft bis zu sechs Benachrichtigungen an einem Tag, bevor es schließlich erfolgreich ist.
Das Log aus der Benachrichtigung sagt, dass es beim Hochladen der ZIP-komprimierten Tar-Datei zu S3 scheitert. In meinem S3-Konto kann ich keine Fehler finden.
4etails4 6
4r4m e
Der erste Teil des Logs sieht normal aus, dann:
[2025-05-20 07:11:38] Backup wird finalisiert…
[2025-05-20 07:11:38] Archiv erstellen: 506-investor-group-2025-05-20-070428-v20250513161753.tar.gz
[2025-05-20 07:11:38] Sicherstellen, dass das Archiv noch nicht existiert…
[2025-05-20 07:11:38] Leeres Archiv erstellen…
[2025-05-20 07:11:38] Daten-Backup archivieren…
[2025-05-20 07:12:17] Uploads archivieren…
[2025-05-20 07:15:48] Temporäres Verzeichnis ‘/var/www/discourse/tmp/backups/default/2025-05-20-070428’ entfernen…
[2025-05-20 07:15:48] Archiv komprimieren, das kann eine Weile dauern…
[2025-05-20 07:32:51] Archiv hochladen..
Könnte Ihnen der Arbeitsspeicher ausgehen? Diese Ausnahme lässt mich vermuten, dass Sidekiq (das die automatischen Backups ausführt) entweder vom Betriebssystem beendet wird oder aus einem anderen Grund abstürzt.
Haben Sie versucht, den Docker-Container neu zu erstellen (./launcher rebuild app), um zu sehen, ob das Problem dadurch behoben wird?
Ich glaube nicht. Der Server ist mit 16 GB RAM für unsere Community überdimensioniert. top zeigt 11 GB freien Speicher an, und das ändert sich kaum, wenn ich manuell ein Backup auslöse.
Ich werde morgen /var/log/syslog auf alles überprüfen, was mit Speicher, kill oder OOM zu tun hat. (Kann es heute nicht überprüfen, da ich einige nicht verwandte ausführliche Protokolle hatte und das Backup-Ereignis aus dem Syslog-Puffer herausscrollt.)
Ja, ich habe vor ein paar Tagen auf 3.5.0.beta5-dev aktualisiert und das Problem besteht weiterhin.
Ich habe das in /logs. Diese spezielle Warnung fiel nicht mit dem Backup zusammen – das prüfe ich morgen (Backups werden nachts gemacht). Aber ich wusste nicht, dass Discourse eine eigene Speicherprüfung durchführt – ich dachte, Sie bezögen sich auf den OOM-Killer. Kann ich die maximal zulässige Speichermenge für Sidekiq erhöhen?
Nachricht
Sidekiq verbraucht zu viel Speicher (verwendet: 547,87 MB) für ‘ip-172-26-9-xxx-app’, wird neu gestartet
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload’
Tatsächlich bezog ich mich auf den OOM-Killer. Ich habe komplett vergessen, dass es eine Speicherbegrenzung für Sidekiq gibt. Hat es geholfen, den Speicher für Sidekiq zu erhöhen?