Sidekiq si blocca (sul lavoro BotInput?)

Nell’ultima settimana abbiamo visto tre istanze di Sidekiq su forum diversi bloccarsi. Non stava succedendo nulla di particolare, semplicemente Sidekiq non stava elaborando alcun lavoro e mostrava 5 processi su 5.

Una cosa interessante che avevano tutte in comune era la presenza di un job critico BotInput tra i job in coda. Ora questo è un job abbastanza comune, ma comunque si distingue.

Dopo aver riavviato Sidekiq, tutto torna a funzionare normalmente. Mettere in coda manualmente un job con gli stessi parametri non causa più il blocco. Non c’è nulla di particolare nel post specifico per cui è stato chiamato.

Qualcuno ha qualche idea su come potremmo rintracciare cosa sta succedendo qui?

1 Mi Piace

Abbiamo anche avuto blocchi come questo e il nostro host non riesce a capire cosa li stia causando.

Hai uno screenshot di ciò che vedi nella dashboard?

Se puoi, prova a inviare al processo Sidekiq il segnale TTIN e fornisci qui il backtrace.

1 Mi Piace

Mi dispiace, ci è voluto un po’ prima che succedesse di nuovo.

sidekiq-clean.txt (35,8 KB)

Riepilogo dei log

[default] Thread TID-1ow77
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/cli.rb:199:in `backtrace'
--
[default] Thread TID-1o1jr
[default] /var/www/discourse/lib/demon/base.rb:234:in `sleep'
--
[default] Thread TID-1o1j7
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/connection/ruby.rb:57:in `wait_readable'
--
[default] Thread TID-1o1j3
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/timer_thread.rb:130:in `sleep'
--
[default] Thread TID-1o1ij AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1hj
[default] <internal:thread_sync>:18:in `pop'
--
[default] Thread TID-1o1gz AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1gv
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:18:in `sleep'
--
[default] Thread TID-1o1gb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:32:in `sleep'
--
[default] Thread TID-1otmb
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otkn
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otjz
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otif
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1othr
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1o1fb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:80:in `sleep'
--
[default] Thread TID-1o1er
[default] /var/www/discourse/lib/mini_scheduler_long_running_job_logger.rb:87:in `sleep'
--
[default] Thread TID-1o1en heartbeat
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/launcher.rb:76:in `sleep'
--
[default] Thread TID-1o1e3 scheduler
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/connection_pool-2.5.0/lib/connection_pool/timed_stack.rb:79:in `sleep'
--
[default] Thread TID-1ot4n processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot67 processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot8j processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot5n processor
[default] /usr/local/lib/ruby/3.3.0/bundled_gems.rb:74:in `require'
--
[default] Thread TID-1ot6b processor
[default] /var/www/discourse/lib/distributed_mutex.rb:5:in `<main>'
--
[default] Thread TID-1o0kn final-destination_resolver_thread
[default] <internal:thread_sync>:18:in `pop'
--
[default] Thread TID-1o0k3 Timeout stdlib thread
[default] <internal:thread_sync>:18:in `pop'

@tgxworld hai avuto modo di guardare il backtrace?

Ho avuto problemi con Sidekiq da quando è stato eseguito l’aggiornamento del forum un mese fa. Quale comando usi per riavviare Sidekiq? Solo un sv restart sidekiq?

Mi dispiace, non ho ancora avuto modo di dare un’occhiata. Cercherò di farlo questa settimana.

1 Mi Piace

Sto riscontrando questo problema negli ultimi giorni. Alla fine tutti i processi smettono di funzionare. In precedenza ho riavviato, ma è sicuro eliminare la coda critica? È una coda redis?

Sono aggiornato alla versione 3.5.0.beta1-dev.

Solo un’ipotesi, ma a volte quando sto chattando con il bot, questo smette di rispondere, quindi aggiorno la pagina o rinuncio. Forse quei casi lasciano un processo in sospeso?

1 Mi Piace

Questi lavori sono asincroni, quindi non saprebbero nemmeno che l’hai fatto.

È interessante sentire che stai riscontrando questo problema anche su Jobs::BotInput. Stiamo riscontrando questo problema solo su un piccolo sottoinsieme di tutti i nostri server (pochi percento) e sembra che siano le istanze che utilizzano il bot narrativo in modo piuttosto intensivo.

No, perderesti anche tutti gli altri lavori in coda.

Il modo più semplice e sicuro è sv reload unicorn dall’interno del container.

1 Mi Piace

Non è questo il caso del nostro forum. L’IA è visibile solo allo staff e ho confermato che nessuno dello staff la sta utilizzando.

Per ora ho disabilitato l’IA.

BotInput è un’attività del Discourse Narrative Bot (noto anche come Discobot), non del bot AI.

Ah. Sto usando pesantemente l’API, come il nome utente discobot.

Ho dato un’occhiata ai backtrace e tutto punta a qualche problema con la seguente riga:

Non sono sicuro del perché quella riga possa causare problemi, ma è una riga non necessaria, quindi l’ho rimossa in

@RGJ Hai per caso impostato Rails.application.config.eager_load su disabilitato per qualche motivo? :thinking:

2 Mi Piace

Interessante scoperta, grazie per aver indagato.
È difficile dire quando un problema così intermittente scompare. Ho rimosso quella riga nelle tre istanze che si bloccavano più spesso (una di esse quasi quotidianamente). Tornerò qui:

  • quando una di quelle istanze si bloccherà (sapremo allora che non ha funzionato)
  • venerdì se nessuna di esse si è bloccata (potremo allora iniziare a presumere che sia stata la soluzione)

No, non ho toccato quello.

Ma qualcuno lo ha fatto…

Rails.autoloaders.main.do_not_eager_load(config.root.join("lib"))

su Blaming discourse/config/application.rb at main · discourse/discourse · GitHub

3 Mi Piace

@loic Ti ricordi perché non carichiamo in anticipo la directory lib nemmeno in produzione?

1 Mi Piace

[quote=“Richard - Communiteq, post:16, topic:352661, username:RGJ”]
È difficile dire quando un problema così intermittente scompare. Ho rimosso quella riga nelle tre istanze che si bloccavano più spesso (una di esse quasi quotidianamente). Tornerò qui:\n\n* quando una di quelle istanze si blocca (allora sapremo che non ha funzionato)\n* venerdì se nessuna di esse si è bloccata (allora potremo iniziare a presumere che sia stata la soluzione)\n[/quote]

Mentre i problemi si sono verificati questa settimana, non si sono verificati nelle tre istanze in cui abbiamo rimosso quella riga require, quindi penso che possiamo tranquillamente presumere che questo sia il colpevole :tada: . Grazie per averlo notato @tgxworld , non l’avrei mai trovato.\n\nRiusciresti a eseguire il backport di quella correzione alla versione stabile?

1 Mi Piace

È correlato a quanto spiegato qui (quando siamo passati a Rails 7.1): Upgrading Ruby on Rails — Ruby on Rails Guides

Non ricordo il problema esatto, ma abbiamo mantenuto il comportamento precedente, dovendo includere le cose da lib.