Musings of a remote software developer…

Monthly Archives: August 2015

I have been working a lot with somewhat large datasets (millions of records) that benefits from parallel processing. I thought sidekiq’s multi-threading was going to be a great solution for this, but upon further investigation, I noticed my work was only marginally faster and that my CPU wasn’t ever at 100%. In fact, it was hovering more around 25%… what gives? Maybe my jobs are IO bound? Nope, that wasn’t the case… $ top showed wait cpu time to be 0.0.. The CPU wasn’t waiting for more IO! What could be the issue?

Global Interpreter Lock (GIL) Sadness

On further research, I learned that all MRI ruby threads run one at a time, even on a multi-core system! This is to protect from non-thread safe functions. Implementations of JRuby and Rubinius have threads that can run in parallel, but I didn’t have a chance to try them. Reading this toptal article was very informative for me to understand the difference between ruby concurrency and parallelism. (Sorry for referencing parallel wrong in previous blogs!)

Solution For Maxing Out CPU in Sidekiq

So the only way to max out cpu utilization with sidekiq is to use more processes. All you have to do is spawn up more sidekiq workers with the same configuration file and they will just be added to the pool of workers. Neat and simple! You have to note that more worker processes mean more memory. While worker threads can share memory, worker processes will not and if you spawn too many processes, you’ll run out of memory quickly. Also, in general, it is better to only spawn as many workers as you have logical CPUs.

I wrote a quick script to manage starting/stopping sidekiq workers. Feel free to use it too if you’d like:

Clearly, using more processes is faster than just more worker threads. Just make sure you have enough memory! For my test run, I could only divide up my work into 16 jobs, so I couldn’t test with more processes… but I think at a certain point, adding more processes would not help make the job run any faster and would probably start slowing down the system with overhead. I recommend running benchmarks on a small subset of your data to determine what the right balance would be before processing the whole thing! You can save a lot of time if you can make a 20 hour job turn into a 2 hour job.

I would love to see how multi-threaded processes work with rubinius. It’s been pretty fun learning about concurrency and parallel computing in ruby context.