RE: [reSIProcate] Load Testing Using Resiprocate
I must not have been clear -- the memory corruption was
the fault of my software, not resip. There was no fix
to submit.
> -----Original Message-----
> From: kaiduan xie [mailto:kaiduanx@xxxxxxxx]
> Sent: Thursday, September 29, 2005 11:01 AM
> To: Dennis Dupont; Asheesh Joshi;
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Load Testing Using Resiprocate
>
>
> Dennis,
>
> Can you contribute your finding on memory corruption
> and the fix of Resip back to the community?
>
> Many thanks,
>
> kaiduan
> --- Dennis Dupont <ddupont@xxxxxxxxxxxxxxx> wrote:
>
> > Some clarifying questions:
> > - are you using dum or just resip?
> > - which version are you running?
> > - do you have a stack trace?
> > - have you run your code under valgrind to look for
> > memory corruption?
> > - do you mean 10 call setups/second per user
> > (1000/second) or just
> > 10/second overall spread over 100 users?
> >
> > I have tested my B2BUA under loads of up to 60
> > calls/second on a dual
> > Xeon LINUX system. In fact, I actually
> > ran 3 instances of my program on this machine, each
> > at 50 calls/second
> > with a load balancer in front of them.
> > So I had a total load of 150 CSPS on the system. We
> > split the program
> > up only to have less calls affected
> > by a software failure. This configuration ran for
> > several days with
> > over 10 million calls. I never even had any
> > swapping and ran all within just over 1GB of
> > physical memory (2 GB on
> > the system). My system is built with
> > 0.9.0-5019. However, I am not using dum, so I
> > cannot comment on that
> > part of the software.
> >
> > Before I achieved that stability I also had crashes
> > similar to what you
> > describe. It was almost always in the
> > stack, but I was pretty sure I was stomping on the
> > stack. Sure enough,
> > I used valgrind to find that I was
> > writing to released memory. Since resip uses the
> > heap intensely and my
> > application only uses it rarely,
> > resip was the most likely victim of my defects.
> >
> >
> > -----Original Message-----
> > From: Asheesh Joshi [mailto:asjoshi@xxxxxxxxxx]
> > Sent: Thursday, September 29, 2005 12:41 AM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] Load Testing Using
> > Resiprocate
> >
> >
> > Hi All,
> >
> > Over the past one week I am trying to get my
> > B2BUA using the resip
> > put under load test. There are
> > some issues I am seeing with the memory creeping up
> > slowly and slowly.
> >
> > My team is still trying to find out is it our
> > UAS / UAC state
> > machines that is slowly eating up the
> > memory. Meanwhile I thought I will write in this
> > mail and seek
> > suggestions/information from you guys
> > on past observed behavior of Resip under load
> > testings.
> >
> > We have a tool generatting load at 10 calls per
> > second for 100
> > users... each call cycle being defined by
> > INVITE, 100 trying, 180 ringing, 200 Ok, ACK, (
> > Pause ), BYE, ACK.
> >
> > The B2BUA is running in a Linux machine and we
> > monitor the memory
> > using "top" command
> > and I see memory rising .1% to .5 % after each batch
> > of 100 calls.
> > Eventually after 12,000 calls
> > the system crashes !
> >
> > I wanted to ask the forum that do we have any
> > statistics on RESIP
> > being tested under high
> > traffic for long periods ? And has any kind of
> > memory leak testing being
> > done on Resip. Can
> > somebody suggest me some good tools ?
> >
> > Any help will be appreciated.
> >
> > -cheers
> > Asheesh
> >
> >
> >
> > Asheesh Joshi
> > SCA-Voice Development.
> > Varaha Systems India Pvt Ltd.
> > <http://www.varaha.com/> www.varaha.com
> > mail: <mailto:asjoshi@xxxxxxxxxx>
> > asjoshi@xxxxxxxxxx
> >
> >
> > > _______________________________________________
> > resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
>
>
>
>
>
> __________________________________________________________
> Find your next car at http://autos.yahoo.ca
>