configuration reload

Maxim Dounin mdounin at mdounin.ru
Sun Nov 25 10:55:35 UTC 2012


Hello!

On Fri, Nov 23, 2012 at 05:53:53PM +0200, Anatoli Marinov wrote:

> *Hello colleagues,
> We have some troubles when nginx have to reload its configuration.
> *There is a*control panel and every user which has account may
> change its own settings. For example it may add new domain name or
> change other option. After that new config files are created and
> they are sent to the servers.
> When there is a new config file master process receives HUP signal
> and it loads this new configuration. After the configuration is
> loaded the master process starts new workers and waits for old
> workers to complete its responses with the end users.  Usually there
> are several slow connections and old workers can stay alive for a
> long time.
> If there are several new configs for small period of time the number
> of workers may become very high and servers' load also gets high
> values. In general this is not good for the service.

That's why it's generally not recommended to do automated 
configuration reloads.  If you do automated reloads - you have to 
implement some safeguards to prevent situation of too many worker 
processes shutting down by either preventing further reloads till 
some workers exit, or killing oldest shutting down workers if 
another reload is strictly required.

> Do you have any idea how this issue could be solved? Is there
> different way to set new config file without a proc*ess *of new
> workers creation?

Current nginx configuration reload code uses new worker processes 
to apply new configuration.  Reimplementing this with some other 
mechanism is certainly possible, but wouldn't be trivial (and I 
suspect might result in other problems).  I would recommend you to 
focus on dynamic configuration of aspects you want to be 
user-configurable without changing main nginx configuration.

-- 
Maxim Dounin
http://nginx.com/support.html

p.s. Please do not post html here, thank you.



More information about the nginx-devel mailing list