新手问题 Sidekiq limit fetch 一个问题

leijun · 2020年06月03日 · 最后由 leijun 回复于 2020年06月05日 · 2886 次阅读

大家好,我又过来问问题了。现在我公司碰到了一个奇怪的问题,一个 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:

  1. 确定是否有 worker 还在工作?就是 sidekiq web 后台的 执行中 的 tab 里面,有没有活跃的 sidekiq(对于没有设置 limit 的 queue 是否还在正常消耗)。如果有就先排除 sidekiq 进程本身有问题。
  2. 如果排除 sidekiq 进程本身有问题,那就缩小问题范围到 limit fetch 这个 gem 的功能。首先你去了解一下这个做 gem 做 limit 大概原理 (我大概看了一下,貌似也是依赖 redis 来做控制,不过不一定对,我没仔细看)。大概了解原理了,就去利用 gem 实现了的一些帮助 debug 的 api(例如这些)
  3. 然后就是些猜测加验证了的体力活了

而且如果你们用了 auto-scale 的话,要看一下减少机器的时候,是怎么通知进程关闭的。

如果是暴力的关闭进程,那有可能造成数据状态不对。假设 limit 确实是基于 redis 记录当前有多少几个任务同时再跑,那么如果暴力关闭的话,就会造成 redis 数据状态和实际状态对不上,也就可能 block queue 了

redemption 回复

谢谢回答, 目前观察,这里的 auto scaling 策略是 redis 不动,另外再 launch 一个一摸一样的 worker, 很可能多个一样的 worker 互相踩了,造成 redis 里面的 deadlock ... 我再做做体力活,进行测试去了。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号