Hello! On Thu, Mar 21, 2019 at 11:29:04AM -0400, wkbrad wrote:
> Thanks again Maxim! You're really providing some valuable insights for me. > > > This is because mmap()-based individual allocations imply additional > > overhead. Using mmapAnd this is are costly. > > That's what I figured might be going on. I assume there are also some > negative impacts on performance with accessing memory that is allocated via > mmap. Is that right? Accessing the memory shouldn't depend on the way how it is allocated. But there may be negative effects on the memory allocator performance due to the number of individual mmap() allocations it has to maintain, and there may be negative effects on the whole system performance with such a big number of mmap()s. > > On FreeBSD you'll see that _virtual_ memory usage grows on reload, > > but the actual memory is returned to the system and can be used by > > other processes. > > Actually, I see an increase in virtual and resident. Here are my tests from > FreeBSD. > -------------------------------------------------------------------------------- > service nginx restart; sleep 10; echo; ps aux|grep -v grep|egrep > 'RSS|nginx' > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 923 0.0 5.4 121840 110368 - Ss 08:10 0:00.00 nginx: master > process /usr/local/ > www 924 0.0 5.4 121840 110372 - S 08:10 0:00.01 nginx: worker > process (nginx) > -------------------------------------------------------------------------------- > service nginx reload; sleep 10; echo; ps aux|grep -v grep|egrep 'RSS|nginx' > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 923 0.0 10.2 219828 209388 - Ss 08:10 0:00.44 nginx: master > process /usr/local/ > www 940 0.0 10.2 219828 209384 - S 08:10 0:00.01 nginx: worker > process (nginx) > -------------------------------------------------------------------------------- > > Those tests look exactly like the Linux tests and it's definitely not > released back to the system. The problem is that "ps" doesn't know if memory counted in RSS can be reclaimed by the system or not. And reclaiming the memory might not happen till the system needs this memory for something else. You may have a better picture by looking at memory stats reported by top: $ ps aux | grep nginx | grep -v grep; top | grep Mem mdounin 55612 0.0 18.0 55192 41868 0 S+ 18:48 0:00.29 nginx: master mdounin 55613 0.0 18.0 55192 41868 0 S+ 18:48 0:00.00 nginx: worker Mem: 44M Active, 8208K Inact, 63M Wired, 29M Buf, 108M Free $ kill -HUP 55612 $ ps aux | grep nginx | grep -v grep; top | grep Mem mdounin 55612 1.0 32.6 87960 75808 0 S+ 18:48 0:00.68 nginx: master mdounin 55619 1.0 32.6 87960 75808 0 S+ 18:49 0:00.00 nginx: worker Mem: 52M Active, 34M Inact, 63M Wired, 29M Buf, 74M Free Note that most of the additional memory is now counted as "Inact", i.e., it can be reclaimed by the system at any time. The other factor is that jemalloc maintains various allocation caches, and some of the allocations are preserved there and not returned to the system. [...] > You may be asking why I'm even looking into this and I've had a lot of push > back and questions as to why I'm doing this. My point is this. Even if > Nginx on my server is only using 50M of ram, wouldn't it better for it to > use only 25M when that's all it needs? That's clearly a problem in my mind. > Can you address why that is not a problem? There are two things to keep in mind here: - Every task needs memory. Depending on the amount of memory used and how common the task is, it may worth optimizing or not. In most setups, nginx uses far less memory for the configuration data than for other things. And optimizing configuration storage hardly worth the effort, as it doesn't matter if your configuration uses 25M or 50M compared to a 2G shared memory zone used for cache keys, or several gigabytes of proxy buffers. - The particular effect of "doubling" memory usage on reload you are trying to understand in this thread is not really about nginx, but rather about how your system allocator works. You can tune or improve your system allocator to handle this better, but see above about if it worth the effort. If you still think this is a problem for you, and you want to save 25M of memory, you were already suggested several ways to improve things - including re-writing your configuration, re-compiling nginx without unused modules, or tuning/replacing your system allocator. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
