EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Re; IOC memory leak
From: [email protected]
Date: Wed, 30 Nov 94 16:17:31 -0600
CA as well as a number of other items within EPICS eat memory under
load.  There might be a memory leak in there somewhere as well, but
the 'eating' of memory has been a problem for us in the past and is
more noticable depending on how you are determining how much 'free'
memory you actually have.

By 'eating', I mean that if some component, such as CA, decided that it
needs more buffers (perhaps a new connection is made) it will malloc
space for them.  Later on, when the buffers are no longer needed, they
are placed on an internal free list... not returned to vxWorks via
'free'.  Then, if a new connection is made later on, the buffer(s)
on the free list will be used... and if the free list ever empties,
another malloc will be done to get more.

This will make things look like they are disappearing for a while and
eventually level off... (hopefully before you run out of memory.)

If all you are doing is looking at the memShow output, this can fool
you.

This memory eating is done to prevent fragmentation from making the
entire memory pool unusable.  And is generally not a problem
unless/until there are 12MB sitting on various internal free lists and
something else needs a mere 1K, and there is not enough memory
available for malloc() to provide it.

As an aside,
If you are using memShow to monitor your memory pool, make sure you do
a 'memShow 1' to get a list of all the blocks and their sizes.  That
way you will be able monitor fragmentation as well.  It is possible
that you have alot of memory, but it is in 100000 tiny pieces and the
memory allocator system is hogging up most of it just to keep track of
it.  If this is the case (I have not seen it happening here at APS, but
I have not run any decent tests for it in a while) it is a hard thing
to deal with.  You will have to grep around for all uses of malloc()
and make sure that it is not allocating things for temporary use and
then calling free().  Yes, memory fragments are coalesced by free(),
but if one program fragment is allocating memory that it intends to
keep and it is interleaved with others that allocate memory and then
free it, it is possible to fragment things up.

--John

Navigate by Date:
Prev: Re: Re; IOC memory leak Jeff Hill
Next: Re: MVME162's for remote I/O Bob Dalesio
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Re; IOC memory leak Jeff Hill
Next: Re: MVME162's for remote I/O Bob Dalesio
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·