Question

Sidekiq有哪些可能的原因阻止处理队列中的作业？队列已满。日志文件sidekiq.log表示根本没有活动。因此队列已满，但日志为空，而Sidekiq似乎不处理项目。似乎没有工人处理工作。重新启动Redis或使用FLUSHALL或FLUSHDB将其刷新为无效。 Sidekiq已经开始了

捆绑exec sidekiq -L log / sidekiq.log

并生成以下日志文件：

2013-05-30..Booting Sidekiq 2.12.0 using redis://localhost:6379/0 with options {}
2013-05-30..Running in ruby 1.9.3p374 (2013-01-15 revision 38858) [i686-linux]
2013-05-30..See LICENSE and the LGPL-3.0 for licensing details.
2013-05-30..Starting processing, hit Ctrl-C to stop

你怎么知道出了什么问题？有没有隐藏的日志文件？

Answer 1

原因在于我们的情况：Sidekiq可能会查找错误的队列。默认情况下，Sidekiq使用名为“default”的队列。我们使用了两个不同的队列名称，并在config / sidekiq.yml

中定义了它们

# configuration file for Sidekiq
:queues:
  - queue_name_1
  - queue_name_2

问题是，默认情况下，您的开发环境中的配置文件不会自动加载（例如，不像database.yml或thinking_sphinx.yml）{{1}命令。因此，我们在两个特定队列中编写了作业，而Sidekiq正在等待第三个队列中的作业（默认值）。您必须通过bundle exec sidekiq或-C选项将路径作为参数传递给配置文件：

--config

或者您可以直接传递队列名称（逗号后面不允许使用空格）：

bundle exec sidekiq -C ./config/sidekiq.yml

要找出问题，在命令行中传递选项bundle exec sidekiq -q queue_name_1,queue_name_2或-v或在--verbose文件中使用:verbose: true会很有帮助。如果未加载配置文件，配置文件中定义的所有内容当然都是无用的。因此，请确保首先使用正确的配置文件。

Answer 2

如果您config/sidekiq.yml检查是否已在此处定义了所有队列，请检查以下示例文件：https://github.com/mperham/sidekiq/blob/master/examples/config.yml

如果要在命令行或Procfile中传递队列名称，则类似于

bin/sidekiq -q queue1 -q queue2
bundle exec sidekiq -q queue1 -q queue2

检查是否在那里定义了所有队列。

如果您不确定队列的名称，可以使用以下脚本来解决它：

require "sidekiq/api"
stats = Sidekiq::Stats.new
stats.queues
# {"production_mailers"=>25, "production_default"=>1}

然后，您可以使用队列执行操作：

queue = Sidekiq::Queue.new("production_mailers")
queue.count
queue.clear

Answer 3

我花了几个小时才发现自己设置了config.active_job.queue_name_prefix = "xxxxx_#{Rails.env}"。设置中的队列名称看起来相同，但是sidekiq查找带有前缀的队列。

设置错误

app/jobs/my_job.rb

class MyJob < ApplicationJob
  queue_as :default
end

config/sidekiq.yml

:queues:
  - default

正确的设置

app/jobs/my_job.rb

class MyJob < ApplicationJob
  queue_as :default
end

config/sidekiq.yml

:queues:
  - xxxxx_development_default
  - xxxxx_production_default

Answer 4

我刚遇到这个问题。事实证明我在sidekiq.yml

中出现了语法错误

Answer 5

刷新 redis 对我有用。在终端：

redis-cli flushall

Answer 6

就我而言，sidekiq在开发方面表现不错，但停留在阶段。 Capistrano的部署配置是人为错误。我在Capfile中错误地设置了sidekiq.yml的路径（共享而不是当前）。

它默默地失败了：

# Capfile

# WRONG:
set :sidekiq_config, -> { File.join(shared_path, 'config', 'sidekiq.yml') }
                                    ^^^^^^^^^^^
# RIGHT:
set :sidekiq_config, -> { File.join(current_path, 'config', 'sidekiq.yml') }

Answer 7

我的问题是我的初始化程序中有一个configure_server但没有configure_client，您必须同时拥有两个：

Sidekiq.configure_server do |config|
  config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end

Sidekiq.configure_client do |config|
  config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end

Answer 8

我的问题是我没有正确配置initializers/sidekiq.rb，但即使配置正确，sidekiq仍未运行入队作业。我必须首先运行spring stop，然后重新启动所有程序，它解决了我的问题。

Answer 9

我遇到了类似的问题，其中日志会显示诸如 INFO Rails : queueing TestWorker (TestWorker) 之类的条目。但是，作业永远不会得到处理，并且此问题中的所有答案都无法解决问题。

我的解决方案的 tl;dr 是 Sidekiq's Testing Client 被意外触发。

根据以下轶事，我最终推断出在表面之下存在一些“魔法”，这使得难以离散地确定上述测试触发器的配置位置/时间/方式...

运行 bundle exec sidekiq -C config/sidekiq.yml -e development 的结果是 Sidekiq::Testing.fake? == true

然而，运行 bundle exec sidekiq -C config/sidekiq.yml -e development_2 的结果是 Sidekiq::Testing.fake? == false

^ 这两个命令的唯一区别是我将 development 中的 sidekiq.yml 环境重命名为 development_2，即两个命令都在运行相同/等效的环境（至少，如果不是引擎盖下的这种愚蠢的“魔法”，大概会是相同的环境）。

我更新了 sidekiq.rb 以通过以下方式显式切换 Sidekiq::Testing：

sidekiq_testing_fake = false  # set this using env var, etc.
if sidekiq_testing_fake
  Sidekiq::Testing.fake!
elsif Sidekiq.constants.include?(:Testing)
  Sidekiq::Testing.disable!
end

Answer 10

我正在敲打砖墙一段时间，我的问题是sidekiq需要更新版本的redis-server。我跑了＆＃34;捆绑了exec sidekiq＆＃34;这揭示了错误。一旦我更新到更新版本的redis-server，就可以了。

Sidekiq没有处理队列

10 个答案:

设置错误

正确的设置