[OpenSIPS-Users] Debugging memory leaks
Liviu Chircu
liviu at opensips.org
Wed Mar 11 10:32:17 EST 2020
On 11.03.2020 12:21, Fabian Gast wrote:
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 33428816 : 3893 x [h_table.c: build_cell, line 244]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 72 : 3 x [evi/event_interface.c: evi_event_subscribe, line 334]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 176 : 1 x [event_route.c: scriptroute_parse, line 306]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 616 : 12 x [ucontact.c: mem_update_ucontact, line 255]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [dlg_timer.c: init_dlg_reinvite_ping_timer, line 192]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 8 : 1 x [sl_funcs.c: sl_startup, line 80]
> Mar 10 23:00:03 ireg02 /usr/sbin/opensips[42351]: 37022512 : 3893 x [sip_msg.c: sip_msg_cloner, line 534]
It seems most of your shared memory usage (33MB + 37MB, which equates to
~80% of total usage) consists of ... unreleased "tm" module
transactions! Some questions going forward:
* what kind of traffic is hitting your server when you reach this
state? Is it just during normal operation, or are you passing through
some kind of peak hour or maybe you are performing a sipp-based stress test?
* do you have (or can you create) a quiet window, with less traffic? If
yes, do these transactions get cleaned up properly within a minute, or
are we dealing with some kind of transaction referencing bug (unlikely)?
* can you reproduce this in a lab environment? If yes, please share how! :)
Regards,
--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
www.opensips.org/events
More information about the Users
mailing list