HTTPS clone URL
Subversion checkout URL
- Active Job
- Advanced Options
- Best Practices
- Commercial collaboration
- Commercial FAQ
- Commercial Support
- Complex Job Workflows with Batches
- Delayed extensions
- Deploying to Ubuntu
- Ent Leader Election
- Ent Periodic Jobs
- Ent Rate Limiting
- Ent Unique Jobs
- Error Handling
- Expiring Jobs
- Getting Started
- Job Control
- Job Format
- Pro API
- Problems and Troubleshooting
- Related Projects
- Resque Compatibility
- Scheduled Jobs
- The Basics
- UI Filtering
- Using Redis
Clone this wiki locally
I recommend running 1 or more Sidekiqs per app server in your production cluster. At The Clymb, we run two Sidekiqs on each of our three app servers, for six total processes. With default concurrency of 25, this gives us 150 worker threads. All six processes talk to the same master Redis server and we use
low queues to keep things as simple as possible.
Running separate machines for Sidekiq or using many different queues adds complexity where it is not needed for us.
To safely shut down Sidekiq, you need to send it the USR1 signal as early as possible in your deploy process and the TERM signal as late as possible. USR1 tells Sidekiq to stop pulling new work and finish all current work. TERM tells Sidekiq to exit within N seconds, where N is set by the
-t timeout option and defaults to 8. Using USR1+TERM in your deploy process gives your jobs the maximum amount of time to finish before exiting.
capistrano-sidekiq gem (github). Integrated support has been removed.
Using sidekiq with Heroku is simple, you need to use the (default) Cedar stack and add a
Procfile to your Rails app to start a sidekiq worker process:
web: bundle exec unicorn ... worker: bundle exec sidekiq ...
Before version 3.0 Sidekiq will automatically configure itself to use Redis-to-Go so you don't need to customize the Redis server location.
Starting from 3.0 version the built-in support for Redis-to-Go is removed, you'll need to set
heroku config:set REDIS_PROVIDER=REDISTOGO_URL env variable for it to work.
Keep in mind that Heroku puts a hard limit of 10 seconds on a process restart and you cannot send a USR1 signal so restarting Sidekiq gracefully when running long running jobs is tough. Sidekiq will push the unfinished jobs back to Redis; make sure your jobs are idempotent so it can restart them when the process starts back up.
See this page for more details about Procfiles, Foreman and Heroku.
I strongly recommend people not to use the
-d flag but instead use a process supervisor like
upstart to manage Sidekiq (or any other server daemon). This ensures Sidekiq will immediately restart if it crashes for some reason.
I've included the Upstart config The Clymb uses to manage our Sidekiq instances on our app servers. These files go in
/etc/init and will automatically startup Sidekiq when the machine is booted. The Sidekiq process group can be very simply managed with
[start | stop | restart] workers.
Sidekiq fires process lifecycle events when starting up and shutting down:
Sidekiq.configure_server do |config| # runs after your app has finished initializing but before any jobs are dispatched. config.on(:startup) do make_some_singleton end # runs once all jobs are terminated and threads are shut down config.on(:shutdown) do stop_the_world end end