[SIP Beyond VoIP] SylkServer throws a "MemoryError" and that is out of service although running
ANIL KARADAĞ
anil.karadag at gmail.com
Fri Feb 8 15:28:37 CET 2013
Adrian,
As you know traffic rate depends on some important conditions. So the
number is not finalized and i did not run traffic for a long time.
I showed 1200 concurrent calls but after some times SylkServer does not
response for new calls. I will share new rates in the next week :)
On Fri, Feb 8, 2013 at 4:22 PM, Adrian Georgescu <ag at ag-projects.com> wrote:
> Wow, to be honest it was developed with 50 concurrent calls in mind. If it
> does 1000 is beyond any of our dreams.
>
> Adrian
>
> On Feb 8, 2013, at 3:20 PM, ANIL KARADAĞ wrote:
>
>
> approximately 1200 :)
>
>
>
> On Fri, Feb 8, 2013 at 4:04 PM, Adrian Georgescu <ag at ag-projects.com>wrote:
>
>> Memory issues can related to any data structure. Each SIP method and SIP
>> dialog allocates memory and PJSIP has some arbitrary imposed limitations
>> for many internals. Is pretty hard to guess but that 1024 looks highly
>> suspects of being a static limit set somewhere.
>>
>> How many concurrent calls did you achieve?
>>
>> Adrian
>>
>>
>> On Feb 8, 2013, at 2:49 PM, ANIL KARADAĞ wrote:
>>
>> Hi Adrian,
>>
>>
>> This is the second time i have seen the error. I run traffic to show
>> simultaneous TCP port number on the application with sipp and
>> sipsimpleclient.
>>
>>
>> After some times, sylk is out of service due to this error.
>>
>>
>> Traffic model:
>>
>> - register individual users with "auto-answer" and "auto-hangup
>> <seconds>" options via script "sip-session"
>> - each user joins to rooms
>> - send dummy messages to all established sessions
>>
>>
>> *sipp results:*
>>
>> ------------------------------ Scenario Screen -------- [1-9]: Change
>> Screen --
>> Call-rate(length) Port Total-time Total-calls Remote-host
>> 0.0(0 ms)/1.000s 5060 16055.63 s 4783 1.1.1.1:5060(UDP)
>>
>> 0 new calls during 0.379 s period 1 ms scheduler resolution
>> *1024 calls (limit 1024) * Peak was 1024 calls, after
>> 4783 s
>> 0 Running, 1024 Paused, 0 Woken up
>> 10 dead call msg (discarded) 0 out-of-call msg (discarded)
>> 3 open sockets
>>
>> Messages Retrans Timeout
>> Unexpected-Msg
>> REFER ----------> 4783 0
>> 202 <---------- 3759 0 0 0
>> NOTIFY <---------- 3759 0 0 0
>> 200 ----------> 3759 0
>> NOTIFY <---------- 3759 3 0 0
>> 200 ----------> 3759 0
>> NOTIFY <---------- 3759 0 0 0
>> 200 ----------> 3759 0
>> ------------------------------ Test Terminated
>> --------------------------------
>>
>>
>> ----------------------------- Statistics Screen ------- [1-9]: Change
>> Screen --
>> Start Time | 2013-02-08 11:11:26:434 1360314686.434073
>> Last Reset Time | 2013-02-08 15:39:01:693 1360330741.693140
>> Current Time | 2013-02-08 15:39:02:073 1360330742.073187
>>
>> -------------------------+---------------------------+--------------------------
>> Counter Name | Periodic value | Cumulative value
>>
>> -------------------------+---------------------------+--------------------------
>> Elapsed Time | 00:00:00:380 | 04:27:35:639
>> Call Rate | 0.000 cps | 0.298 cps
>>
>> -------------------------+---------------------------+--------------------------
>> Incoming call created | 0 | 0
>> OutGoing call created | 0 | 4783
>> Total Call created | | 4783
>> * **Current Call | 1024* |
>>
>> -------------------------+---------------------------+--------------------------
>> Successful call | 0 | 3759
>> Failed call | 0 | 0
>>
>> -------------------------+---------------------------+--------------------------
>> Call Length | 00:00:00:000 | 00:00:00:266
>> ------------------------------ Test Terminated
>> --------------------------------
>>
>>
>>
>> On Fri, Feb 8, 2013 at 3:32 PM, Adrian Georgescu <ag at ag-projects.com>wrote:
>>
>>> Unless one can reproduce the exact load you created, how could anyone
>>> know.
>>>
>>> What do you mean by testing performance, can you elaborate what you
>>> have tested and how?
>>>
>>> Adrian
>>>
>>>
>>> On Feb 8, 2013, at 2:28 PM, ANIL KARADAĞ wrote:
>>>
>>> Hi all,
>>>
>>>
>>> I am working with SylkServer to test its performance. And I show that
>>> the following message in the /var/log/messages file.
>>>
>>> *"Feb 8 12:14:08 rcs-chat-server sylk-server[1386]: MemoryError"*
>>> *
>>> *
>>> *
>>> *
>>> The message is generated by sipsimple -> _core.so. But I don't
>>> understand it because my server has a 6GB memory and the application is
>>> used max 900MB.
>>>
>>> Does anyone know that why the application acts like this?
>>>
>>>
>>> thanks
>>>
>>> [root at sylkserver core]# pwd
>>> */opt/mcp/sylkserver/data/python-sipsimple/sipsimple/core*
>>> *[root at sylkserver core]# grep "MemoryError" -r .*
>>> ./_core.event.pxi: raise MemoryError()
>>> ./_core.event.pxi: raise MemoryError()
>>> ./_core.lib.pxi: raise MemoryError()
>>> ./_core.c:static PyObject *__pyx_builtin_MemoryError;
>>> ./_core.c:static char __pyx_k__MemoryError[] = "MemoryError";
>>> ./_core.c:static PyObject *__pyx_n_s__MemoryError;
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError() # <<<<<<<<<<<<<<
>>> ./_core.c: __pyx_t_5 = PyObject_Call(__pyx_builtin_MemoryError,
>>> ((PyObject *)__pyx_empty_tuple), NULL); if (unlikely(!__pyx_t_5))
>>> {__pyx_filename = __pyx_f[2]; __pyx_lineno = 180; __pyx_clineno = __LINE__;
>>> goto __pyx_L1_error;}
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError() # <<<<<<<<<<<<<<
>>> ./_core.c: __pyx_t_2 = PyObject_Call(__pyx_builtin_MemoryError,
>>> ((PyObject *)__pyx_empty_tuple), NULL); if (unlikely(!__pyx_t_2))
>>> {__pyx_filename = __pyx_f[10]; __pyx_lineno = 55; __pyx_clineno = __LINE__;
>>> goto __pyx_L1_error;}
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError() # <<<<<<<<<<<<<<
>>> ./_core.c: __pyx_t_2 = PyObject_Call(__pyx_builtin_MemoryError,
>>> ((PyObject *)__pyx_empty_tuple), NULL); if (unlikely(!__pyx_t_2))
>>> {__pyx_filename = __pyx_f[10]; __pyx_lineno = 122; __pyx_clineno =
>>> __LINE__; goto __pyx_L1_error;}
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: * raise MemoryError()
>>> ./_core.c: {&__pyx_n_s__MemoryError, __pyx_k__MemoryError,
>>> sizeof(__pyx_k__MemoryError), 0, 0, 1, 1},
>>> ./_core.c: __pyx_builtin_MemoryError = __Pyx_GetName(__pyx_b,
>>> __pyx_n_s__MemoryError); if (!__pyx_builtin_MemoryError) {__pyx_filename =
>>> __pyx_f[2]; __pyx_lineno = 180; __pyx_clineno = __LINE__; goto
>>> __pyx_L1_error;}
>>>
>>>
>>> --
>>> Anıl KARADAĞ
>>> http://anilkaradag.info/blog
>>> _______________________________________________
>>> SIPBeyondVoIP mailing list
>>> SIPBeyondVoIP at lists.ag-projects.com
>>> http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip
>>>
>>>
>>>
>>
>>
>> --
>> Anıl KARADAĞ
>> http://anilkaradag.info/blog
>>
>>
>>
>
>
> --
> Anıl KARADAĞ
> http://anilkaradag.info/blog
>
>
>
--
Anıl KARADAĞ
http://anilkaradag.info/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20130208/eb5a2c91/attachment-0001.html>
More information about the SIPBeyondVoIP
mailing list