[Users] memory issues

Christian Schlatter cs at unc.edu
Fri Mar 16 05:38:49 CET 2007


Daniel,

Daniel-Constantin Mierla wrote:
...
>> 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.

Thanks for the clarification, I was always looking at 'top' output that 
shows total shared memory as per process reserved memory. The fifo 
statistics are very helpful.

> 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.

Ok, so memory consumption is directly related to number of ongoing SIP 
transactions. Confusingly, 'top' only shows max used memory so I was 
thinking that openser didn't release memory after stopping the SIP flood.

I always had 768MB shared memory configured though, so I still can't 
explain the memory allocation errors I got. Some more test runs revealed 
that I only get these errors when using a more production oriented 
config that loads more modules than the one posted in my earlier email. 
I now try to figure out what exactly causes these memory allocation 
errors that happen reproducibly after about 220s at 400 cps.

I could successfully achieve about 2000 cps over a long period with the 
simple config which is probably limited by the single sipp UAC instance 
and not by openser's performance.

I also tested userloc in db-only mode with a mysql cluster storing 
30'000 permanent registration entries (location table). With this setup 
I could achieve about 800 cps (randomized user population), which is a 
very good number. With a BHCA of 5 this would be enough to support over 
500'000 user agents.

thanks,
Christian


>>
>> 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 sr-users mailing list