Les sauvegardes vers S3 fonctionnent depuis plusieurs années. Depuis environ un mois, je reçois souvent plusieurs notifications indiquant que la sauvegarde a échoué. Ensuite, elle réessaie, et environ une heure plus tard, elle échoue à nouveau, ce qui me conduit à une seconde notification, et souvent jusqu’à six notifications en une journée avant qu’elle ne réussisse finalement.
Le journal de la notification indique qu’il échoue à télécharger le fichier tar compressé vers S3. Je ne peux pas trouver d’erreurs dans mon compte S3.
31;Détails30;
1;Résumé30;
La première partie du journal semble normale, puis :[2025-05-20 07:11:38] Finalisation de la sauvegarde…
[2025-05-20 07:11:38] Création de l’archive : 506-investor-group-2025-05-20-070428-v20250513161753.tar.gz
[2025-05-20 07:11:38] Vérification que l’archive n’existe pas déjà…
[2025-05-20 07:11:38] Création d’une archive vide…
[2025-05-20 07:11:38] Archivage de l’export de données…
[2025-05-20 07:12:17] Archivage des téléchargements…
[2025-05-20 07:15:48] Suppression du répertoire tmp ‘/var/www/discourse/tmp/backups/default/2025-05-20-070428’…
[2025-05-20 07:15:48] Compression de l’archive, cela peut prendre un certain temps…
[2025-05-20 07:32:51] Téléchargement de l’archive…
Pourriez-vous manquer de mémoire ? Cette exception me fait penser que Sidekiq (qui gère les sauvegardes automatiques) est soit arrêté par le système d’exploitation, soit planté pour une autre raison.
Avez-vous essayé de reconstruire le conteneur Docker (./launcher rebuild app) pour voir si cela résout le problème ?
Je ne pense pas. Le serveur est surdimensionné pour notre communauté avec 16 Go de RAM. top montre 11 Go de mémoire libre, et cela change à peine si je déclenche manuellement une sauvegarde.
Je vérifierai /var/log/syslog demain pour tout ce qui concerne la mémoire, kill ou OOM. (Je ne peux pas vérifier aujourd’hui car j’avais une journalisation détaillée sans rapport et l’événement de sauvegarde sort du tampon syslog.)
Oui, j’ai mis à jour vers la version 3.5.0.beta5-dev il y a quelques jours et le problème persiste.
Je l’ai dans /logs. Cet avertissement particulier ne coïncidait pas avec la sauvegarde - je vérifierai cela demain matin (les sauvegardes sont effectuées la nuit). Mais je ne savais pas que Discourse avait sa propre vérification de mémoire - je pensais que vous faisiez référence au tueur OOM. Puis-je augmenter la taille de mémoire autorisée pour Sidekiq ?
Message
Sidekiq consomme trop de mémoire (utilisé : 547.87M) pour ‘ip-172-26-9-xxx-app’, redémarrage
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’
En effet, je faisais référence au killer OOM. J’avais complètement oublié qu’il y a une limite de mémoire pour Sidekiq. Est-ce que l’augmentation de la mémoire pour Sidekiq a aidé ?