OK, if you think such sort Debian behaviour is good:Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have gotthe 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.
Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have got the memory effectivity some better even than in Debian 7!Is there a way to reproduce your results easily? Upstream, we're looking for workloads which are difficult to handle for glibc's malloc and its default settings, so that we hopefully can improve things eventually.
This way of the ready builds of the application and LiveDisks is simplest one for me, than writing a test application with simulation such sort complex load, so you can already install the application, start and observer.
About my after-measures — I have set the environment variable MALLOC_ARENA_MAX=1 for all my builds of the live disks of the automation Linux distributive.
07.08.19 09:09, Roman Savochenko wrote:
I have a real-task environment on Debian 9 which consume
initially about 1.6 GB and after a pair days of such work it
consume about 6GB!
To demonstrate how this problem can be awful in real tasks, I have wrote the memory consumption tendency for the both default environment and under MALLOC_ARENA_MAX=1.
Also I have wrote the CPU load, to demonstrate of this environment variable influence to the performance.
So, the tendency of the memory consumption on a real big application at the default conditions and during two days is:
And the tendency of the memory consumption on the same real big application at the environment variable MALLOC_ARENA_MAX=1 and during two days is:
So, influence to the performance is slightly notating and counted
about 5% (15 > 20%), but the last environment also was under
higher user loading than the previous one.
Regards, Roman