Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert to using sidekiq-unique-jobs gem #927

Merged
merged 1 commit into from
May 23, 2017

Conversation

kevindew
Copy link
Member

We were previously using a fork of it for a bug fix.

I've given it a spin on integration and has been running without issues.

We were previously using a fork of it for a bug fix.
Copy link
Contributor

@thomasleese thomasleese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!

@kevindew kevindew merged commit 5274367 into master May 23, 2017
@kevindew kevindew deleted the use-sidekiq-unique-jobs-gem branch May 23, 2017 11:51
h-lame added a commit that referenced this pull request Mar 13, 2018
This reverts #927.  Sidekiq-unique-jobs 5.x requires redis 3.x but our
infrastructure uses 2.8.  We also have to use the fork rather than a
released version of 4.x because the last release of 4.x doesn't include
a fix for mhenrixon/sidekiq-unique-jobs#195
which means the `uniquejobs` hash key in redis never gets smaller.

Although there is a fix for this in 5.x (see:
https://github.com/mhenrixon/sidekiq-unique-jobs/pulls/200 - this
commit is what is on our fork of 4.x) it may have been changed to rely
on expiry features of redis 3.x that are not available in redis 2.x.

On staging this key is currently 6.5M entries, and consumes ~500Mb.
On production it's only 2.5M entries and consumes ~200Mb.
We're running a (much simplified version of) this script:
https://gist.github.com/riyad/9086d2b17ff1e8c091cdb1c7ac501b62
in a screen session to remove any expired keys from this hash.
h-lame added a commit that referenced this pull request Mar 13, 2018
This reverts #927.  Sidekiq-unique-jobs 5.x requires redis 3.x but our
infrastructure uses 2.8.  We also have to use the fork rather than a
released version of 4.x because the last release of 4.x doesn't include
a fix for mhenrixon/sidekiq-unique-jobs#195
which means the `uniquejobs` hash key in redis never gets smaller.

Although there is a fix for this in 5.x (see:
https://github.com/mhenrixon/sidekiq-unique-jobs/pulls/200 - this
commit is what is on our fork of 4.x) it may have been changed to rely
on expiry features of redis 3.x that are not available in redis 2.x.

On staging this key is currently 6.5M entries, and consumes ~500Mb.
On production it's only 2.5M entries and consumes ~200Mb.
We tried running a (much simplified version of) this script:
https://gist.github.com/riyad/9086d2b17ff1e8c091cdb1c7ac501b62
in a screen session to remove any expired keys from this hash, but
unfortunately the rate of adding keys to the uniquejobs hash was
greater than the rate of removal.  Instead we waited until the queue
was drained and deleted the key.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants