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