Already did - Feb 21 03:36:31 chieftec /usr/sbin/opensips[3429]: ERROR:registrar:update_contacts: failed to insert contact Feb 21 03:36:31 chieftec /usr/sbin/opensips[3419]: ERROR:registrar:update_contacts: failed to insert contact Feb 21 03:36:31 chieftec /usr/sbin/opensips[3425]: ERROR:usrloc:new_ucontact: no more shm memory Feb 21 03:36:31 chieftec /usr/sbin/opensips[3405]: ERROR:usrloc:new_ucontact: no more shm memory Feb 21 03:36:31 chieftec /usr/sbin/opensips[3425]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact Feb 21 03:36:31 chieftec /usr/sbin/opensips[3410]: ERROR:usrloc:mem_insert_ucontact: failed to create new contact Feb 21 03:36:31 chieftec /usr/sbin/opensips[3409]: ERROR:usrloc:mem_insert_urecord: creating urecord failed Feb 21 03:36:31 chieftec /usr/sbin/opensips[3403]: ERROR:usrloc:insert_urecord: inserting record failed Feb 21 03:36:31 chieftec /usr/sbin/opensips[3402]: ERROR:usrloc:mem_insert_urecord: creating urecord failed Feb 21 03:36:31 chieftec /usr/sbin/opensips[3417]: ERROR:registrar:insert_contacts: failed to insert new record structure Feb 21 03:36:31 chieftec /usr/sbin/opensips[3421]: ERROR:usrloc:mem_insert_urecord: creating urecord failed Feb 21 03:36:31 chieftec /usr/sbin/opensips[3401]: ERROR:usrloc:new_urecord: no more share memory
These errors keep occuring - however increasing the shared memory (from 2048 to 3072) didnt change the performance (same percentage of failed calls) Dne 22.2.2010 10:05, Bogdan-Andrei Iancu napsal(a): > If you received a 500 reply from opensips, you may check opensips logs > for errors - maybe opensips is running out of memory or some other > internal error. > > Regards, > Bogdan > > Jan Rozhon wrote: > >> Hi Bogdan, >> >> I also thought, that the problem may be in SIPp, however most error I >> get in SIPp are 500 Server Error Occured, so It directed me to >> Opensips, moreover I tried to increase the load on a single VM and the >> problems didnt occure until I reached 100% CPU utilization on SIPp VM. >> >> Disabling the authentication is not an option for me, because I need >> it in my thesis, but I will try it to see, if it is not the >> bottleneck. >> >> Thanks >> Jan >> >> 2010/2/22 Bogdan-Andrei Iancu<bog...@voice-system.ro>: >> >> >>> Hi Jan, >>> >>> Jan Rozhon wrote: >>> >>> >>>> Hi Bogdan, >>>> >>>> thank you for your advice, but no help so far. I ran a test again using >>>> a load of 280 calls per second (2800 simultaneous calls) and watched >>>> receive buffer errors using netstat -su, but only 2930 errors occured >>>> out of almost 3 000 000 packets received. So if I understand it well, >>>> the problem is not caused by udp buffer size, because despite the low >>>> number of udp datagrams discarded more than 60 000 calls were not >>>> succesful (aproximately 25% of total calls). >>>> >>>> >>>> >>> In sipp, what are the the cps and max parallel call you are using ? >>> Also, what kind of failures does the sipp report (missing 200ok ? >>> missing BYE? etc). >>> >>> >>>> Then I checked the database setting - I am using MySQL with "0" >>>> parameter (no database persistency), so I dont know how else I can make >>>> it run faster (I cannot use separate computer for the database). >>>> >>>> >>>> >>> so no DB persistence for usrloc, but you mentioned using auth - is this >>> correct? as auth is doing real time DB queries maybe you should try >>> disabling the auth also to see how this affects the performance. >>> >>> >>>> As an opensips newbie, I dont have a clue, where the real problem could >>>> be, so any further help would be appreciated. >>>> >>>> Thanks, Jan >>>> >>>> Dne 19.2.2010 14:56, Bogdan-Andrei Iancu napsal(a): >>>> >>>> >>>> >>>>> Hi Jan, >>>>> >>>>> You need to see where the bottleneck is. If it is not the CPU, it must >>>>> be some I/O blocking opensips. For example the DB may be too slow >>>>> blocking opesips processes -> no process to read traffic from network -> >>>>> traffic discarded, package lost. >>>>> >>>>> So, you should first look with netstat at the UDP sock, to see if the >>>>> in-buffer is full or not (if full, the kernel will discard packages). >>>>> >>>>> Regarding the timeouts (for calls, for retransmissions) see the TM module: >>>>> http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id228443 >>>>> >>>>> Regards, >>>>> Bogdan >>>>> >>>>> Jan Rozhon wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> as a part of my diploma thesis I'm trying to do some performance testing >>>>>> of opensips running on low cost machine with 4GB of RAM and dual-core >>>>>> AMD Athlon processor. As a generator of SIP traffic I use SIPp v3.1 >>>>>> running on 4 virtual computers as UAC and two computers as UAS all >>>>>> connected just by gigabit ports of a single switch. My proublem is, that >>>>>> as soon as I reach the load of 200 calls per second (2000 simultaneous >>>>>> calls) many of those calls (aroud 50%) don't finish succesfully. CPU >>>>>> utilization of opensips machine is around 40% and memory around 25%, so >>>>>> the opensips has still a lot of free resources, but it doesn't use them. >>>>>> Could you please advise me, how to change default configuration script >>>>>> and opensips settings to achieve better results? >>>>>> >>>>>> Right now, the only changes I made is : >>>>>> -enabling registrar/proxy authentication; >>>>>> -disabled tcp, since all the traffic is carried by udp; >>>>>> -set shared memory to 2048 MB; >>>>>> -set number of children to 16 >>>>>> -limit debug level to 1 >>>>>> >>>>>> PS. How can I increase the time, after which opensips retransmits SIP >>>>>> messages? >>>>>> >>>>>> Thanks in advance, >>>>>> Jan >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
