<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hello,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Not analysed it in detail, but this looks indeed a bit odd:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">job_queue_push(286): 15369848 – 15MB allocated in this function alone.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">My suggestion would be to try to reproduce it in your lab/testing environment, and then test a newer version and investigate the reasons for this issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">As soon as you can reproduce it with a recent 5.3 or 5.4. version, please create a ticket for it.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Henning<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">-- <o:p>
</o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Henning Westerholt –
</span><span style="mso-fareast-language:EN-US"><a href="https://skalatan.de/blog/"><span lang="EN-GB" style="color:#0563C1">https://skalatan.de/blog/</span></a></span><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Kamailio services –
</span><span style="mso-fareast-language:EN-US"><a href="https://gilawa.com/"><span lang="EN-GB" style="color:#0563C1">https://gilawa.com</span></a></span><span style="mso-fareast-language:EN-US">
<span lang="EN-GB"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b>From:</b> sr-users <sr-users-bounces@lists.kamailio.org>
<b>On Behalf Of </b>Patrick Wakano<br>
<b>Sent:</b> Tuesday, October 27, 2020 7:20 AM<br>
<b>To:</b> Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org><br>
<b>Subject:</b> Re: [SR-Users] Kamailio unresponsive with Dialog+DMQ<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Sorry to bother again, but another problem we are facing and that now seems related is an increasing memory usage similar to a memory leak.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">So during the load test, Kamailio shmem starts increasing fast making it run out of shmem. Today it happened again and I could retrieve some info and looks like the "leak" is likely due to the DMQ workers. The
kamcmd shmem stats showed high usage in core and dmq:<br>
# kamcmd mod.stats all shm<br>
Module: core<br>
{<o:p></o:p></p>
<div style="margin-left:30.0pt">
<p class="MsoNormal" style="margin-left:35.4pt">sip_msg_shm_clone(496): 959632704<br>
counters_prefork_init(207): 61440<br>
cfg_clone_str(130): 392<br>
cfg_shmize(217): 1496<br>
main_loop(1295): 8<br>
init_pt(113): 8<br>
init_pt(108): 8<br>
init_pt(107): 5920<br>
cfg_parse_str(906): 80<br>
register_timer(1012): 432<br>
cfg_register_ctx(47): 96<br>
init_tcp(4714): 8192<br>
init_tcp(4708): 32768<br>
init_tcp(4700): 8<br>
init_tcp(4693): 8<br>
init_tcp(4686): 8<br>
init_tcp(4680): 8<br>
init_tcp(4668): 8<br>
init_avps(90): 8<br>
init_avps(89): 8<br>
init_dst_blacklist(437): 16384<br>
init_dst_blacklist(430): 8<br>
timer_alloc(515): 96<br>
init_dns_cache(358): 8<br>
init_dns_cache(350): 16384<br>
init_dns_cache(343): 16<br>
init_dns_cache(336): 8<br>
init_timer(284): 8<br>
init_timer(283): 16384<br>
init_timer(282): 8<br>
init_timer(281): 8<br>
init_timer(270): 8<br>
init_timer(238): 8<br>
init_timer(221): 278544<br>
init_timer(220): 8<br>
init_timer(207): 8<br>
cfg_child_cb_new(828): 64<br>
sr_cfg_init(360): 8<br>
sr_cfg_init(353): 8<br>
sr_cfg_init(346): 8<br>
sr_cfg_init(334): 8<br>
sr_cfg_init(322): 8<br>
qm_shm_lock_init(1202): 8<br>
Total: 960071600<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt">}<br>
Module: dmq<br>
{<o:p></o:p></p>
<div style="margin-left:30.0pt">
<p class="MsoNormal" style="margin-left:35.4pt">alloc_job_queue(250): 64<br>
shm_str_dup(723): 48<br>
build_dmq_node(164): 896<br>
add_peer(68): 312<br>
mod_init(240): 8<br>
mod_init(233): 48<br>
init_dmq_node_list(70): 24<br>
init_peer_list(33): 24<br>
job_queue_push(286): 15369848<br>
Total: 15371272<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt">}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">From GDB I could see both workers were stuck here:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt">Thread 1 (Thread 0x7f4a3cba7740 (LWP 17401)):<br>
#0 0x00007f4a3c29dbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007f49f1a44bdd in futex_get (lock=0x7fff1d14f564) at ../../core/futexlock.h:121<br>
#2 0x00007f49f1a4fe57 in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657<br>
mypid = 17401<br>
index = 2543<br>
entry = {first = 0x0, last = 0x0, next_id = 107271, lock = {val = 2}, locker_pid = {val = 17393}, rec_lock_level = 0}<br>
dlg = 0x0<br>
__FUNCTION__ = "dmq_send_all_dlgs"<br>
#3 0x00007f49f1a4c000 in dlg_dmq_handle_msg (msg=0x7f49fe88b2b8, resp=0x7fff1d14f8e0, node=0x7f49fd4be5d8) at dlg_dmq.c:391<br>
#4 0x00007f49f25da34a in worker_loop (id=1) at worker.c:113<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">#5 0x00007f49f25d7d35 in child_init (rank=0) at dmq.c:300<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Thread 1 (Thread 0x7f4a3cba7740 (LWP 17400)):<br>
#0 0x00007f4a3c29dbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007f49f1a44bdd in futex_get (lock=0x7fff1d14f564) at ../../core/futexlock.h:121<br>
#2 0x00007f49f1a4fe57 in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657<br>
mypid = 17400<br>
index = 1080<br>
entry = {first = 0x7f49fe575ad0, last = 0x7f49fe575ad0, next_id = 54971, lock = {val = 2}, locker_pid = {val = 17385}, rec_lock_level = 0}<br>
dlg = 0x0<br>
__FUNCTION__ = "dmq_send_all_dlgs"<br>
#3 0x00007f49f1a4c000 in dlg_dmq_handle_msg (msg=0x7f49fe437878, resp=0x7fff1d14f8e0, node=0x7f49fd4be5d8) at dlg_dmq.c:391<br>
#4 0x00007f49f25da34a in worker_loop (id=0) at worker.c:113<br>
#5 0x00007f49f25d7d35 in child_init (rank=0) at dmq.c:300<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">From my analysis, it seems memory was increasing because every new call was adding a new job to the dmq workers queue but the workers were stuck in the mutex not consuming the jobs. We could not figure out which
process had the mutex, because from GDB the locker_pid had an UDP process and a timer process, but both seemed to be just waiting in normal operation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Also, I didn't create a ticket because 5.2 is deprecated, but I found it worth reporting this potential problem in the list since it looks like the code for the DMQ is similar between 5.4 and 5.2.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On Tue, 27 Oct 2020 at 09:22, Patrick Wakano <<a href="mailto:pwakano@gmail.com">pwakano@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Hello list,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Hope all are doing well!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">We are running load tests in our Kamailio server, that is just making inbound and outbound calls and eventually (there is no identified pattern) Kamailio freezes and of course all calls start to fail. It does
not crash, it just stops responding and it has to be killed -9. When this happens, SIP messages are not processed, dmq keepalive fails (so the other node reports as down), dialog KA are not sent, but Registrations from UAC seem to still go out (logs from local_route
are seen).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">We don't have a high amount of cps, it is max 3 or 4 per sec, and it gets around 1900 active calls. We are now using Kamailio 5.2.8 installed from the repo on a CentOS7 server. Dialog has KA active and DMQ (with
2 workers) is being used on an active-active instance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">From investigation using GDB as pasted below, I can see UDP workers are stuck on a lock either on a callback from t_relay...<br>
<span style="font-family:"Courier New"">#0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007ffb2b1bce08 in futex_get (lock=0x7ffb35217b90) at ../../core/futexlock.h:108<br>
#2 0x00007ffb2b1bec44 in bcast_dmq_message1 (peer=0x7ffb35e8bf38, body=0x7fff2e95ffb0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>, incl_inactive=0) at dmq_funcs.c:156<br>
#3 0x00007ffb2b1bf46b in bcast_dmq_message (peer=0x7ffb35e8bf38, body=0x7fff2e95ffb0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>) at dmq_funcs.c:188<br>
#4 0x00007ffb2a6448fa in dlg_dmq_send (body=0x7fff2e95ffb0, node=0x0) at dlg_dmq.c:88<br>
#5 0x00007ffb2a64da5d in dlg_dmq_replicate_action (action=DLG_DMQ_UPDATE, dlg=0x7ffb362ea3c8, needlock=1, node=0x0) at dlg_dmq.c:628<br>
#6 0x00007ffb2a61f28e in dlg_on_send (t=0x7ffb36c98120, type=16, param=0x7fff2e9601e0) at dlg_handlers.c:739<br>
#7 0x00007ffb2ef285b6 in run_trans_callbacks_internal (cb_lst=0x7ffb36c98198, type=16, trans=0x7ffb36c98120, params=0x7fff2e9601e0) at t_hooks.c:260<br>
#8 0x00007ffb2ef286d0 in run_trans_callbacks (type=16, trans=0x7ffb36c98120, req=0x7ffb742f27e0, rpl=0x0, code=-1) at t_hooks.c:287<br>
#9 0x00007ffb2ef38ac1 in prepare_new_uac (t=0x7ffb36c98120, i_req=0x7ffb742f27e0, branch=0, uri=0x7fff2e9603e0, path=0x7fff2e9603c0, next_hop=0x7ffb742f2a58, fsocket=0x7ffb73e3e968, snd_flags=..., fproto=0, flags=2, instance=0x7fff2e9603b0, ruid=0x7fff2e9603a0,
location_ua=0x7fff2e960390) at t_fwd.c:381<br>
#10 0x00007ffb2ef3d02d in add_uac (t=0x7ffb36c98120, request=0x7ffb742f27e0, uri=0x7ffb742f2a58, next_hop=0x7ffb742f2a58, path=0x7ffb742f2e20, proxy=0x0, fsocket=0x7ffb73e3e968, snd_flags=..., proto=0, flags=2, instance=0x7ffb742f2e30, ruid=0x7ffb742f2e48,
location_ua=0x7ffb742f2e58) at t_fwd.c:811<br>
#11 0x00007ffb2ef4535a in t_forward_nonack (t=0x7ffb36c98120, p_msg=0x7ffb742f27e0, proxy=0x0, proto=0) at t_fwd.c:1699<br>
#12 0x00007ffb2ef20505 in t_relay_to (p_msg=0x7ffb742f27e0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:334</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Arial",sans-serif">or loose_route...</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Courier New"">#0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007ffb2b1bce08 in futex_get (lock=0x7ffb35217b90) at ../../core/futexlock.h:108<br>
#2 0x00007ffb2b1bec44 in bcast_dmq_message1 (peer=0x7ffb35e8bf38, body=0x7fff2e9629d0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>, incl_inactive=0) at dmq_funcs.c:156<br>
#3 0x00007ffb2b1bf46b in bcast_dmq_message (peer=0x7ffb35e8bf38, body=0x7fff2e9629d0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>) at dmq_funcs.c:188<br>
#4 0x00007ffb2a6448fa in dlg_dmq_send (body=0x7fff2e9629d0, node=0x0) at dlg_dmq.c:88<br>
#5 0x00007ffb2a64da5d in dlg_dmq_replicate_action (action=DLG_DMQ_STATE, dlg=0x7ffb363e0c10, needlock=0, node=0x0) at dlg_dmq.c:628<br>
#6 0x00007ffb2a62b3bf in dlg_onroute (req=0x7ffb742f11d0, route_params=0x7fff2e962ce0, param=0x0) at dlg_handlers.c:1538<br>
#7 0x00007ffb2e7db203 in run_rr_callbacks (req=0x7ffb742f11d0, rr_param=0x7fff2e962d80) at rr_cb.c:96<br>
#8 0x00007ffb2e7eb2f9 in after_loose (_m=0x7ffb742f11d0, preloaded=0) at loose.c:945<br>
#9 0x00007ffb2e7eb990 in loose_route (_m=0x7ffb742f11d0) at loose.c:979</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Arial",sans-serif">or t_check_trans:</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Courier New"">#0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007ffb2a5ea9c6 in futex_get (lock=0x7ffb35e78804) at ../../core/futexlock.h:108<br>
#2 0x00007ffb2a5f1c46 in dlg_lookup_mode (h_entry=1609, h_id=59882, lmode=0) at dlg_hash.c:709<br>
#3 0x00007ffb2a5f27aa in dlg_get_by_iuid (diuid=0x7ffb36326bd0) at dlg_hash.c:777<br>
#4 0x00007ffb2a61ba1d in dlg_onreply (t=0x7ffb36952988, type=2, param=0x7fff2e963bf0) at dlg_handlers.c:437<br>
#5 0x00007ffb2ef285b6 in run_trans_callbacks_internal (cb_lst=0x7ffb36952a00, type=2, trans=0x7ffb36952988, params=0x7fff2e963bf0) at t_hooks<br>
.c:260<br>
#6 0x00007ffb2ef286d0 in run_trans_callbacks (type=2, trans=0x7ffb36952988, req=0x7ffb3675c360, rpl=0x7ffb742f1930, code=200) at t_hooks.c:28<br>
7<br>
#7 0x00007ffb2ee7037f in t_reply_matching (p_msg=0x7ffb742f1930, p_branch=0x7fff2e963ebc) at t_lookup.c:997<br>
#8 0x00007ffb2ee725e4 in t_check_msg (p_msg=0x7ffb742f1930, param_branch=0x7fff2e963ebc) at t_lookup.c:1101</span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Courier New"">#9 0x00007ffb2eee44c7 in t_check_trans (msg=0x7ffb742f1930) at tm.c:2351</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">And the DMQ workers are here:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span style="font-family:"Courier New"">#0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6<br>
#1 0x00007ffb2b1d6c81 in futex_get (lock=0x7ffb35217c34) at ../../core/futexlock.h:108<br>
#2 0x00007ffb2b1d7c3a in worker_loop (id=1) at worker.c:86<br>
#3 0x00007ffb2b1d5d35 in child_init (rank=0) at dmq.c:300</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Currently I will not be able to upgrade to latest 5.4 version to try to reproduce the error and since 5.2.8 has already reached end-of-life, maybe is there anything I can do on the configuration to avoid such
condition?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Any ideas are welcome!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Kind regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Patrick Wakano<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>