[SR-Users] Kamailio out-of-mem
José Seabra
joseseabra4 at gmail.com
Mon Jul 4 18:59:47 CEST 2016
Hello,
It won't be ease because of the network firewall where the servers are
behind.
I will setup a new test environment in my laptop then give feedback.
Regards
José
2016-07-04 15:46 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
> Hello,
>
> looking at the source code, it seems that the xavp is linked to the root
> list and should be deleted with the rest of xavps when the
> message/transaction structure is destroyed.
>
> Would it be possible to allow me access to the test system in order to
> check the memory of kamailio with gdb?
>
> Cheers,
> Daniel
>
> On 04/07/16 15:48, José Seabra wrote:
>
> Hello
>
> I'm using lookup() and registered().
>
> Let me know if do you need more information or tests from my side.
>
> Regards
>
> 2016-07-04 14:41 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>> Hello,
>>
>> one more question: are you using only lookup(...) or using
>> registered(...) (or other functions from registrar module) as well?
>> Cheers,
>> Daniel
>>
>>
>> On 04/07/16 15:21, José Seabra wrote:
>>
>> Hello,
>> Right now I'm using registrar functions only in request_route.
>>
>> At first i had disabled both, after received your email, I disabled one
>> by one and I see that the only the parameter that is affecting this, is
>> modparam("registrar", "xavp_rcd", "ulrcd")
>>
>> Let me know if do you need more information.
>>
>> Regards
>> José
>>
>> 2016-07-04 13:20 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>
>>> Hello,
>>>
>>> very useful information -- are you using the registrar functions only
>>> inside request_route, or you have them also in failure_route or other type
>>> of routes?
>>>
>>> Were you able to detect if both cause the leak or you disabled both of
>>> them without trying each one?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 04/07/16 14:01, José Seabra wrote:
>>>
>>> Hello Daniel,
>>>
>>> I think that the issue is on registrar module.
>>>
>>> I'm using the following parameters:
>>>
>>> - modparam("registrar", "xavp_cfg", "regcfg")
>>> - modparam("registrar", "xavp_rcd", "ulrcd")
>>>
>>> If I disable it there isn't memory leak.
>>>
>>> Let me know if you need more information.
>>>
>>> Thank you
>>> Regards
>>> José
>>>
>>> 2016-07-04 11:27 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>
>>>> Hello,
>>>>
>>>> can you provide more details about where you use xavps in the
>>>> configuration file? Do you use them in some route block executed by rtimer
>>>> or via asyn framework (e.g., via t_continue() or async module)?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 03/07/16 20:35, José Seabra wrote:
>>>>
>>>> Hello,
>>>> I'm monitoring these testes with "corex.shm_summary" provided by kamcmd.
>>>>
>>>> I'm noticing that the core module - xavp.c is consuming lot of memory
>>>> and it is increasing.
>>>>
>>>> result of command corex.shm_summary is:
>>>>
>>>> fm_status: summarizing all alloc'ed. fragments:
>>>> fm_status: count= 2 size= 1120 bytes from tm: t_reply.c:
>>>> _reply_light(542)
>>>> fm_status: count= 2 size= 896 bytes from tm:
>>>> t_msgbuilder.c: build_uac_req(1543)
>>>> fm_status: count= 2182 size= 231088 bytes from tm: t_fwd.c:
>>>> prepare_new_uac(479)
>>>> fm_status: count= 12488 size= 12050808 bytes from tm: t_reply.c:
>>>> relay_reply(1884)
>>>> fm_status: count= 12490 size= 14564656 bytes from core:
>>>> msg_translator.c: build_req_buf_from_sip_req(2149)
>>>> fm_status: count= 12492 size= 71366536 bytes from tm: h_table.c:
>>>> build_cell(317)
>>>> fm_status: count= 12490 size= 75086184 bytes from core:
>>>> sip_msg_clone.c: sip_msg_shm_clone(494)
>>>> fm_status: count= 2 size= 96 bytes from tm: t_hooks.c:
>>>> insert_tmcb(137)
>>>> fm_status: count= 2182 size= 17800 bytes from tm: t_fwd.c:
>>>> prepare_new_uac(524)
>>>> fm_status: count= 3 size= 512 bytes from htable: ht_api.c:
>>>> ht_cell_new(183)
>>>> fm_status: count= 12490 size= 10586712 bytes from core:
>>>> sip_msg_clone.c: msg_lump_cloner(978)
>>>> fm_status: count= 56508 size= 3457904 bytes from core: usr_avp.c:
>>>> create_avp(175)
>>>> fm_status: count= 4 size= 600 bytes from tmx:
>>>> tmx_pretran.c: tmx_check_pretran(250)
>>>> fm_status: count= 4 size= 1008 bytes from usrloc:
>>>> ucontact.c: new_ucontact(98)
>>>> fm_status: count= 4 size= 1320 bytes from tmx:
>>>> tmx_pretran.c: tmx_check_pretran(271)
>>>> fm_status: count= 4 size= 144 bytes from usrloc: urecord.c:
>>>> new_urecord(65)
>>>> fm_status: count= 4 size= 328 bytes from usrloc: urecord.c:
>>>> new_urecord(58)
>>>> fm_status: count= 24 size= 952 bytes from usrloc:
>>>> ../../ut.h: shm_str_dup(723)
>>>> fm_status: count= 2182 size= 53040 bytes from tm: t_fwd.c:
>>>> prepare_new_uac(509)
>>>> fm_status: count=12545409 size=1420184592 bytes from core: xavp.c:
>>>> xavp_new_value(94)
>>>> fm_status: count= 4 size= 128 bytes from dmq: worker.c:
>>>> alloc_job_queue(229)
>>>> fm_status: count= 1 size= 13440 bytes from core: counters.c:
>>>> counters_prefork_init(207)
>>>> fm_status: count= 1 size= 4032 bytes from sl: sl_stats.c:
>>>> init_sl_stats_child(125)
>>>> fm_status: count= 1 size= 256 bytes from tmx:
>>>> tmx_pretran.c: tmx_init_pretran_table(90)
>>>> fm_status: count= 1 size= 5376 bytes from tm: t_stats.c:
>>>> init_tm_stats_child(60)
>>>> fm_status: count= 1 size= 1008 bytes from kex: pkg_stats.c:
>>>> pkg_proc_stats_init(79)
>>>> fm_status: count= 3 size= 88 bytes from core:
>>>> cfg/cfg_struct.c: cfg_clone_str(130)
>>>> fm_status: count= 1 size= 744 bytes from core:
>>>> cfg/cfg_struct.c: cfg_shmize(217)
>>>> fm_status: count= 3 size= 64 bytes from usrloc: udomain.c:
>>>> build_stat_name(51)
>>>> fm_status: count= 1 size= 40960 bytes from usrloc: udomain.c:
>>>> new_udomain(93)
>>>> fm_status: count= 1 size= 48 bytes from usrloc: udomain.c:
>>>> new_udomain(86)
>>>> fm_status: count= 1 size= 16 bytes from usrloc: dlist.c:
>>>> new_dlist(573)
>>>> fm_status: count= 1 size= 32 bytes from usrloc: dlist.c:
>>>> new_dlist(565)
>>>> fm_status: count= 1 size= 8 bytes from core: pt.c:
>>>> init_pt(110)
>>>> fm_status: count= 1 size= 8 bytes from core: pt.c:
>>>> init_pt(105)
>>>> fm_status: count= 1 size= 2944 bytes from core: pt.c:
>>>> init_pt(104)
>>>> fm_status: count= 1 size= 32 bytes from usrloc:
>>>> ul_callback.c: register_ulcb(94)
>>>> fm_status: count= 1 size= 24 bytes from dmq: ../../ut.h:
>>>> shm_str_dup(723)
>>>> fm_status: count= 1 size= 448 bytes from dmq: dmqnode.c:
>>>> build_dmq_node(156)
>>>> fm_status: count= 2 size= 168 bytes from dmq: peer.c:
>>>> add_peer(67)
>>>> fm_status: count= 1 size= 8 bytes from dmq: dmq.c:
>>>> mod_init(243)
>>>> fm_status: count= 1 size= 96 bytes from dmq: dmq.c:
>>>> mod_init(237)
>>>> fm_status: count= 1 size= 24 bytes from dmq: dmqnode.c:
>>>> init_dmq_node_list(66)
>>>> fm_status: count= 1 size= 24 bytes from dmq: peer.c:
>>>> init_peer_list(33)
>>>> fm_status: count= 1 size= 16 bytes from usrloc:
>>>> ul_callback.c: init_ulcb_list(45)
>>>> fm_status: count= 1 size= 4112 bytes from usrloc:
>>>> ../../lock_alloc.h: lock_set_alloc(70)
>>>> fm_status: count= 1 size= 8 bytes from carrierroute:
>>>> cr_data.c: rule_fixup_recursor(584)
>>>> fm_status: count= 5 size= 56 bytes from carrierroute:
>>>> ../../ut.h: shm_str_dup(723)
>>>> fm_status: count= 1 size= 152 bytes from carrierroute:
>>>> cr_rule.c: add_route_rule(74)
>>>> fm_status: count= 3 size= 240 bytes from core: dtrie.c:
>>>> dtrie_insert(157)
>>>> fm_status: count= 3 size= 48 bytes from core: dtrie.c:
>>>> dtrie_insert(148)
>>>> fm_status: count= 1 size= 48 bytes from carrierroute:
>>>> cr_rule.c: add_route_flags(225)
>>>> fm_status: count= 2 size= 160 bytes from core: dtrie.c:
>>>> dtrie_init(60)
>>>> fm_status: count= 2 size= 32 bytes from core: dtrie.c:
>>>> dtrie_init(51)
>>>> fm_status: count= 1 size= 32 bytes from carrierroute:
>>>> cr_domain.c: create_domain_data(83)
>>>> fm_status: count= 1 size= 8 bytes from carrierroute:
>>>> cr_carrier.c: create_carrier_data(59)
>>>> fm_status: count= 1 size= 64 bytes from carrierroute:
>>>> cr_carrier.c: create_carrier_data(50)
>>>> fm_status: count= 1 size= 8 bytes from carrierroute:
>>>> cr_db.c: load_route_data_db(295)
>>>> fm_status: count= 5 size= 1008 bytes from dispatcher:
>>>> dispatch.c: reindex_dests(600)
>>>> fm_status: count= 1 size= 48 bytes from carrierroute:
>>>> cr_db.c: load_domain_map(182)
>>>> fm_status: count= 1 size= 24 bytes from carrierroute:
>>>> cr_db.c: load_domain_map(171)
>>>> fm_status: count= 1 size= 48 bytes from carrierroute:
>>>> cr_db.c: load_carrier_map(126)
>>>> fm_status: count= 1 size= 24 bytes from carrierroute:
>>>> cr_db.c: load_carrier_map(115)
>>>> fm_status: count= 7 size= 168 bytes from dispatcher:
>>>> dispatch.c: add_dest2list(350)
>>>> fm_status: count= 1 size= 64 bytes from carrierroute:
>>>> cr_data.c: reload_route_data(172)
>>>> fm_status: count= 1 size= 8 bytes from carrierroute:
>>>> cr_data.c: init_route_data(74)
>>>> fm_status: count= 5 size= 4200 bytes from dispatcher:
>>>> dispatch.c: add_dest2list(324)
>>>> fm_status: count= 1 size= 16 bytes from dispatcher:
>>>> dispatch.c: init_data(204)
>>>> fm_status: count= 1 size= 16 bytes from dispatcher:
>>>> dispatch.c: init_data(195)
>>>> fm_status: count= 1 size= 8 bytes from dispatcher:
>>>> dispatcher.c: mod_init(309)
>>>> fm_status: count= 1 size= 8 bytes from dispatcher:
>>>> dispatcher.c: mod_init(307)
>>>> fm_status: count= 1 size= 8 bytes from dispatcher:
>>>> dispatch.c: ds_ping_active_init(102)
>>>> fm_status: count= 1 size= 256 bytes from db_text:
>>>> dbt_lib.c: dbt_init_cache(81)
>>>> fm_status: count= 1 size= 8 bytes from db_text:
>>>> dbt_lib.c: dbt_init_cache(69)
>>>> fm_status: count= 1 size= 8 bytes from db_text:
>>>> dbt_lib.c: dbt_init_cache(54)
>>>> fm_status: count= 3 size= 288 bytes from core: timer.c:
>>>> register_timer(1011)
>>>> fm_status: count= 4 size= 8388608 bytes from htable: ht_api.c:
>>>> ht_init_tables(381)
>>>> fm_status: count= 1 size= 8 bytes from sl: sl_funcs.c:
>>>> sl_startup(83)
>>>> fm_status: count= 1 size= 8 bytes from sl: sl_stats.c:
>>>> init_sl_stats(110)
>>>> fm_status: count= 1 size= 16 bytes from tm: t_hooks.c:
>>>> init_tmcb_lists(74)
>>>> fm_status: count= 1 size= 16 bytes from tm: t_hooks.c:
>>>> init_tmcb_lists(72)
>>>> fm_status: count= 1 size= 2097152 bytes from tm: h_table.c:
>>>> init_hash_table(467)
>>>> fm_status: count= 2 size= 64 bytes from core:
>>>> cfg/cfg_ctx.c: cfg_register_ctx(47)
>>>> fm_status: count= 1 size= 80 bytes from db_postgres:
>>>> ../../lock_alloc.h: lock_set_alloc(70)
>>>> fm_status: count= 1 size= 8192 bytes from core: tcp_main.c:
>>>> init_tcp(4635)
>>>> fm_status: count= 1 size= 32768 bytes from core: tcp_main.c:
>>>> init_tcp(4629)
>>>> fm_status: count= 1 size= 8 bytes from core: tcp_main.c:
>>>> init_tcp(4621)
>>>> fm_status: count= 1 size= 8 bytes from core: tcp_main.c:
>>>> init_tcp(4614)
>>>> fm_status: count= 1 size= 8 bytes from core: tcp_main.c:
>>>> init_tcp(4607)
>>>> fm_status: count= 1 size= 8 bytes from core: tcp_main.c:
>>>> init_tcp(4601)
>>>> fm_status: count= 1 size= 8 bytes from core: tcp_main.c:
>>>> init_tcp(4589)
>>>> fm_status: count= 1 size= 8 bytes from core: usr_avp.c:
>>>> init_avps(90)
>>>> fm_status: count= 1 size= 8 bytes from core: usr_avp.c:
>>>> init_avps(89)
>>>> fm_status: count= 1 size= 16384 bytes from core:
>>>> dst_blacklist.c: init_dst_blacklist(437)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> dst_blacklist.c: init_dst_blacklist(430)
>>>> fm_status: count= 2 size= 96 bytes from core: timer.c:
>>>> timer_alloc(514)
>>>> fm_status: count= 1 size= 8 bytes from core: dns_cache.c:
>>>> init_dns_cache(366)
>>>> fm_status: count= 1 size= 16384 bytes from core: dns_cache.c:
>>>> init_dns_cache(358)
>>>> fm_status: count= 1 size= 16 bytes from core: dns_cache.c:
>>>> init_dns_cache(351)
>>>> fm_status: count= 1 size= 8 bytes from core: dns_cache.c:
>>>> init_dns_cache(345)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(283)
>>>> fm_status: count= 1 size= 16384 bytes from core: timer.c:
>>>> init_timer(282)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(281)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(280)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(269)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(237)
>>>> fm_status: count= 1 size= 278544 bytes from core: timer.c:
>>>> init_timer(220)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(219)
>>>> fm_status: count= 1 size= 8 bytes from core: timer.c:
>>>> init_timer(206)
>>>> fm_status: count= 1 size= 64 bytes from core:
>>>> cfg/cfg_struct.c: cfg_child_cb_new(830)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> cfg/cfg_struct.c: sr_cfg_init(361)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> cfg/cfg_struct.c: sr_cfg_init(354)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> cfg/cfg_struct.c: sr_cfg_init(347)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> cfg/cfg_struct.c: sr_cfg_init(335)
>>>> fm_status: count= 1 size= 8 bytes from core:
>>>> cfg/cfg_struct.c: sr_cfg_init(323)
>>>> fm_status: count= 4 size= 928 bytes from htable: ht_api.c:
>>>> ht_add_table(278)
>>>> fm_status: count= 1 size= 8 bytes from core: mem/shm.c:
>>>> shm_core_lock_init(153)
>>>> fm_status: -----------------------------
>>>>
>>>> If i stop these tests and after few minutes, run again the command
>>>> "corex.shm_summary" the entry that contains the memory consume for xavp.c
>>>> doesn't decrease.
>>>>
>>>> It seems that there is a memory leak in this module xavp.c.
>>>>
>>>> Thank you for your help.
>>>> Regards
>>>> José
>>>>
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Cumprimentos
>>> José Seabra
>>>
>>>
>>> --
>>> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>
>>
>> --
>> Cumprimentos
>> José Seabra
>>
>>
>> --
>> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>
>
> --
> Cumprimentos
> José Seabra
>
>
> --
> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
--
Cumprimentos
José Seabra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160704/71f8a1d7/attachment-0001.html>
More information about the sr-users
mailing list