[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