And even that being said, Aqs Younas, the original poster of the question, has never actually described his situation as causing a stability problem for any the freeswitch instances or the other running programs on those servers.  This may simply be an incorrect assumption from the standpoint of how everybody is taught basic memory management:  free whatever you've allocated as soon as your done with that given object.

In case our original poster (and anybody else who is curious) isn't as experienced with memory pools, the general idea behind their use in FreeSWITCH is to cut down on memory fragmentation.  Every time you allocate an object, the operating system has to map out some memory for you to use.  If you do this too often for too small of an amount of memory, you can negatively impact the performance of the application and the system as a whole.  Memory pooling adds another layer onto the memory management in that FreeSWITCH in this case requests a larger block of memory for allocation, but then it allocates smaller objects off of that pool.  This is especially beneficial when the allocations happen from within the same places.  It also makes releasing this memory a lot simpler because we then simply free the current memory pool, and all objects on that given pool are technically no longer valid objects ("freed").  But it frees the memory pool back to the master memory pool that FreeSWITCH uses, and that grows, as Brian stated, up to a given "high water mark".  It's only when FreeSWITCH stops running that is releases all those blocks of allocated memory back to the operating system.  When used properly and in the right situations, as we do in FreeSWITCH, memory pools are more efficient.

So 3 GB of RAM used by the application with mod_vlc do not seem to be such a stretch.  Heck, I routinely have Mozilla Firefox and Google Chrome each grab more RAM than that.  In other words, if there's no actual stability issue, this sounds like it's a case of FreeSWITCH working in the way it has been engineered to do so.

-- 
Yossi Neiman

On 03/27/2015 10:06 AM, Michael Jerris wrote:
That being said.. there is a known issue in mod_vlc in 1.4 that leaks but I don't think enough to necessarily describe what you are seeing.  We are doing a complete rewrite of that module for 1.6 so that fix may not make it down to 1.4, still to be seen.


On Mar 27, 2015, at 10:45 AM, Brian West <brian@freeswitch.org> wrote:

FreeSWITCH uses memory pools, so NO in a lot of cases it won't give it back, it will hit a high water mark based on your use case.  And Drop caches is dangerous.




On Fri, Mar 27, 2015 at 9:06 AM, Aqs Younas <aqsyounas@gmail.com> wrote:
Hi, Brian.

Its ok If vlc takes some ram, but freeswitch must release the ram when there are no calls.
Is there any command that can make freeswitch release the ram without restarting the freeswitch.

Like this linux command which makes linux release the cached ram.

free && sync && echo 3 > /proc/sys/vm/drop_caches && free1

Thanks


On 27 March 2015 at 18:51, Aqs Younas <aqsyounas@gmail.com> wrote:
Yes, we are using linux and looking at RSS value.

Our dialplan is mostly using mod_vlc for running streams.Just a call comes in and a radio stream is played with mod_vlc. I am not sure either mod_vlc or something else in freeswitch is eating up ram.

I just told our dialplan is mostly based on mod_vlc a portion on mod_curl. I have attached the top command results in above post, you can see freeswitch consuming more ram than any process.

One more thing, 6th freeswitch doesn't capture ram more than 1 gb, that one is not using mod_vlc or mod_curl. On other 5 freeswitch we are facing the issue.

6th one freeswitch dialplan just consist of.

<extension name="garbage">
      <condition>
        <action application="answer"/>
        <action application="playback" data="/opt/garbage/Generic_VM.wav"/>
        <action application="hangup"/>
      </condition>
</extension>


Thanks for your reply.

On 27 March 2015 at 18:32, I put the Who? in Mishehu <mishehu@freeswitch.org> wrote:
Are you using linux?  If so, which memory value are you looking at (VSZ, RSS...) ?

If you don't use mod_vlc, do you still see FreeSWITCH consuming this much RAM?  Usually FreeSWITCH builds up a memory pool and won't release that back to the system until after shutdown, but I don't normally see that go above about 1.2GB of RAM in any of the systems I work on (though they do not use mod_vlc).

-- 
Yossi Neiman
On 03/27/2015 07:57 AM, Aqs Younas wrote:
Hi, users

We are using 6 freeswitch instances, 5 freeswitch instances for playing streams with mod_vlc. After 3 to 4 for days,  we see these (5) freeswitch taking more than 3gb of momory and even though calls are not more than 25.

Usually, some calls stay for more than 2 to 3 hours on some freeswitch.  Everytime we have to restart the freeswitch to release the captured memory.

But is believed, freeswitch must release the momory when there are no calls. But freeswitch still keeps captured memory.

I have attactted the top command result along with this email.
Willing to perform any test if it helps tackle the problem.

Thanks for your help.




_________________________________________________________________________
Professional FreeSWITCH Consulting Services: 
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org