15 Mar
2007
15 Mar
'07
11:05 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users