<html xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body><div>While I Should be filing a Jira, but the problem remains even is using ODBC with or without MySQL. Only then using Sqlite this behavior does not happen. Seems like FS looses track of channels and not cleaning up from the DB, and new channels also coming up at the same time. But I observed if traffic is stopped being sent to FS, all the channels from the DB eventually die. Maybe RTP timeout or something?
</div><div><br></div><div><br></div><div class="unibox-signature">Sent with <a href="http://www.uniboxapp.com/t/sig">Unibox</a>
</div><div><br></div><blockquote type="cite" class="unibox-hidden"><div>On Jun 13, 2014, at 12:01 AM, Victor Chukalovskiy &lt;victor.chukalovskiy@gmail.com&gt; wrote:
</div><div><br></div><div>Greetings.
</div><div><br></div><div>Just found this thread. I also observe issues with postgres. In my case,<br>trying to use mod_lcr with core postgresql (postgres dsn instead of odbc<br>dsn):
</div><div><br></div><div>-at first it works like a charm and able to do 200-400 CPS of LCR queries<br>-after a period of time (from a minute to a few hours depending on the<br>load) it drops to marginal 45 CPS.<br>-calls keep piling-up to whatever limit I set in my sipp
</div><div><br></div><div>After that nothing brings FS back to desired 200-400 queries, it stays<br>at ~45 CPS no matter what:<br>-restarting PostgreSQL does not help<br>-restarting mod_lcr does not help<br>-letting FS idle with 0 calls for a few minutes does not help
</div><div><br></div><div>When this happens I observe a build-up of idle PG connections, but it<br>never reaches max_connections set on the PG end. So, I suspect the<br>issues is in FS core rather than PG. The only thing that brings it back<br>to high CPS throughput is a full restart of FS. I'm starting to think<br>that core postgres support is poorly implemented
</div><div><br></div><div>And here is a note from Brian on FS-6582:
</div><div><br></div><blockquote><div>I vote for the complete removal of CORE PGSQL Support as its<br>incomplete and has bugs.
</div><div><br></div><div>/b
</div><div><br></div></blockquote><div><br></div><div>Does anyone have a similar experience or have confirmation of core pg<br>support being not reliable?
</div><div><br></div><div>Cheers,<br>-Victor
</div><div><br></div><div>On 14-06-05 08:59 PM, Ken Rice wrote:
</div><div><br></div><blockquote><div>you'll probably want to open a jira on this and make sure you include<br>all the good logging..
</div><div><br></div><div>Ken<br>Sent from my iPad
</div><div><br></div><div>On Jun 5, 2014, at 17:49, Muhammad Naseer Bhatti &lt;nbhatti@gmail.com<br>&lt;mailto:nbhatti@gmail.com&gt;&gt; wrote:
</div><div><br></div><blockquote><div>Hi, I am using Postgres in the core as well as for mod_db because the<br>limit subsystem needs to be shared with other hosts
</div><div><br></div><div>for mod_db<br>&lt;param name="odbc-dsn" value="pgsql://hostaddr=remote_host port=15432<br>dbname=freeswitch user=freeswitch password=freeswitch options='-c<br>client_min_messages=NOTICE'" /&gt;<br>and with switch.conf<br>&lt;param name="core-db-dsn" value="pgsql://hostaddr=remote_host<br>port=15432 dbname=freeswitch user=freeswitch password=freeswitch<br>options='-c client_min_messages=NOTICE'" /&gt;
</div><div><br></div><div>DB host has a latency of 27 ms from FreeSWITCH server. Channels keep<br>on piling up until the max_session limit is reached and the switch<br>does not accept any more channels. Seems like the channel info is not<br>being released from the database. Even now I have stopped sending any<br>calls, the switch still shows 7000+ channels connected. Offcourse<br>that's the database only. But why this is happening?
</div><div><br></div><div>freeswitch@internal&gt; show calls count
</div><div><br></div><div><br></div><div>7260 total.
</div><div><br></div><div><br></div><div>freeswitch@internal&gt; status
</div><div><br></div><div>UP 0 years, 0 days, 0 hours, 24 minutes, 54 seconds, 940<br>milliseconds, 636 microseconds
</div><div><br></div><div>FreeSWITCH (Version 1.4.6 git 9479729 2014-06-03 19:35:16Z 64bit) is<br>ready
</div><div><br></div><div>12884 session(s) since startup
</div><div><br></div><div>0 session(s) - peak 10000, last 5min 0
</div><div><br></div><div>0 session(s) per Sec out of max 500, peak 89, last 5min 0
</div><div><br></div><div>10000 session(s) max
</div><div><br></div><div>min idle cpu 0.00/99.83
</div><div><br></div><div>Current Stack Size/Max 240K/8192K
</div><div><br></div><div><br></div><div>show channels shows
</div><div><br></div><div>0d01315c-ed00-11e3-a7c7-dfbcc3672627,inbound,2014-06-05<br>18:23:42,1402007022,sofia/Profile_250.218/vGriffins@88.208.219.118<br>&lt;mailto:sofia/Profile_250.218/vGriffins@88.208.219.118&gt;:5050,CS_EXECUTE,vGriffins,123456789,88.208.219.118,4414732506,,,RINGING,,,,,vBilling,,,,,,,,,,,,,,,,,,,,,
</div><div><br></div><div><br></div><div><br></div><div>But when I try to kill that uuid,
</div><div><br></div><div>freeswitch@internal&gt; uuid_kill 0d01315c-ed00-11e3-a7c7-dfbcc3672627
</div><div><br></div><div>-ERR No such channel!
</div><div><br></div><div><br></div><div>I am not sure what's going on except something is not allowing for<br>the channels to be cleared from the database. I also have tried<br>rtp-timer-name =soft and session-timeout=10 with enable-timer=true,<br>but that does not helps. What should I look for now?
</div><div><br></div><div>Thanks.
</div><div><br></div><div>Sent with Unibox &lt;http://www.uniboxapp.com/t/sig&gt;<br>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br>consulting@freeswitch.org &lt;mailto:consulting@freeswitch.org&gt;<br>http://www.freeswitchsolutions.com
</div><div><br></div><div>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com
</div><div><br></div><div>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com
</div><div><br></div><div>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>&lt;mailto:FreeSWITCH-users@lists.freeswitch.org&gt;<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>&lt;http://lists.freeswitch.org/mailman/options/freeswitch-users&gt;<br>http://www.freeswitch.org
</div><div><br></div></blockquote><div><br></div><div><br></div><div>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br>consulting@freeswitch.org<br>http://www.freeswitchsolutions.com
</div><div><br></div><div>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com
</div><div><br></div><div>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com
</div><div><br></div><div>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org
</div><div><br></div></blockquote><div><br></div><div class="moz-cite-prefix">Greetings.<br><br>Just found this thread. I also observe issues with postgres. In my case, trying to use mod_lcr with core postgresql (postgres dsn instead of odbc dsn):<br><br>-at first it works like a charm and able to do 200-400 CPS of LCR queries<br>-after a period of time (from a minute to a few hours depending on the load) it drops to marginal 45 CPS.<br>-calls keep piling-up to whatever limit I set in my sipp<br><br>After that nothing brings FS back to desired 200-400 queries, it stays at ~45 CPS no matter what:<br>-restarting PostgreSQL does not help<br>-restarting mod_lcr does not help<br>-letting FS idle with 0 calls for a few minutes does not help<br><br>When this happens I observe a build-up of idle PG connections, but it never reaches max_connections set on the PG end. So, I suspect the issues is in FS core rather than PG. The only thing that brings it back to high CPS throughput is a full restart of FS. I'm starting to think that core postgres support is poorly implemented<br><br>And here is a note from Brian on FS-6582:<br><br><blockquote type="cite">I vote for the complete removal of CORE PGSQL Support as its incomplete and has bugs.<br><br>/b
</blockquote><br>Does anyone have a similar experience or have confirmation of core pg support being not reliable?<br><br>Cheers,<br>-Victor<br><pre class="moz-signature" cols="72"></pre>On 14-06-05 08:59 PM, Ken Rice wrote:<br>
</div><blockquote cite="mid:B0F01F7B-5A5E-40F7-A094-32E5D180B5CA@freeswitch.org" type="cite"><div>you'll probably want to open a jira on this and make sure you include all the good logging..<br><br><div>Ken
</div>Sent from my iPad
</div><div><br>On Jun 5, 2014, at 17:49, Muhammad Naseer Bhatti &lt;<a moz-do-not-send="true" href="mailto:nbhatti@gmail.com">nbhatti@gmail.com</a>&gt; wrote:<br><br>
</div><blockquote type="cite"><div><div>Hi, I am using Postgres in the core as well as for mod_db because the limit subsystem needs to be shared with other hosts
</div><div><br></div><div>for mod_db
</div><div>&lt;param name=“odbc-dsn” value="pgsql://hostaddr=remote_host port=15432 dbname=freeswitch user=freeswitch password=freeswitch options='-c client_min_messages=NOTICE'" /&gt;
</div><div>and with switch.conf
</div><div>&lt;param name=“core-db-dsn” value=“pgsql://hostaddr=remote_host port=15432 dbname=freeswitch user=freeswitch password=freeswitch options=‘-c client_min_messages=NOTICE’” /&gt;<br>
</div><div><br></div><div>DB host has a latency of 27 ms from FreeSWITCH server. Channels keep on piling up until the max_session limit is reached and the switch does not accept any more channels. Seems like the channel info is not being released from the database. Even now I have stopped sending any calls, the switch still shows 7000+ channels connected. Offcourse that’s the database only. But why this is happening? 
</div><div><br></div><div><div>freeswitch@internal&gt; show calls count
</div><div><br></div><div>7260 total.
</div><div><br></div><div>freeswitch@internal&gt; status
</div><div>UP 0 years, 0 days, 0 hours, 24 minutes, 54 seconds, 940 milliseconds, 636 microseconds
</div><div>FreeSWITCH (Version 1.4.6 git 9479729 2014-06-03 19:35:16Z 64bit) is ready
</div><div>12884 session(s) since startup
</div><div>0 session(s) - peak 10000, last 5min 0 
</div><div>0 session(s) per Sec out of max 500, peak 89, last 5min 0 
</div><div>10000 session(s) max
</div><div>min idle cpu 0.00/99.83
</div><div>Current Stack Size/Max 240K/8192K
</div></div><div><br></div><div>show channels shows 
</div><div><br></div><div><div>0d01315c-ed00-11e3-a7c7-dfbcc3672627,inbound,2014-06-05 18:23:42,1402007022,<a moz-do-not-send="true" href="mailto:sofia/Profile_250.218/vGriffins@88.208.219.118">sofia/Profile_250.218/vGriffins@88.208.219.118</a>:5050,CS_EXECUTE,vGriffins,123456789,88.208.219.118,4414732506,,,RINGING,,,,,vBilling,,,,,,,,,,,,,,,,,,,,,
</div></div><div><br></div><div>But when I try to kill that uuid, 
</div><div><br></div><div><div>freeswitch@internal&gt; uuid_kill 0d01315c-ed00-11e3-a7c7-dfbcc3672627
</div><div>-ERR No such channel!
</div></div><div><br></div><div>I am not sure what’s going on except something is not allowing for the channels to be cleared from the database. I also have tried rtp-timer-name  =soft and session-timeout=10 with enable-timer=true, but that does not helps. What should I look for now?
</div><div><br></div><div>Thanks.
</div><div><br></div><div class="unibox-signature">Sent with <a moz-do-not-send="true" href="http://www.uniboxapp.com/t/sig">Unibox</a>
</div></div></blockquote><blockquote type="cite"><div><span>_________________________________________________________________________</span><br><span>Professional FreeSWITCH Consulting Services:</span><br><span><a moz-do-not-send="true" href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a></span><br><span><a moz-do-not-send="true" href="http://www.freeswitchsolutions.com">http://www.freeswitchsolutions.com</a></span><br><br><span>FreeSWITCH-powered IP PBX: The CudaTel Communication Server</span><br><span><a moz-do-not-send="true" href="http://www.cudatel.com">http://www.cudatel.com</a></span><br><br><span>Official FreeSWITCH Sites</span><br><span><a moz-do-not-send="true" href="http://www.freeswitch.org">http://www.freeswitch.org</a></span><br><span><a moz-do-not-send="true" href="http://wiki.freeswitch.org">http://wiki.freeswitch.org</a></span><br><span><a moz-do-not-send="true" href="http://www.cluecon.com">http://www.cluecon.com</a></span><br><br><span>FreeSWITCH-users mailing list</span><br><span><a moz-do-not-send="true" href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a></span><br><span><a moz-do-not-send="true" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a></span><br><span>UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://">http://</a><a moz-do-not-send="true" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">lists.freeswitch.org/mailman/options/freeswitch-users</a></span><br><span><a moz-do-not-send="true" href="http://www.freeswitch.org">http://www.freeswitch.org</a></span><br></div></blockquote><br><fieldset class="mimeAttachmentHeader"></fieldset><br><pre wrap="">_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
<a class="moz-txt-link-abbreviated" href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitchsolutions.com">http://www.freeswitchsolutions.com</a>

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
<a class="moz-txt-link-freetext" href="http://www.cudatel.com">http://www.cudatel.com</a>

Official FreeSWITCH Sites
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://wiki.freeswitch.org">http://wiki.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://www.cluecon.com">http://www.cluecon.com</a>

FreeSWITCH-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>








</pre></blockquote><br><div>_________________________________________________________________________<br>Professional FreeSWITCH Consulting Services:<br>consulting@freeswitch.org<br>http://www.freeswitchsolutions.com
</div><div><br></div><div>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>http://www.cudatel.com
</div><div><br></div><div>Official FreeSWITCH Sites<br>http://www.freeswitch.org<br>http://wiki.freeswitch.org<br>http://www.cluecon.com
</div><div><br></div><div>FreeSWITCH-users mailing list<br>FreeSWITCH-users@lists.freeswitch.org<br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org
</div><div><br></div></blockquote></body></html>