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	1227	1 de Março de 2024
Sidekiq is being paused, how can I discover why? Support	18	3214	20 de Setembro de 2018
"Ensure sidekiq is running." when it is definitely running Self-hosting	19	7857	24 de Outubro de 2015
Sidekiq stops after some time Self-hosting	8	1178	14 de Julho de 2023
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	31	3994	13 de Julho de 2018

Sidekiq trava (na tarefa BotInput?)

Tópicos relacionados