[OpenSER-Devel] [ openser-Patches-1998043 ] Fetch Support for Dialog-Module

Dan Pascu dan at ag-projects.com
Tue Jun 24 15:14:21 CEST 2008


On Tuesday 24 June 2008, Henning Westerholt wrote:
> On Friday 20 June 2008, Dan Pascu wrote:
> > IMO, this is a bug fix, more than a new feature and it should be
> > applied to 1.4 before released. We had similar problems in the past
> > with loading usrloc contacts and was fixed in a similar manner.
> >
> > Not being able to load more than 300 dialogs at startup is a serious
> > bug not a missing feature.
> >
> > At this point I'm so tempted to use the system malloc instead of
> > pkg_malloc as I had so many issues with not enough memory or memory
> > fragmentation in the past and even now.
>
> Hello Dan,
>
> this is a limitiation,

It's a very serious limitation. I even call it a bug. If you have to flush 
you dialog state table to be able to restart openser, the whole ability 
to preserve dialog state over restarts is gone out on the window. Under 
these circumstances, why would I even bother to save dialog state if I 
can't reload it.

I had similar problems with usrloc before the code was changed and it was 
not pretty to restart openser. Having to flush the usrloc table goes 
against having the ability to persistently store contacts over restarts.

> but the patch is IMHO to extensive to be applied 
> in the current state of development.

I don't think that is the unit to measure it. If it's a bug fix it doesn't 
matter how large the fix is. If you remember the amount of code that was 
necessary to fix the problems with mi_xmlrpc in 1.3 (and which was pushed 
during the freeze), you'd probably consider this a walk on the beach.

>
> I'm really curious to see a performance comparison between pkg_malloc
> and system malloc for recent glibc implementations. I'm not sure how
> much work they've invest after the merge of ptmalloc2 that went into
> 2.3.0, but the only actual issues i'm aware of are some regressions [1]
> and some multithreading problems [2], which probably not apply for us.

It's not only about performance, for me it's about limitations like this 
that make pkg_malloc unfriendly. Also the openser memory management has a 
very nasty problem with fragmentation. Not that visible with shm_malloc 
since that has a much larger pool to play with, but very visible with 
pkg_malloc. Try to run openserctl fifo ul_dump when you have more than 
2000 contacts. The command will try to build the list to return and 
somewhere along the process will fail because it has not enough pkg 
memory. It'll then release all allocated memory and return an error code. 
You'd think it ends there, but after this, any openserctl command you try 
to run will fail with pkm memory allocation failures, even though almost 
all of the pkm memory is available. But it's so fragmented that it cannot 
allocate even a small chunk for something like openserctl ps
To fix this you have to restart openser.

I don't know how the system malloc handles this, but I guess the OS has 
some sort of memory defragmentater, otherwise the system wouldn't be able 
to run for long with all the applications doing constant memory 
allocations and deallocations.

-- 
Dan



More information about the Devel mailing list