Memory Usage of BIRD

[Wolfgang Hennerbichler]

On Dec 4, 2009, at 16:56 , Ondrej Zajicek wrote:

> On Thu, Dec 03, 2009 at 12:33:22PM +0100, Wolfgang Hennerbichler wrote:
>>>> Hi Folks,
>>>> 
>>>> I just made a little experiment:
>>>> * let BIRD peer with a router that has Full Feed
>>>> * letting BIRD eat Full Feed (and tweet) - memory footprint ~ 130 MB BTW 
>>>> (64 Bit Linux)
>>>> * shutting the session down on the router-side
>>>> * BIRD's memory consumption decreased to 128 MB, but was never freed  
>>>> again.
>>> 
>>> This is probably caused by memory fragmentation and is otherwise harmless.
>>> You can try that if you shut down the session and after a while shut up
>>> the session, the memory footprint shouldn't be much larger than initially
>>> (memory that was freed by BIRD but not released to OS is reused).
>> 
> 
>> diggin up this old thread. I just did a test on that behaviour on
>> Linux and FreeBSD. If sessions go down, the routing tables go empty, and
>> even the protocols are disabled on Linux (64 Bit) BIRD doesn't free the
>> memory to the OS. Or Linux doesn't reclaim the free memory. 
>> ...
>> On FreeBSD the behaviour is different, FreeBSD gets back most of
>> BIRD's unused memory. Maybe we can look at this together. 
> 
> I would expect that this is not a bug in BIRD, but a behavior of glibc
> memory management code (cause by memory fragmentation of heap and
> reluctancy of glibc to return memory to the kernel). There are three
> levels in memory management - program, libc and kernel. If program frees
> some memory to libc and libc does not free it to kernel, it counts as a
> memory consumption of that process (from the external point of view) and
> kernel cannot reclaim that memory. This problem is general and
> well-known and might be mitigated by some precautions, but i don' think
> it is worth the work now.

Thinking about this a little more this really isn't work the worth - we have dedicated boxes and memory for bird, so actually if it ever consumes too much memory we're screwed anyway. 

Thanks for your reply; 
Wolfgang

> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."

-- 
www.vix.at | www.aco.net
wh at univie.ac.at | WH844-RIPE
Vienna University Computer Center