[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#934080: marked as done ([libc6] Significant degradation in the memory effectivity of the memory allocator)



Your message dated Thu, 8 Aug 2019 19:00:38 +0200
with message-id <20190808170038.GB26564@aurel32.net>
and subject line Re: Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator
has caused the Debian Bug report #934080,
regarding [libc6] Significant degradation in the memory effectivity of the memory allocator
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
934080: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934080
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---

Package: libc6
Version: 2.19, 2.24, 2.28
Severity: normal

--- Please enter the report below this line. ---
Initial condition of the problem representing is a program in the single source code, built on-and for Debian 7, 8, 9, 10 with a result in the Live disks.

The program represents a web-interface of several pages, where here used only the first page.

In building the first page there used wide range of memory chunks: small objects of the C++ classes (~100 bytes), resources of the image files (~10 kbytes), GD memory blocks (~1 kbytes), so on

The live disks were started under VirtualBox 5.2, where the got data was measured by top.

The data measuring under VirtualBox performed into the next stages:
1. Start the program and set the initial state, fixing the memory allocation — measuring the initial memory consumption value
2. Perform the allocation-freeing iteration
2.1. Open the first Web-interface page from a Web-browser of the host system
2.2. Close the page on the Web-browser
2.3. Wait to close-freeing session of the first Web-interface page on the program side, 1 minute — measuring the iteration memory consumption value
3. Return to the stage 2 and repeating 5 iterations

The stage 2.3 tested to real freeing all the allocated memory blocks both by the objects counters and by valgrind!

In the result we have next data:

Environment Initially, MB Iter. 1, MB Iter. 2, MB Iter. 3, MB Iter. 4, MB Iter. 5, MB Resume
Debian 10 amd64, GLibC 2.28, GCC 8.3.0 182 191.5 199 206 212 212 Satiated on the iteration 4, base consumption 9.5 MB, extra consumption 20 MB (200 %), liboscada.so 3.5 MB, ui_WebVision.so 0.74 MB
Debian 9 amd64, GLibC 2.24, GCC 6.3.0 160 170 178 179 183 185 Satiated on the iteration 5, base consumption 10 MB, extra consumption 15 MB (150 %), liboscada.so 3.5 MB, ui_WebVision.so 0.72 MB
Debian 8 amd64, GLibC 2.19, GCC 4.9.2 125.5 133 139 139 139 139 Satiated on the iteration 2, base consumption 7.5 MB, extra consumption 6 MB (80 %), liboscada.so 3.8 MB, ui_WebVision.so 0.79 MB
Debian 7 amd64, GLibC 2.13, GCC 4.7.2 101 108 111 112 112 112 Satiated on the iteration 2, base consumption 7 MB, extra consumption 4 MB (57 %), liboscada.so 3.4 MB, ui_WebVision.so 0.85 MB
Debian 10 i386, GLibC 2.28, GCC 8.3.0 151 158 162.5 166 166 166 Satiated on the iteration 3, base consumption 7 MB, extra consumption 8 MB (114 %), liboscada.so 3.7 MB, ui_WebVision.so 0.9 MB
Debian 9 i386, GLibC 2.24, GCC 6.3.0 125 131 132 136 136 139 Satiated on the iteration 5, base consumption 6 MB, extra consumption 8 MB (133 %), liboscada.so 3.7 MB, ui_WebVision.so 0.9 MB
Debian 8 i386, GLibC 2.19, GCC 4.9.2 92.5 99 101.5 103 103.5 103.5 Satiated on the iteration 2, base consumption 6.5 MB, extra consumption 4.5 (69 %), liboscada.so 3.6 MB, ui_WebVision.so 0.94 MB
Debian 7 i386, GLibC 2.13, GCC 4.7.2 70 76 76 76 77 77 Satiated on the iteration 2, base consumption 6 MB, extra consumption 1 MB (16 %), liboscada.so 3.6 MB, ui_WebVision.so 0.9 MB
ALTLinux 6 i386, GLibC 2.11.3, GCC 4.5.4 69 74 75 75 75 75 Satiated on the iteration 2, base consumption 5 MB, extra consumption 1 MB (20 %), liboscada.so 2.3 MB, ui_WebVision.so 0.9 MB

From the data we have the memory effectivity on AMD64 and I386 platform:

and the absolute initial size for the both platform:



I know about "the Memory Allocation Tunables" (https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html) and have tried them but:
- I have not got any effect from environments like to "GLIBC_TUNABLES=glibc.malloc.trim_threshold=128" on Debian 10
- If the tunables real work, why their do not apply globally (on the system level) to return the memory effectivity to the level of the Debian 7 (GLibC 2.13)?
- If the new memory allocator (into GLibC 2.28) is so good, how can I return its memory effectivity to the level of the Debian 7 (GLibC 2.13)?

The tested program and the analyse page provided on the page http://oscada.org/wiki/Modules/WebVision#Efficiency


--- System information. ---

Architecture:
Kernel: Any for i386, amd64

Debian Release: 8, 9, 10
500 stable-updates ftp.ua.debian.org
500 stable security.debian.org
500 stable ftp.ua.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


--- End Message ---
--- Begin Message ---
On 2019-08-07 21:08, Roman Savochenko wrote:
> Hello, Florian
> 
> 07.08.19 17:04, Florian Weimer wrote:
> > * Roman Savochenko:
> > > Initial condition of the problem representing is a program in the
> > > single source code, built on-and for Debian 7, 8, 9, 10 with a result
> > > in the Live disks.
> > I think glibc 2.13 as shipped by Debian was not built with
> > --enable-experimental-malloc, so it doesn't use arenas.  This can
> > substantially decrease RSS usage compared to later versions.  You can
> > get similar behavior by setting the MALLOC_ARENA_MAX environment
> > variable to 1 or 2.
> 
> Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have got
> the memory effectivity some better even than in Debian 7!
> 
> <http://oscada.org/wiki/File:WebVision_MemEffectAMD64.png>

Thanks for the feedback. I think we can therefore considered this bug as
solved. Closing it.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---

Reply to: