Sidekiq工作忙于postgres& rails 5

时间:2017-07-24 09:51:20

标签: ruby-on-rails postgresql azure sidekiq

我有一些"随机"工作在sidekiq繁忙的状态困住了几个小时(甚至几天)。我无法在我的本地开发环境中重现它,但在生产DB(天蓝色数据库服务)卡住了。

当我将TTIN发送到SQ时,我得到了这个:

2017-07-24T09:13:47.000Z [1]: Thread TID-qf9sw processor                                                                                           [1673/1844]
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `async_
exec'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `block 
in exec_no_cache'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:590:in `block in
 log'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activesupport-5.0.4/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:583:in `log'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `exec_n
o_cache'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/postgresql_adapter.rb:587:in `execut
e_and_clear'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:10
3:in `exec_query'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:373:
in `select'
2017-07-24T09:13:47.000Z [1]: /app/vendor/bundle/ruby/2.3.0/gems/activerecord-5.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:41:i
n `select_all'

我可以在PG中看到有很多空闲连接,但随着时间的推移它们会被使用,所以看起来像是正常的池行为。

手动运行#34;"立即运行所以似乎不是一个代码问题。我也在使用#with_connection但没有帮助。

我正在使用2个docker容器,一个运行rails服务器(puma),其他只运行sidekiq。

我尝试在database.yml中调整变量和reaper设置,但没有解决问题。

任何线索都会非常受欢迎。

2 个答案:

答案 0 :(得分:0)

工作是做什么的?他们是在db级别或其他方面创建死锁吗?在工作中放置某种调试日志将有助于您了解工作中的哪些内容会被卡住。 Sidekiq具有超时和唯一性设置(可能需要许可),这可能有助于管理问题但不能修复根。

答案 1 :(得分:0)

所以这是一个"未定义" Azure服务方面的问题,谢谢你的尝试!

相关问题