Sidekiq trava (na tarefa BotInput?)

RGJ · Fevereiro 17, 2025, 8:21am

Na última semana, vimos três instâncias do Sidekiq em diferentes fóruns travadas. Não havia nada de especial acontecendo, era apenas que o Sidekiq não estava processando nenhum trabalho e mostrava 5 de 5 trabalhos sendo processados.

Uma coisa interessante que todos tinham em comum era que havia um trabalho crítico BotInput entre os trabalhos. Agora, este é um trabalho bastante comum, mas ainda se destaca.

Após reiniciar o Sidekiq, tudo volta a funcionar normalmente. Enfileirar manualmente um trabalho com os mesmos parâmetros não faz com que ele trave novamente. Não há nada de especial com a postagem específica para a qual foi chamado.

Alguém tem alguma ideia de como podemos rastrear o que está acontecendo aqui?

Shauny · Fevereiro 17, 2025, 9:34pm

Nós também estamos tendo travamentos como este, e nosso host não consegue descobrir o que está causando isso.

tgxworld · Fevereiro 18, 2025, 1:30am

Você tem uma captura de tela do que está vendo no painel?

Se puder, tente enviar ao processo Sidekiq o sinal TTIN e forneça o backtrace aqui.

RGJ · Fevereiro 20, 2025, 8:05am

Desculpe, demorou um pouco para isso acontecer novamente.

sidekiq-clean.txt (35,8 KB)

Resumo dos logs

[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'

RGJ · Março 3, 2025, 7:57am

@tgxworld você teve a chance de olhar o backtrace?

Isambard · Março 3, 2025, 9:08am

Tenho tido problemas com o Sidekiq desde uma atualização de fórum há um mês. Qual comando você usa para reiniciar o Sidekiq? Apenas um sv restart sidekiq?

tgxworld · Março 5, 2025, 1:17am

Desculpe, ainda não tive a chance de dar uma olhada. Tentarei resolver isso esta semana.

markschmucker · Março 6, 2025, 7:46pm

Tenho visto isso nos últimos dias. Eventualmente, todos os trabalhos param de rodar. Anteriormente, eu reiniciava, mas é seguro excluir a fila crítica? É uma fila do redis?

Estou atualizado em 3.5.0.beta1-dev.

Apenas um palpite, mas às vezes, quando estou conversando com o bot, ele para de responder, então eu atualizo a página ou desisto. Talvez esses casos deixem um trabalho pendente?

RGJ · Março 6, 2025, 8:21pm

Esses trabalhos são assíncronos, então eles nem saberiam que você fez isso.

É interessante saber que você está tendo isso também em Jobs::BotInput. Estamos vendo esse problema em apenas um pequeno subconjunto de todos os nossos servidores (alguns por cento) e parece ser nas instâncias que usam o bot narrativo com bastante intensidade.

Não, você perderia todos os outros trabalhos enfileirados também.

A maneira mais fácil e segura é sv reload unicorn de dentro do contêiner.

markschmucker · Março 7, 2025, 1:39am

Não é o caso do nosso fórum. A IA é visível apenas para a equipe e confirmei que nenhum membro da equipe a está usando.

Desativei a IA por enquanto.

RGJ · Março 7, 2025, 8:05am

BotInput é uma tarefa do Discourse Narrative Bot (também conhecido como Discobot), não do bot de IA.

markschmucker · Março 7, 2025, 10:45am

Ah. Tenho usado a API intensamente, como o nome de usuário discobot.

tgxworld · Março 10, 2025, 8:36am

Eu dei uma olhada nos backtraces e tudo aponta para algum problema com a seguinte linha:

github.com/discourse/discourse

plugins/discourse-narrative-bot/lib/discourse_narrative_bot/new_user_narrative.rb

85e525a8d

# frozen_string_literal: true

require "distributed_mutex"

module DiscourseNarrativeBot
  class NewUserNarrative < Base
    I18N_KEY = "discourse_narrative_bot.new_user_narrative".freeze
    BADGE_NAME = "Certified".freeze

    TRANSITION_TABLE = {
      begin: {
        init: {
          next_state: :tutorial_bookmark,
          next_instructions:
            Proc.new { I18n.t("#{I18N_KEY}.bookmark.instructions", base_uri: Discourse.base_path) },
          action: :say_hello,
        },
      },
      tutorial_bookmark: {
        next_state: :tutorial_onebox,

This file has been truncated. show original

Não tenho certeza por que essa linha causaria problemas, mas é uma linha que não é necessária, então eu a removi em

@RGJ Você por acaso tem Rails.application.config.eager_load definido como desativado por algum motivo?

RGJ · Março 10, 2025, 8:58am

Achado interessante, obrigado por investigar.
É difícil dizer quando um problema intermitente como esse desaparece. Removi essa linha nas três instâncias que travaram com mais frequência (uma delas quase diariamente). Voltarei aqui:

quando uma dessas instâncias travar (então saberemos que isso não resolveu)
na sexta-feira se nenhuma delas travar (então poderemos começar a supor que foi a solução)

Não, não mexi nisso.

Mas alguém mexeu…

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

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

tgxworld · Março 14, 2025, 1:11am

@loic Você se lembra por que não fazemos o carregamento antecipado do diretório lib mesmo em produção?

RGJ · Março 14, 2025, 8:30am

Embora os problemas tenham ocorrido esta semana, eles não aconteceram nas três instâncias onde removemos essa linha require, então acho que podemos assumir com segurança que este é o culpado . Obrigado por identificar isso @tgxworld, eu nunca teria encontrado isso.

Você seria capaz de fazer o backport dessa correção para a versão estável?

loic · Março 14, 2025, 8:50am

Está relacionado ao que é explicado aqui (quando atualizamos para o Rails 7.1): Upgrading Ruby on Rails — Ruby on Rails Guides

Não me lembro do problema exato, mas na verdade mantivemos o comportamento anterior, tendo que incluir coisas de lib.

Tópico		Respostas	Visualizações
Sidekiq has a lot of errors and queued jobs Support	19	1090	1 de Março de 2024
Sidekiq is being paused, how can I discover why? Support	18	3165	20 de Setembro de 2018
"Ensure sidekiq is running." when it is definitely running Installation	19	7755	24 de Outubro de 2015
Sidekiq stops after some time Installation	8	1127	14 de Julho de 2023
Could sidekiq queue be reason for 500 errors? Installation server-resources	31	3857	13 de Julho de 2018

Sidekiq trava (na tarefa BotInput?)

Tópicos relacionados