I backup su S3 funzionano da diversi anni. A partire da un mese fa, ricevo spesso diverse notifiche di fallimento del backup. Poi riprova e, circa un’ora dopo, fallisce di nuovo, quindi ricevo una seconda notifica, e spesso fino a sei notifiche in un giorno prima che infine abbia successo.
Il log della notifica dice che si sta tentando di caricare il file tar compresso su S3. Non riesco a trovare errori nel mio account S3.
dettagli0
sommario0
Il primo pezzo del log sembra normale, poi:
[2025-05-20 07:11:38] Finalizzazione del backup…
[2025-05-20 07:11:38] Creazione dell’archivio: 506-investor-group-2025-05-20-070428-v20250513161753.tar.gz
[2025-05-20 07:11:38] Verifica che l’archivio non esista già…
[2025-05-20 07:11:38] Creazione di un archivio vuoto…
[2025-05-20 07:11:38] Archiviazione del dump dei dati…
[2025-05-20 07:12:17] Archiviazione degli upload…
[2025-05-20 07:15:48] Rimozione della directory tmp ‘/var/www/discourse/tmp/backups/default/2025-05-20-070428’…
[2025-05-20 07:15:48] Compressione dell’archivio, potrebbe richiedere del tempo…
[2025-05-20 07:32:51] Caricamento dell’archivio…
Potrebbe esaurire la memoria? Quell’eccezione mi fa pensare che Sidekiq (che esegue i backup automatici) venga terminato dal sistema operativo o si arresti in modo anomalo per qualche altro motivo.
Hai provato a ricostruire il container Docker (./launcher rebuild app) per vedere se risolve il problema?
Non credo. Il server è sovradimensionato per la nostra community con 16 GB di RAM. top mostra 11 GB di memoria libera e questa difficilmente cambia se attivo manualmente un backup.
Controllerò /var/log/syslog domani per eventuali informazioni su memoria, kill o OOM. (Non posso controllare oggi perché ho avuto dei log non correlati e l’evento di backup scorre fuori dal buffer di syslog.)
Sì, sono passato a 3.5.0.beta5-dev qualche giorno fa e il problema persiste.
Ho questo in /logs. Questo particolare avviso non ha coinciso con il backup, controllerò domattina (i backup vengono eseguiti di notte). Ma non mi ero reso conto che Discourse avesse un suo controllo della memoria, pensavo ti riferissi all’OOM killer. Posso aumentare la dimensione della memoria consentita per Sidekiq?
Messaggio
Sidekiq sta consumando troppa memoria (utilizzando: 547.87M) per ‘ip-172-26-9-xxx-app’, riavvio
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’
Infatti, mi riferivo all’oom killer. Mi ero completamente scordato che c’è un limite di memoria per Sidekiq. L’aumento della memoria per Sidekiq ha aiutato?