Sidekiq spinning out of control


(Sam Saffron) #1

I have seen this now on 2 instances (here on meta and on another site)

The symptoms are

  1. A very large number of jobs scheduled “now” in the scheduled tab in sidekiq
  2. A very rapid increase in executed jobs

What more when I try to use the API to clear it, it does not clear.

We are running Sidekiq 3.1.3, I notice we can upgrade, but as of Sidekiq 3.2 there is no support for Ruby 1.9, it will not even boot. This will officially make Discourse Ruby 2.0 and up.

I am not really sure what to do here, but we need to nail this bug somehow.


Topic list avatars are missing
(Erlend Sogge Heggen) #2

How is a flexible Ruby requirement still important when you’re relying on Docker for installs? Just curious.


(Sam Saffron) #3

I don’t really think the flexible Ruby requirement is that important anymore. I think we could give it up. Also, turns out Sidekiq 3.0+ does not officially support 1.9 so we have not officially supported 1.9 for a while now.

Dropping 1.9 support does feel a bit on the aggressive side, but I guess Mike had his reasons.


(Jeff Atwood) #4

We should upgrade to Sidekiq latest asap and see if that bug goes away. It is severe.


(Sam Saffron) #5

This is now fixed, not Sidekiqs bug, our bug.

Essentially we had a way to kick sidekiq into a “paused” state forever with zero feedback about it.

I fixed the root problem, if a process pausing sidekiq dies, sidekiq is unpaused.

https://github.com/discourse/discourse/commit/cb686792df7ea5c2c7001f7544a77c6895fe19ac


(Sam Saffron) #6