Sidekiqハングする (BotInput jobで？)

RGJ · 2025 年 2 月 17 日午前 8:21

過去1週間で、異なるフォーラムで3つのSidekiqインスタンスがハングしているのを確認しました。特に何も起こっていませんでしたが、Sidekiqは処理を行っておらず、5/5のジョブが処理中と表示されていました。

興味深いことに、それらすべてに共通していたのは、ジョブの中にクリティカルな BotInput ジョブが1つあったことです。これはかなり一般的なジョブですが、それでも際立っています。

Sidekiqを再起動すると、すべてが正常に機能します。同じパラメータを持つジョブを手動でキューイングしても、再びハングすることはありません。特定の投稿に特別なことはありませんでした。

この問題の原因を特定する方法について、何かアイデアはありますか？

Shauny · 2025 年 2 月 17 日午後 9:34

私たちも同様のハングアップが発生しており、ホストも原因を特定できていません。

tgxworld · 2025 年 2 月 18 日午前 1:30

ダッシュボードで何が表示されているかのスクリーンショットはありますか？

もし可能であれば、SidekiqプロセスにTTINシグナルを送信してみて、そのバックトレースをここに提供していただけますか？

RGJ · 2025 年 2 月 20 日午前 8:05

申し訳ありません、これが再び発生するまでにしばらく時間がかかりました。

sidekiq-clean.txt (35.8 KB)

ログの概要

[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] --
[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] --
[default] Thread TID-1o0k3 Timeout stdlib thread
[default] --

RGJ · 2025 年 3 月 3 日午前 7:57

@tgxworld バックトレースを確認する時間はありましたか？

Isambard · 2025 年 3 月 3 日午前 9:08

1か月前のフォーラムのアップグレード以降、Sidekiqに問題が発生しています。Sidekiqを再起動するには、どのコマンドを使用しますか？ sv restart sidekiqだけでよいのでしょうか？

tgxworld · 2025 年 3 月 5 日午前 1:17

すみません、まだ確認する時間がありませんでした。今週中に確認するようにします。

markschmucker · 2025 年 3 月 6 日午後 7:46

ここ数日、この状況が発生しています。最終的にはすべてのジョブが停止します。以前は再起動していましたが、クリティカルキューを削除しても安全ですか？Redisキューですか？

3.5.0.beta1-devまで最新の状態です。

ただの推測ですが、ボットとチャットしているときに応答しなくなり、ページをリロードしたり諦めたりすることがあります。これらのケースでジョブがハングしたままになるのでしょうか？

RGJ · 2025 年 3 月 6 日午後 8:21

これらのジョブは非同期なので、あなたがそれをしたことさえ知らないでしょう。

Jobs::BotInput でもこの問題が発生しているというのは興味深いです。この問題は、すべてのサーバーのごく一部（数パーセント）でのみ発生しており、特にナラティブボットをかなり頻繁に使用しているインスタンスで発生しているようです。

いいえ、他のすべてのキューに入れられたジョブも失うことになります。

最も簡単で安全な方法は、コンテナ内から sv reload unicorn を実行することです。

markschmucker · 2025 年 3 月 7 日午前 1:39

当社のフォーラムではそうではありません。AIはスタッフにのみ表示され、スタッフが使用していないことを確認しました。

現在AIを無効にしました。

RGJ · 2025 年 3 月 7 日午前 8:05

BotInput はAIボットではなく、Discourse Narrative Bot（Discobot）のジョブです。

markschmucker · 2025 年 3 月 7 日午前 10:45

Ah。私は、ユーザー名 discobot として API を多用してきました。

tgxworld · 2025 年 3 月 10 日午前 8:36

バックトレースを確認したところ、すべて以下の行の問題を指しています。

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

その行がなぜ問題を引き起こすのか正確にはわかりませんが、不要な行なので削除しました。

@RGJ Rails.application.config.eager_load が何らかの理由で無効に設定されていませんか？

RGJ · 2025 年 3 月 10 日午前 8:58

興味深い発見ですね。調べていただきありがとうございます。
このような断続的な問題がいつ解決したのかを判断するのは難しいです。最も頻繁にハングアップしていた3つのインスタンス（そのうちの1つはほぼ毎日）から、その行を削除しました。ここに再度確認に来ます。

それらのインスタンスのいずれかがハングアップした場合（その場合は、これが効果がなかったことがわかります）
金曜日に、それらのいずれもハングアップしなかった場合（その場合は、これが解決策であったと仮定し始めることができます）

いいえ、いじっていません。

しかし、誰かがいじりました…

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

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

tgxworld · 2025 年 3 月 14 日午前 1:11

@loic 本番環境でも lib ディレクトリを eager load しない理由を覚えていますか？

RGJ · 2025 年 3 月 14 日午前 8:30

今週、問題が発生していましたが、その require 行を削除した3つのインスタンスでは発生していなかったので、これが原因であると安全に仮定できると思います。 @tgxworld 、それに気づいてくれてありがとう。私は決してそれを見つけることができなかったでしょう。

その修正を安定版にバックポートしていただけますか？

loic · 2025 年 3 月 14 日午前 8:50

これは、(Rails 7.1 にアップグレードした際の) ここで説明されていることに関連しています: Upgrading Ruby on Rails — Ruby on Rails Guides

正確な問題は覚えていませんが、実際には以前の動作を維持し、lib からものを require する必要がありました。

トピック		返信	表示
Sidekiq has a lot of errors and queued jobs Support	19	1090	2024 年 3 月 1 日
Sidekiq is being paused, how can I discover why? Support	18	3165	2018 年 9 月 20 日
"Ensure sidekiq is running." when it is definitely running Installation	19	7755	2015 年 10 月 24 日
Sidekiq stops after some time Installation	8	1127	2023 年 7 月 14 日
Could sidekiq queue be reason for 500 errors? Installation server-resources	31	3857	2018 年 7 月 13 日

Sidekiqハングする (BotInput jobで？)

関連トピック