[Freeswitch-users] unexplained RAM usage increase

Wed Jan 30 02:32:07 MSK 2013

Were are you getting the package from? 1.3 is on 13 right now so 4 is a bit
too old.
Can you build HEAD from source and reproduce a log you can post to jira?

On Tue, Jan 29, 2013 at 5:15 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:

> I gave you bad information before.  It does happen with just one or two
> calls, it just takes a long time.  Valgrind was not an option on the
> embedded box  I was able to reproduce the issue on a regular x86_64 machine
> running squeeze, FreeSWITCH Version 1.3.4-n20130128T034121Z-1~squeeze+1
> (-n20130128T034121Z-1~squeeze+1).
>
> I have the vg.log file produced with two calls up for approximately 35
> minutes.  No other SIP activity occurred during that time period.  Is it
> Jira time, or is there other data you'd like to see?
>
>
> - Jeff
>
>
> On Tue, Jan 29, 2013 at 12:04 PM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> Can you systematically increase the current call count and see where you
>> do see something?
>> On a system with limited ram you can also consider stripping all the .so
>> files in the mods and lib dir but you will need to put non-stripped ones in
>> for any debugging.
>>
>> I don't really see a correlation on how not using a timer could trigger
>> an sustained memory increase so that's why I'd like you to step up the
>> number and see if you can find a number of calls that tops out because
>> usually there always is a magic number where it will hover and go up and
>> down a meg at a time.
>>
>> SIP calls are required to keep state data around for at least 30 seconds
>> after a call ends and there are a number of pools in the code that inflate
>> once and do not return the memory.  Its usually possible to identify the
>> high watermark on a particular box.
>>
>> For instance the machine we host the conference call on launches using 25
>> megs and hovers at about 350 megs once it has accumulated all the pool
>> memory it needs over time.
>>
>>
>>
>>
>>
>> On Tue, Jan 29, 2013 at 8:33 AM, Jeff Pyle <jpyle at fidelityvoice.com>wrote:
>>
>>> Version:
>>>   FreeSWITCH version: 1.3.4-n20130122T122521Z-1~squeeze+1
>>> (-n20130122T122521Z-1~squeeze+1)
>>>
>>> The calls are bridged, from one sofia profile to another.
>>>
>>> Unfortunately two concurrent calls doesn't seem to trigger the same
>>> behavior.
>>>
>>>
>>> - Jeff
>>>
>>>
>>> On Mon, Jan 28, 2013 at 11:21 PM, Ken Rice <krice at freeswitch.org> wrote:
>>>
>>>>  Ok the package timestamps/versions there don’t do us a lot of good,
>>>> we need to know the version line from the FreeSWITCH CLI..
>>>>
>>>>
>>>> On 1/28/13 9:59 PM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:
>>>>
>>>> I just updated from repo.profhost.eu <http://repo.profhost.eu> .  The
>>>> most recent timestamp on the packages was 2013-01-28 03:41:21 GMT.  Same
>>>> behavior.  At 5 minutes it was using 12.5% RAM.  At 40 minutes, 60.4%.
>>>>  After disconnecting the calls the usage returned to 8.5%.
>>>>
>>>>
>>>> I started toggling config items to see if I could impact this.  I found
>>>> one that seems to have an effect:  rtp-timer-name in the sofia profile
>>>> config.  By changing it from 'soft' to 'none', the CPU utilization with 30
>>>> calls dropped from ~70% to ~46%, and the RAM usage is rock solid at 5.8%.
>>>>
>>>> That's great, but does it make any sense?
>>>>
>>>> Does an rtp-timer-name of 'none' pose any risks?
>>>>
>>>>
>>>>
>>>> - Jeff
>>>>
>>>>
>>>>
>>>> On Mon, Jan 28, 2013 at 8:43 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>>> wrote:
>>>>
>>>> It's on Voyage Linux, a cousin of Debian.  I believe it uses glibc.
>>>>
>>>>
>>>> - Jeff
>>>>
>>>>
>>>> On Mon, Jan 28, 2013 at 6:45 PM, Kristian Kielhofner <kris at kriskinc.com>
>>>> wrote:
>>>>
>>>> Out of curiosity does your distro use uclibc, eglibc, or glibc?
>>>>
>>>> On Mon, Jan 28, 2013 at 5:41 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>>> wrote:
>>>> > Hello,
>>>> >
>>>> > I'm running HEAD version from Jan 22 on an Alix board with an AMD
>>>> Geode LX
>>>> > processor (i386).  I can sustain 30 concurrent calls averaging around
>>>> 70%
>>>> > CPU utilization by the freeswitch process, measured by top.  Bypass
>>>> media
>>>> > and proxy media are disabled.  PCMU is forced on both endpoints (no
>>>> > transcoding).
>>>> >
>>>> > The problem is the RAM usage over time.  The board has 256M.  Idle,
>>>> > freeswitch occupies around 4% after a fresh restart.  A minute or so
>>>> after
>>>> > 30 calls are nailed up the RAM usage is about 7.2%.  After 5 minutes,
>>>> 13.6%.
>>>> > After 60 minutes, near 65%.  Disconnecting the calls returns the RAM
>>>> usage
>>>> > to 6-8%.
>>>> >
>>>> > I've not tried to troubleshoot an issue like this before.  Is
>>>> valgrind the
>>>> > next step, or would something else make more sense?
>>>> >
>>>> >
>>>> > Regards,
>>>> > Jeff
>>>>
>>>>
>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130129/1b572aa8/attachment-0001.html 