Jan, First of all, be sure you are running the latest 1.6 version - there were some mem leaks fixed - just to be sure you are not facing some old issues.
Now, about the memory shortage, see http://www.opensips.org/Resources/DocsTsMem Regards, Bogdan Jan Rozhon wrote: > 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 > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users