Optimizing Sidekiq

I just kick off the application with a bash script for both dev and prod and push it through supervisor. (Remember to set `stopasgroup` to true, though, or else you can easily orphan processes and you will be sad.)

I've always just done `bundle exec sidekiqctl stop tmp/blah_worker.pid` at deploy-time, and then let the process monitoring system bring them back up. It works fine. I've never had a problem with orphans in production, but our apps dont rely on sidekiq for their core functionality.

Leaking is the wrong word. A leak implies that the memory was retained, RAM usage will go up forever and the process will eventually crash as a result. This is memory that sidekiq needs to do it's job, allocating strings, hashes, arrays etc. that will all be cleaned up eventually. Larger, more complex objects take up more memory. I.e. strings take up less memory than a hash. What he has done is eliminate the need to allocate so many large objects. This means less GC is needed, and overall performance is increased.

See http://www.schneems.com/2015/05/11/how-ruby-uses-memory.html for more info.