Sidekiq завис (на задаче BotInput?)

За последнюю неделю мы наблюдали три случая, когда инстансы Sidekiq на разных форумах зависали. Ничего необычного не происходило — просто Sidekiq перестал обрабатывать задачи, хотя отображал статус «5 из 5 задач в обработке».

Общим для всех трёх случаев было наличие одной критической задачи BotInput в очереди. Хотя такая задача встречается довольно часто, она всё же выделяется.

После перезапуска Sidekiq всё снова работало нормально. Ручное добавление задачи с теми же параметрами не приводило к повторному зависанию. В конкретном посте, для которого была вызвана задача, тоже ничего особенного не обнаружено.

Есть ли у кого-то идеи, как можно отследить причину происходящего?

У нас тоже бывают подобные зависания, и наш хост не может понять, что их вызывает.

Есть ли у вас скриншот того, что вы видите в панели управления?

Если возможно, пожалуйста, отправьте процессу Sidekiq сигнал TTIN и предоставьте здесь трассировку стека.

Извините, прошло некоторое время, прежде чем это произошло снова.

sidekiq-clean.txt (35.8 КБ)

Сводка логов

[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, у вас была возможность посмотреть на трассировку стека?

У меня возникли проблемы с Sidekiq после обновления форума месяц назад. Какую команду вы используете для перезапуска Sidekiq? Просто sv restart sidekiq?

Извините, у меня пока не было возможности посмотреть. Постараюсь заняться этим на этой неделе.

В последние несколько дней я наблюдаю это. В конечном итоге все задачи перестают выполняться. Ранее я перезагружал систему, но безопасно ли удалять критическую очередь? Это очередь Redis?

У меня установлена актуальная версия 3.5.0.beta1-dev.

Это лишь предположение, но иногда, когда я общаюсь с ботом, он перестает отвечать, и я либо обновляю страницу, либо сдаюсь. Возможно, в таких случаях задача зависает?

Эти задачи выполняются асинхронно, поэтому они даже не узнают о ваших действиях.

Интересно, что вы сталкиваетесь с этим и в Jobs::BotInput. Мы наблюдаем эту проблему только на небольшом подмножестве всех наших серверов (несколько процентов), и, похоже, это экземпляры, которые довольно интенсивно используют нарративный бот.

Нет, вы потеряете все остальные задачи в очереди.

Самый простой и безопасный способ — выполнить sv reload unicorn внутри контейнера.

У нас на форуме ситуация иная. ИИ виден только сотрудникам, и я подтвердил, что никто из них его не использует.

На данный момент я отключил ИИ.

«BotInput» — это задача от бота Discourse Narrative (также известного как Discobot), а не от ИИ-бота.

Ах. Я активно использую API под именем пользователя discobot.

Я посмотрел на трассировки стека, и всё указывает на проблему со следующей строкой:

Точно не уверен, почему именно эта строка вызывает проблемы, но она не является необходимой, поэтому я убрал её в:

@RGJ, случайно у вас не отключено Rails.application.config.eager_load по какой-то причине? :thinking:

Интересная находка, спасибо, что разобрались в этом.
Трудно сказать, когда пройдет такая периодическая проблема. Я убрал эту строку на трех экземплярах, которые чаще всего зависали (один из них почти ежедневно). Я вернусь сюда с обновлением либо:

  • когда один из этих экземпляров зависнет (тогда мы поймем, что это не помогло)
  • в пятницу, если ни один из них не зависнет (тогда мы сможем предположить, что это было решением)

Нет, я не трогал это.

Но кто-то другой…

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

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

@loic, помнишь ли ты, почему мы не загружаем директорию lib заранее даже в продакшене?

Хотя проблемы наблюдались на этой неделе, на трёх экземплярах, где мы удалили строку require, они не возникали. Поэтому я считаю, что можно с уверенностью утверждать, что именно это было причиной :tada:. Спасибо, что заметили это @tgxworld, я бы никогда сам этого не обнаружил.

Не могли бы вы перенести это исправление в стабильную версию?

Это связано с тем, что объясняется здесь (когда мы обновились до Rails 7.1): Upgrading Ruby on Rails — Ruby on Rails Guides

Я не помню точную проблему, но мы сохранили предыдущее поведение, требуя явно подключать модули из lib.