[Users] memory issues

Daniel-Constantin Mierla daniel at voice-system.ro
Thu Mar 15 22:05:12 CET 2007


Hello,

On 03/15/07 21:25, Christian Schlatter wrote:
> I'm doing sipp performance measurements with openser 1.2 and I was 
> surprised on how much memory the openser processes do allocate when 
> confronted with a high call-per-second load.
>
> I observed the following behavior:
>
> One sipp instance creates SIP requests that get routed through openser 
> and forwarded to another sipp instance running in UAS mode. The sipp 
> scenario looks like
>
> INVITE ---------->
>    100 <----------
>    180 <----------
>    200 <----------
>    ACK ---------->
>  Pause [    10.0s]
>    BYE ---------->
>    200 <----------
>
> Nothing special here. The openser instance record routes the SIP 
> requests and forwards them in transaction stateful mode (t_relay) to 
> the sipp UAS instance. The routing script looks like:
>
> route{
>         if (!method=="REGISTER") record_route();
>         if (loose_route()) route(1);
>         if (uri==myself) rewritehost("xx.xx.xx.xx");
>         route(1);
> }
>
> route[1] {
>         if (!t_relay()) sl_reply_error();
>         exit;
> }
>
> ( xx.xx.xx.xx is the IP of sipp UAS)
>
> Running sipp with a call rate of 500 cps results in 45 MB of memory 
> allocation per openser process after a few seconds. What could cause 
> this behavior, message queuing maybe? But then again having a message 
> queue of 40+ MB seems to be unrealistic.
It is not per process. It is the share memory, I guess. By default, each 
openser process can use maximum of 1MB. Share memory is 32MB by default, 
can be changed by -w command line parameter. It cannot go over it, it is 
the moment of out of memory. It is all the time visible as allocated by 
openser, but can be free. You can use "openserctl fifo get_statistics 
all" to see how much of memory is really used.

A transaction lasts a bit more in memory after a final response has been 
answered. The transaction keeps at least two times the size of initial 
request, plus a reply at a moment, so it demands some memory. If you get 
high load at a moment you need more memory. Try to set share memory size 
to higher values and run the tests again.
>
> And the memory consumption goes up the longer the test runs until 
> openser dies because of out-of-memory.
What do you mean by dies? It crashes or just prints lot of error 
messages in syslog? If you stop the sip flood and try a bit later, did 
you get same errors from first time?
>
> I observed the same behavior with openser 1.1 and 1.2. Is this a 
> memory leak or did I miss some settings? 
We needed to set share memory to 768MB to be able to flood openser at 
full power of 2 sipp instances. The results were about 4000 cps per 
instance.
> And what's the best method to debug memory issues with openser?
Not very easy right now, compiling without F_MALLOC and with 
DBG_QM_MALLOC is the best. Plans to improve in this aspects are 
scheduled for next release.

Cheers,
Daniel

>
>
> thanks in advance,
> Christian
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>




More information about the Users mailing list