zero downtime deploys

Eric Wong normalperson at
Fri Nov 13 18:12:31 EST 2009

Suraj Kurapati <sunaku at> wrote:
> Hello,
> I tried using preload_app with the "zero downtime deploys" trick of
> sending SIGQUIT to the old master in before_fork(), as described in:
> This significantly reduced, but did not eliminate, the transition time
> when the new workers take over (step #2 below):
> 1. old master (and its workers) is killed in before_fork()
> 2. workers re-establish DB connections in after_fork()
> 3. workers are ready to work, at the bottom of after_fork()
> Why do we kill the old master in before_fork() when the new workers
> are really ready to work much later?  Shouldn't we kill the old master
> at the *bottom* of after_fork() --- when the new workers are really
> ready to work?

Hi Suraj,

It depends on your setup, mainly memory constraints.  I know some
deployments run very close to the memory limit of the box and those
examples are geared for that.  We should clarify that in the
documentation.  I also know some setups that always startup with
worker_processes=1 and then SIGTTIN through an external script

Obviously I would always try to avoid maintenance during peak traffic
because performance inevitably suffers somewhat (and human error is
always possible :)

Eric Wong

More information about the mongrel-unicorn mailing list