Unbound pretends to report memory statistics based on the value returned
by sbrk(). Not only is this non-portable (as demonstrated by r3528 and
r3911), but it is completely meaningless even on systems that provide
the sbrk() function. First, modern allocators (and by "modern" I mean
"anything written in the last 10-15 years") use mmap(), not sbrk(), to
manage address space. Second, even with allocators that do rely on
sbrk(), it only tells you how much address space is available to the
program, not how much of it is currently or has ever been used. The
attached patch removes all traces of sbrk() from the code.
First, modern allocators (and by "modern" I mean
"anything written in the last 10-15 years") use mmap(), not sbrk(), to
manage address space.
Both jemalloc and glibc use sbrk in addition to mmap.
Second, even with allocators that do rely on
sbrk(), it only tells you how much address space is available to the
program, not how much of it is currently or has ever been used.
glibc and at least some versions of jemalloc use brk(p) or sbrk(-x) to
release part of the data segment back to the operating system.
Taylor R Campbell <campbell+unbound@mumble.net> writes:
Both jemalloc and glibc use sbrk in addition to mmap.
Jemalloc *can* use sbrk() in addition to mmap() if enabled at build
time, but even then, it will try mmap() first, unless you explicitly
configure it at runtime to prefer sbrk() over mmap(). And it's still
not a meaningful measure of the amount of memory in use.
glibc and at least some versions of jemalloc use brk(p) or sbrk(-x) to
release part of the data segment back to the operating system.
Which will only work if the heap is not very fragmented.
Unbound pretends to report memory statistics based on the value returned
by sbrk(). Not only is this non-portable (as demonstrated by r3528 and
r3911), but it is completely meaningless even on systems that provide
the sbrk() function. First, modern allocators (and by "modern" I mean
"anything written in the last 10-15 years") use mmap(), not sbrk(), to
manage address space. Second, even with allocators that do rely on
sbrk(), it only tells you how much address space is available to the
program, not how much of it is currently or has ever been used. The
attached patch removes all traces of sbrk() from the code.
Thank you, applied this patch. There are separate debug counters in the
allocation debug code in unbound, so sbrk is not needed.
Not sure if the munin_ graph change is wanted, it was produced with 'ps'
getting the RSS value, and users may appreciate it?