[Freeswitch-users] unexplained RAM usage increase

[Jeff Pyle]

I installed via apt-get from http://repo.profhost.eu/debian.

The same issue occurs on a fresh download from HEAD, yielding v1.3.13b.
 Jira FS-5065 <http://jira.freeswitch.org/browse/FS-5065>.  Log uploads to
follow once some calls have had enough time to generate some data.


- Jeff



On Tue, Jan 29, 2013 at 6:32 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> 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
>>>>>
>>>>>
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130129/23edd121/attachment.html