[SR-Users] ims_dialog default_timeout parameter
tyd
ydtzou at gmail.com
Wed Apr 11 02:53:27 CEST 2018
Hello,
>
> there are a lot of active dialogs there, however, as they BYEs are
> replied, the structures should be released in short time and shared memory
> freed. Do you execute dlg_manage() when receiving BYE?
>
> Cheers,
> Daniel
>
Hello,
I can not find dlg_manage in example scscf configuration file.
But below is ims_dialog document, dlg_manager has been deprecated in
ims_dialog.
6.10. dlg_manage()
This has been deprecated in ims_dialog. Instead set dialog flag for initial
INVITE and Route-parameter-callback execution for within-dialog requests.
Any suggestions? Thanks.
> On 10.04.18 10:43, tyd wrote:
>
>
>
> Hello,
>>
>> do you get also dialog statistics? tm stats are not relevant in this
>> context.
>>
>> Cheers,
>> Daniel
>>
> Hi,
>
> I'm re-running SIPp.
> The share memory is decreaing and will run out of memory.
> Is below information enough ?
>
>
> # kamctl stats shmem
> shmem:fragments = 40
> shmem:free_size = 312842424
> shmem:max_used_size = 224156616
> shmem:real_used_size = 224028488
> shmem:total_size = 536870912
> shmem:used_size = 140091536
>
> #kamctl mi dlg_list|grep dialog|wc -l
> 121500
>
> # kamctl dialog show|grep dialog|wc -l
> 123363
>
> # kamctl fifo get_statistics :dialog::all
> cdp:average_response_time = 3
> cdp:queuelength = 0
> cdp:replies_received = 20000
> cdp:replies_response_time = 72658
> cdp:timeout = 0
> core:bad_URIs_rcvd = 0
> core:bad_msg_hdr = 0
> core:drop_replies = 0
> core:drop_requests = 0
> core:err_replies = 0
> core:err_requests = 0
> core:fwd_replies = 0
> core:fwd_requests = 122460
> core:rcv_replies = 548443
> core:rcv_requests = 384642
> core:unsupported_methods = 0
> dialog_ng:active = 61230
> dialog_ng:early = 37
> dialog_ng:expired = 0
> dialog_ng:processed = 61267
> dns:failed_dns_request = 0
> ims_auth:mar_avg_response_time = 1
> ims_auth:mar_replies_received = 10000
> ims_auth:mar_replies_response_time = 16199
> ims_auth:mar_timeouts = 0
> ims_registrar_scscf:accepted_regs = 10000
> ims_registrar_scscf:default_expire = 3660
> ims_registrar_scscf:default_expires_range = 0
> ims_registrar_scscf:max_contacts = 1
> ims_registrar_scscf:max_expires = 654800
> ims_registrar_scscf:rejected_regs = 0
> ims_registrar_scscf:sar_avg_response_time = 5
> ims_registrar_scscf:sar_replies_received = 10000
> ims_registrar_scscf:sar_replies_response_time = 56459
> ims_registrar_scscf:sar_timeouts = 0
> ims_usrloc_scscf:active_contacts = 10000
> ims_usrloc_scscf:active_impus = 10000
> ims_usrloc_scscf:active_subscriptions = 10000
> ims_usrloc_scscf:contact_collisions = 28
> ims_usrloc_scscf:impu_collisions = 27
> ims_usrloc_scscf:subscription_collisions = 27
> mysql:driver_errors = 0
> shmem:fragments = 30
> shmem:free_size = 311718120
> shmem:max_used_size = 225269176
> shmem:real_used_size = 225152792
> shmem:total_size = 536870912
> shmem:used_size = 140599664
> sl:1xx_replies = 0
> sl:200_replies = 0
> sl:202_replies = 0
> sl:2xx_replies = 0
> sl:300_replies = 0
> sl:301_replies = 0
> sl:302_replies = 0
> sl:3xx_replies = 0
> sl:400_replies = 0
> sl:401_replies = 0
> sl:403_replies = 0
> sl:404_replies = 0
> sl:407_replies = 0
> sl:408_replies = 0
> sl:483_replies = 0
> sl:4xx_replies = 0
> sl:500_replies = 0
> sl:5xx_replies = 0
> sl:6xx_replies = 0
> sl:failures = 0
> sl:received_ACKs = 0
> sl:sent_err_replies = 0
> sl:sent_replies = 122534
> sl:xxx_replies = 122534
> tcp:con_reset = 0
> tcp:con_timeout = 0
> tcp:connect_failed = 0
> tcp:connect_success = 0
> tcp:current_opened_connections = 0
> tcp:current_write_queue_size = 0
> tcp:established = 0
> tcp:local_reject = 0
> tcp:passive_open = 0
> tcp:send_timeout = 0
> tcp:sendq_full = 0
>
> #
>
>
>
>>
>> On 10.04.18 09:19, tyd wrote:
>>
>> Hello,
>>>
>>> On 10.04.18 07:25, tyd wrote:
>>>
>>> Hi, Daniel
>>>
>>> No, the dialogs were not terminated after 10 minutes if no BYE message
>>> was sent.
>>>
>>>
>>> Not using ims_dialog, but it may be that it doesn't send bye when the
>>> dialog lifetime elapses, just destroys the structure it keeps in memory.
>>> With the other dialog module, there is a parameter to set if you want BYE
>>> to be sent.
>>>
>>> But if Default value(43200) was set, the S-CSCF will run out of memory
>>> finally (after 200000 calls).
>>>
>>> Were all these calls still active?
>>>
>>> Hi,
>> In SIPp, the calls were finishes.
>> But in Kamailio, the calls seem keep in the memory and run out of memory.
>> Can any parameter solve this problem?
>> Is it a solution to set "ims_dialog", "default_timeout" to 600 ?
>>
>> # kamcmd tm.stats
>> {
>> current: 69
>> waiting: 0
>> total: 991300
>> total_local: 0
>> rpl_received: 2183891
>> rpl_generated: 20232
>> rpl_sent: 1475856
>> 6xx: 0
>> 5xx: 2704
>> 4xx: 10124
>> 3xx: 0
>> 2xx: 978329
>> created: 991300
>> freed: 991231
>> delayed_free: 0
>> }
>> # kamctl stats shmem
>> shmem:fragments = 1630
>> shmem:free_size = 4303040
>> shmem:max_used_size = 536870912
>> shmem:real_used_size = 532567872
>> shmem:total_size = 536870912
>> shmem:used_size = 415668000
>>
>>
>>
>>
>>>
>>> Have any relation with this parameter and memory release ?
>>>
>>>
>>> Yes, the structure kept for each call is destroyed after lifetime. But
>>> it should be also destroyed if the BYE is received.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> Any impacts if using value 600 at production environment ?
>>> Thanks.
>>>
>>> 2018-04-10 0:27 GMT+08:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>
>>>> Hello,
>>>>
>>>> that should be the call lifetime. Are the dialogs terminated after 10
>>>> minutes?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 09.04.18 16:58, tyd wrote:
>>>>
>>>> Dear all,
>>>>
>>>> What's the meaning of ims_dialog default_timeout parameter ?
>>>> *Default value is 「43200 (12 hours)」*
>>>>
>>>> When modparam("ims_dialog", "default_timeout", 600) was set,
>>>> the situation of Kamailio S-CSCF out of memory was solved and is
>>>> running smoothly.
>>>>
>>>> Debian 8 with Kamailio 4.4.7
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
>>>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
>>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>
>>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180411/6be0b798/attachment.html>
More information about the sr-users
mailing list