Sidekiq is not releasing the memory after finishing the job - ruby-on-rails

Question

I am facing some strange issue with Sidekiq, I have a few heavy jobs running in the background with Sidekiq. but even after Sidekiq finished the job it's still holding the memory. what could be the reason?
Versions
ruby : 2.2.4
rails : 4.2.7
sidekiq : 3.5.4
I have attached the memory log also.
Even I haved check the link but it couldn't help. I have even manually started the GC also.

Answer 1

My understanding is that Ruby MRI will not release memory back to the OS. If your Sidekiq job consumes a lot of memory, even if those objects are garbage collected, the memory will just be released back to Ruby, not back to the OS. You should try to find a way to make your Sidekiq job(s) consume less memory, and assume that your workers will eventually allocate the maximum amount of memory that your most memory-consuming job requires.

Answer 2

Hi we were also facing the same problem. I researched about it a lot. Jim said it right. It's Ruby MRI which is handling the resources. Actually your sidekiq workers are heavy or they're performing heavy operations and I guess it's making more object allocations as well. They more the resources it needs ruby takes the resources from the OS and then use it for the operations being performed in sidekiq. It doesn't release memory to the OS. It uses the same memory space and reuses it to provide resources to other objects.
The things you have to keep in mind to stay out of this problem is to optimise your code.
If you're performing multiple heavy operations and they can be divided then use separate workers for that.
You can run your fetch query in batches to decrease the load on the server.
Use array operations whenever they're necessary.
you can run GC.start to force run Garbage collector after the end of your job to release the memory as well.
when you kill a sidekiq process it releases the memory to OS because process is being run by ruby and you killed it so in the end ruby will release memory to the OS.
I hope this helps.
You'll have to optimise your code and this is the same suggestion which is given by mperham.

Answer 3

People above have already delineated the problem - MRI will not release the memory that Sidekiq allocated after a huge job is completed, and also a possible solution - run GC.start manually after you finish your job.
There are scenarios where you might have a big job that's split into smaller ones and that stills generates a lot of memory. I will kindly suggest an approach here:
The SmallerJobs have a way to understand whether their counterparts have finished - maybe a flag on your Cache Engine** of choice:
class BigJob
def perform(record_ids)
Rails.cache.write("big_job/in_progress", record_ids)
record_ids.map { SmallerJob.perform_later(_1) }
end
end
class SmallerJob
def perform(record_id)
jobs_in_progress = Rails.cache.read("big_job/in_progress/")
# perform you action against the record
jobs_in_progress -= [ record_id ]
Rails.cache.write("big_job/in_progress/", jobs_in_progress)
ForceGCJob.perform_later if jobs_in_progress.empty?
end
end
After you're done, you queue a ForceGCJob, which as the name says, simply does this:
def perform
logger.debug(GC.stats) # if you're curious
GC.start
end
** concurrent writes to the cache might not be Serializable and you might lose removing some of them due to race conditions, this is just a simple example. In one scenario, I have a Database column for each record, which guarantees these operations are ACID