[OpenSIPS-Users] Setting opensips for maximum performance

Jan Rozhon jan.rozhon at gmail.com
Mon Feb 22 11:12:46 CET 2010


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<bogdan at 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 at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>    




More information about the Users mailing list