You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 1, 2023. It is now read-only.
I recently ran some diagnostics against my Sidekiq instance using RedisInsight and was shocked to see I had >1GB of data for the sidekiq:status:* keyspace. This is 10x larger than any other keyspace in my Redis database. Worth noting that I process ~1MM jobs a day that utilize sidekiq-status, and I have a status expiry of 3 days.
Upon inspection, the large keyspace was because this lib is storing the job's args for display purposes. In my case, this included potentially large JSON payloads.
I actually don't use the UI for Sidekiq, so this was needlessly wasting space and I feel like an option to disable this behavior would be beneficial for situations like this.
For now, I implemented the following monkey-patch in an initializer:
I recently ran some diagnostics against my Sidekiq instance using RedisInsight and was shocked to see I had >1GB of data for the
sidekiq:status:*keyspace. This is 10x larger than any other keyspace in my Redis database. Worth noting that I process ~1MM jobs a day that utilize sidekiq-status, and I have a status expiry of 3 days.Upon inspection, the large keyspace was because this lib is storing the job's args for display purposes. In my case, this included potentially large JSON payloads.
I actually don't use the UI for Sidekiq, so this was needlessly wasting space and I feel like an option to disable this behavior would be beneficial for situations like this.
For now, I implemented the following monkey-patch in an initializer:
Thoughts?