[OpenSER-Devel] RFC: memory management in database modules

[Bogdan-Andrei Iancu]

Hi Henning,

Indeed, it will be interesting to run the such tests, but some major 
advantages we have with the current mem manager:
    1) in private memory, we have no locking. Malloc from glibc does all 
the time lock in order to be thread safe
    2) debugging possibilities - I know there are hundreds of tools for 
doing this, but we have it built in and better tuned for openser
    3) runtime inspection - mem usage, fragments,

Anyhow, we will never be able to drop the internal openser mem manager 
as it is mandatory for shm memory ;)

Regards,
Bogdan

Henning Westerholt wrote:
> On Thursday 07 February 2008, Dan Pascu wrote:
>   
>>> Well ....do not take me as a performance maniac :D...As I said, it is
>>> not about performance but about functionality - memory fragmentation is
>>> something serious and we should try to avoid it as much as possible.
>>>       
>> As a side note to the discussed issue, I don't think it is realistic to
>> assume that memory fragmentation will not occur by just avoiding some DB
>> memory allocations that vary in size too much. Given the varying size of
>> SIP requests, over time, if the proxy is online for a long time and
>> servicing many requests per second, memory fragmentation will occur
>> sooner or later, unless the memory allocator is smart and works around
>> it, or if it has a defragmentor that is run when memory gets too
>> fragmented.
>>     
>
> It would be interesting to run OpenSER on a recent kernel with a recent glibc 
> and sees how the performance figures of the standard malloc compares now 
> against the internal f_malloc. The memory allocator in the kernel was 
> reworked quite a few times, and some work have been done in the active 
> defragmentation area (but i'm not sure if this have been merged yet).
>
> Cheers,
>
> Henning
>
>