Possible memory leak?

[Anoop Alias]

limiting the server blocks may not be practical when each domain has a
different TLS config

unless we use lua modules provided in the openresty

Correct me if I am wrong



On Tue, Mar 12, 2019 at 8:09 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Mon, Mar 11, 2019 at 04:37:50PM -0400, wkbrad wrote:
>
> > I think I haven't been clear in what I'm seeing so let's start over.
> :)  I
> > set up a very simple test on Centos 7 with a default install of Nginx
> > 1.12.2.  Below is exactly what I did to produce the result and it's
> clear to
> > me that Nginx is using 2x the ram than it should be using after the first
> > reload.  Can anyone explain why the ram usage would double after doing a
> > config reload?
>
> As I already tried to explained earlier in this thread, this is a
> result of two things:
>
> 1) How nginx allocates memory when doing a configuration reload:
> it creates a new configuration first, and then frees the old one.
>
> 2) How system memory allocator works.  Usually it cannot return
> memory to the system if there are any remaining allocations above
> the freed memory regions.  In some cases you can configure system
> allocator to use mmap(), so it will be possible to free such
> allocations, but it may a be a bad idea for other reasons.
>
> As a result, if large amount of memory is used solely for the
> configuration structures, memory occupied by the nginx master
> process from the system point of view is roughly doubled after a
> configuration reload.
>
> Note that the memory in question is not leaked.  It is properly
> freed by nginx, and it is available for future allocations within
> nginx.  In worker processes, this memory will be used for various
> run-time allocations, such as request buffers and so on.  In the
> master process, this memory will be used on further configuration
> reloads, so the master process will not grow any further.
>
> If the amount of memory used for configuration structures is a
> problem, you may want to re-think your configuration approach.  In
> particular, large virtual hosting providers are known to use nginx
> with small number of server{} blocks serving many different
> domains.  Alternatively, you may want to build nginx with less
> modules compiled in, as each module usually allocates at least
> basic configuration structures in each server{} / location{} even
> if not used.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>


-- 
*Anoop P Alias*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190312/7674e792/attachment-0001.html>