大家好，我又过来问问题了。现在我公司碰到了一个奇怪的问题，一个 sidekiq queue 动不了了。 目前我们使用 gem 'sidekiq-limit_fetch' 对一个外部 API 访问，我们设置了 limit 比如 :limits: my_queue: 1 因为这个外部 API 要一个接一个访问，不能 simultaneously.
以前我们在本地还有 heroku 的时候没有问题，这个 queue 不会动不了，现在我们移到了 IBM cloud, 经常出现这种 queue 动不了的情况， 如果出现这种情况的时候，我们可以手动把 limit my_queue: 调到 2 或者更高，然后才可以通过。
主要是在本地完全不能重现这一情况，我都不知道哪里出错了。 目前有一条线索也不知道对不对，就是 IBM cloud 使用 auto scaling, 就是会自动重启 sidekiq, 不知道这是不是一条正确的线索呢？ 还有现在该如何 debug, 疯狂在所以可能的地方打上 log ? 对了 IBM CLOUD 我们开发人员没有权限，所以我们看不了 terminal log, 也看不了储存在服务器上的 log 文件，这样的化，对我们好使的看 log 的方法是把 log 全部放到 active_admin 上吗？
先感谢看完我问题的大家们。
一个 sidekiq queue 动不了了
是指设置了 limit 的 queue 动不了了？
这种问题的话，大家都没有你的环境可以重现，所以只能给你个思路自己 debug:
- 确定是否有 worker 还在工作？就是 sidekiq web 后台的 执行中 的 tab 里面，有没有活跃的 sidekiq（对于没有设置 limit 的 queue 是否还在正常消耗）。如果有就先排除 sidekiq 进程本身有问题。
- 如果排除 sidekiq 进程本身有问题，那就缩小问题范围到 limit fetch 这个 gem 的功能。首先你去了解一下这个做 gem 做 limit 大概原理 (我大概看了一下，貌似也是依赖 redis 来做控制，不过不一定对，我没仔细看)。大概了解原理了，就去利用 gem 实现了的一些帮助 debug 的 api(例如这些)。
- 然后就是些猜测加验证了的体力活了
而且如果你们用了 auto-scale 的话，要看一下减少机器的时候，是怎么通知进程关闭的。
如果是暴力的关闭进程，那有可能造成数据状态不对。假设 limit 确实是基于 redis 记录当前有多少几个任务同时再跑，那么如果暴力关闭的话，就会造成 redis 数据状态和实际状态对不上，也就可能 block queue 了
redemption
回复
谢谢回答， 目前观察，这里的 auto scaling 策略是 redis 不动，另外再 launch 一个一摸一样的 worker, 很可能多个一样的 worker 互相踩了，造成 redis 里面的 deadlock ... 我再做做体力活，进行测试去了。