redis-rb: Memory leak going from 3.2.2 to 3.3.0
Our app uses sidekiq ent (latest version) with the redis-rb driver. It also access redis directly using redis-rb to do stuff using redis as a datastore.
After updating gems last week, I saw the active memory on the rails server increase quickly and eventually kill the box.
See attached: the section before the big dip (redeploy) is what happens with redis 3.3.0, where the green [active memory] line eventually maxes out and crashes the server. The section after the redeploy is what happens with redis 3.2.2. The 3.2.2 ‘active memory’ line tends to level out over time roughly at the level where I’ve taken this screenshot.

Here’s another screenshot that shows the different a bit more clearly. Here, the sections up to a redeploy early on 22/4 are ‘normal’ with active memory sitting reasonably well around 1.17GB. Then after the update to redis-rb you can see the green ‘active memory’ line climbs and climbs quickly, until catastrophic failure when the kernel kills the process and the cycle continues.

I think this is due to the work that sidekiq does in polling work queues in the background, because once I’d disabled most of our sidekiq workers from doing any work by doing return from their perform methods, the memory-chomping continued. So I think this effect may be visible with sidekiq just polling in the background etc. We use sidekiq-ent’s unique jobs functionality which also polls redis in the background.
I’m not sure how to help debug this but want to raise it because it’s probably an important issue unless I’m doing something really weird in my app (which is entirely possible).
Downgrading to 3.2.2 does definitely fix the issue with no other changes (I’m watching the graphs now: they look completely normal again.)
Are you aware of any changes that may have introduced a problem like this? Can I help you debug it?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 6
- Comments: 25 (11 by maintainers)
@fertobar If you use hiredis-rb you should be fine. I’m gonna pull in the required changes for the pure-ruby connector this week.
This is lying around for far too long already 😕
I don’t have benchmarks at hand, but yeah, performance is the one reason you might want to use hiredis. We now know the reason of the leak in the ruby connector in v3.3.0 though and will release a fix ASAP.
Version 3.3.1 resolves the issue, thanks!
v 3.3.0:
v 3.3.1:
If someone can confirm this, it would be appreciated. If anything else comes up please report back, until then I’m gonna close this ticket.
that confirms my suspicion. I ran a very tiny script through memory_profile: gist. Seems like we’re allocating quite some
Timeoutinstances. A run withhiredisshows no bigger memory usage.If possible, can either of you run with hiredis?
gem install hiredis, then pass:driver => :hiredistoRedis.new.@kamen-hursev, @smeyfroi: Are you using redis-rb in combination with hiredis-rb or without?