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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users