ionathan at gmail.com
Tue May 3 05:02:21 MSD 2011
Thanks! I will check it again. In general my nginx instances have very
low cpu and memory usage, way beneath 50%, probably around 10% or even
And request in our app are avg 200 or 300 ms, so no long running requests.
We are serving around 15k req/s on 5 nginx instances
(instance=machine), so maybe we have something wrong in the conf or
Anyway, now I understand how it works, so it shouldn't affect anything.
On 5/2/11, Maxim Dounin <mdounin at mdounin.ru> wrote:
> On Mon, May 02, 2011 at 07:00:18PM -0300, Jonathan Leibiusky wrote:
>> Hi! How reloading my conf can affect my running nginx instances that are
>> under load?
> While reloading nginx master process parses new configuration,
> starts new worker processes and instructs old worker processes to
> gracefully terminate (i.e. finish processing of all requests and
> then exit).
> This shouldn't affect anything but may require additional
> resources (mostly memory). If you don't have enough memory reload
> may be problematic operation, and it's generally good idea to make
> sure your running nginx doesn't consume more than half of your
> server memory under normal load (to make sure it will be possible
> to start additional worker processes on reload).
>> Just made a small test and I saw that some requests to the upstream are
>> being lost. I am reloading the same configuration I had, didn't change
> It's strange you see something being lost. Are you sure you
> actually did reload (i.e. sent SIGHUP to nginx master process)?
>> Is there any best practice on how to do it? how often? if I should avoid
>> something in particular? etc...
> General practice is to reload config when you've changed it.
> If you are doing reloads often - you may want to make sure
> previous reload was completed (i.e. old workers terminated) before
> doing another one (there is nothing fatal if it's not, but see
> above about resources). Please note that with some use cases
> (long-running requests, downloads and so on) reload may take
> several hours or even more.
> Maxim Dounin
> nginx mailing list
> nginx at nginx.org
More information about the nginx