<div dir="ltr"><div>OK runtime debugging shows something is wrong with dialog module, all 6 processes are locked in trying to access dialog module when 200 OK is received for the call. For example, here is the BT of one the processes,<br><br>--<br>#0  0xb77a0424 in __kernel_vsyscall ()<br>#1  0xb76c140c in sched_yield () from /lib/i386-linux-gnu/i686/cmov/libc.so.6<br>#2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277<br>#3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11302) at dlg_hash.c:610<br>#4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa598a2b0) at dlg_hash.c:643<br>#5  0xb5a14143 in dlg_onreply (t=0xa5989358, type=2, param=0xbff3a0ac) at dlg_handlers.c:429<br>#6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5989398, type=2, trans=0xa5989358, params=0xbff3a0ac) at t_hooks.c:268<br>#7  0xb5f781a3 in run_trans_callbacks (type=2, trans=0xa5989358, req=0xa598a308, rpl=0xb68cc6e8, code=200) at t_hooks.c:295<br>#8  0xb5f84b14 in t_reply_matching (p_msg=0xb68cc6e8, p_branch=0xbff3a5a4) at t_lookup.c:966<br>#9  0xb5f868c4 in t_check_msg (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4) at t_lookup.c:1069<br>#10 0xb5f871fd in t_check (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4) at t_lookup.c:1111<br>#11 0xb5fc9b4e in reply_received (p_msg=0xb68cc6e8) at t_reply.c:2134<br>#12 0x080c9142 in do_forward_reply (msg=0xb68cc6e8, mode=0) at forward.c:747<br>#13 0x080ca61c in forward_reply (msg=0xb68cc6e8) at forward.c:849<br>#14 0x08138aab in receive_msg (<br>    buf=0x840f6c0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP X.X.X.X;rport=5060;branch=z9hG4bK719e.844788c1e820e6096cb00d2b2f6c613d.0\r\nVia: SIP/2.0/UDP 192.168.3.10;received=Y.Y.Y.Y;rport=5060;branch=z9hG4bKlzzjpctt\r\nRe"..., len=1103, rcv_info=0xbff3a93c) at receive.c:255<br>#15 0x082188d0 in udp_rcv_loop () at udp_server.c:495<br>#16 0x080dec65 in main_loop () at main.c:1573<br>#17 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533<br>--<br><br></div>Here is BT of second process,<br><br>--<br>#0  0xb77a0424 in __kernel_vsyscall ()<br>#1  0xb76c140c in sched_yield () from /lib/i386-linux-gnu/i686/cmov/libc.so.6<br>#2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277<br>#3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11301) at dlg_hash.c:610<br>#4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa5985060) at dlg_hash.c:643<br>#5  0xb5a140c4 in dlg_ontdestroy (t=0xa5985424, type=131072, param=0xbff3a7ac) at dlg_handlers.c:398<br>#6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5985464, type=131072, trans=0xa5985424, params=0xbff3a7ac) at t_hooks.c:268<br>#7  0xb5f781a3 in run_trans_callbacks (type=131072, trans=0xa5985424, req=0x0, rpl=0x0, code=0) at t_hooks.c:295<br>#8  0xb5f3cbbb in free_cell (dead_cell=0xa5985424) at h_table.c:128<br>#9  0xb5f7cb20 in wait_handler (ti=1848316837, wait_tl=0xa598546c, data=0xa5985424) at timer.c:648<br>#10 0x0820d8f8 in timer_list_expire (t=1848316837, h=0xa530e718, slow_l=0xa530e7ec, slow_mark=6) at timer.c:873<br>#11 0x0820dcc0 in timer_handler () at timer.c:938<br>#12 0x0820e0d8 in timer_main () at timer.c:977<br>#13 0x080df4e0 in main_loop () at main.c:1644<br>#14 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533<br>--<br><div><br></div><div>Does this makes any sense to you? Let me know if you need anything else.<br><br></div><div>Thank you.<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 11:36 AM, M S <span dir="ltr"><<a href="mailto:shaheryarkh@gmail.com" target="_blank">shaheryarkh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Sure, here is the list of module in given order,<br><br>--<br>loadmodule "db_mysql.so"<br>loadmodule "mi_fifo.so"<br>loadmodule "mi_datagram.so"<br>loadmodule "kex.so"<br>loadmodule "corex.so"<br>loadmodule "tm.so"<br>loadmodule "tmx.so"<br>loadmodule "sl.so"<br>loadmodule "outbound.so"<br>loadmodule "rr.so"<br>loadmodule "path.so"<br>loadmodule "pv.so"<br>loadmodule "maxfwd.so"<br>loadmodule "usrloc.so"<br>loadmodule "registrar.so"<br>loadmodule "sdpops.so"<br>loadmodule "textops.so"<br>loadmodule "textopsx.so"<br>loadmodule "siputils.so"<br>loadmodule "xlog.so"<br>loadmodule "sanity.so"<br>loadmodule "ctl.so"<br>loadmodule "cfg_rpc.so"<br>loadmodule "mi_rpc.so"<br>loadmodule "dialog.so"<br>loadmodule "acc.so"<br>loadmodule "uac.so"<br>loadmodule "rtimer.so"<br>loadmodule "sqlops.so"<br>loadmodule "ndb_redis.so"<br>loadmodule "app_perl.so"<br>loadmodule "permissions.so"<br>loadmodule "domain.so"<br>loadmodule "async.so"<br>loadmodule "stun.so"<br>loadmodule "auth.so"<br>loadmodule "auth_db.so"<br>loadmodule "alias_db.so"<br>loadmodule "speeddial.so"<br>loadmodule "presence.so"<br>loadmodule "presence_mwi.so"<br>loadmodule "presence_xml.so"<br>loadmodule "presence_profile.so"<br>loadmodule "nathelper.so"<br>loadmodule "rtpengine.so"<br>loadmodule "tls.so"<br>loadmodule "htable.so"<br>loadmodule "pike.so"<br>loadmodule "xmlrpc.so"<br>loadmodule "debugger.so"<br>loadmodule "xhttp.so"<br>loadmodule "xhttp_rpc.so"<br>loadmodule "xhttp_pi.so"<br>loadmodule "xcap_server.so"<br>loadmodule "pua.so"<br>loadmodule "pua_mi.so"<br>loadmodule "rls.so"<br>loadmodule "cfgutils.so"<br>loadmodule "htable.so"<br>loadmodule "msrp.so"<br>loadmodule "websocket.so"<br>loadmodule "msilo.so"<br>loadmodule "siptrace.so"<br>--<br><br></div><div>In "top" i see at least 6 kamailio processes using very high cpu (perhaps these are the 6 child processes involved in that single call processing).<br></div><div><br></div>Thank you.<br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Sep 14, 2015 at 11:28 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    I will review the changes pushed to 4.3.2 vs 4.3.1. Can you send
    here the list of modules you are using? The loadmodule lines in
    kamailio.cfg.<br>
    <br>
    Cheers,<br>
    Daniel<div><div><br>
    <br>
    <div>On 14/09/15 10:51, M S wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div>
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>Hi,<br>
                <br>
              </div>
              Over last weekend i upgraded one of my test servers from
              Kamailio v4.3.1-4d1b65 to latest stable release
              v4.3.2-07690f and now kamailio goes crazy even with single
              call (I am using same db and configuration of course).<br>
              <br>
            </div>
            As soon as call establishes system load average (as seen in
            top command) starts increasing and soon it increases beyond
            6.0 and system becomes completely unresponsive, sip messages
            are no longer being processed by kamailio service. Even
            after call hangup, system remains under high load. The
            "htop" indicates that IO Wait time has increased
            substantially.<br>
            <br>
          </div>
          Any idea what is causing this? For now i have reverted by to
          v4.3.1-4d1b65 but can go to v4.3.2-07690f again if you need
          further info or testing.<br>
          <br>
        </div>
        Thank you.<br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><span><font color="#888888">
</font></span></pre><span><font color="#888888">
    </font></span></blockquote><span><font color="#888888">
    <br>
    <pre cols="72">-- 
Daniel-Constantin Mierla
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a></pre>
  </font></span></div>

<br></div></div>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>