memory leak

[Robert G. Brown]

On 18 Dec 2002, Vann H. Walke wrote:

> I agree that this seems like the most likely source of your problem. 
> Unfortunately with the current Linux kernels obtaining clear memory
> usage information is difficult.  The only way I know to really test
> memory usage is to write a simple program that attempts to malloc large
> areas of memory - If the malloc succeeds, the memory wasn't really being
> used.  If you read back through the archives you should find some other
> messages relating to the problem and perhaps even some test code.

It is perfectly simple to obtain memory usage in linux, unless I'm
either going mad or somehow missed something.  The "free" command up
above is one way:  

rgb at ganesh|T:103>free
             total used free shared buffers cached
Mem:  772908 726700 46208 0 141740 243964
-/+ buffers/cache:     340996     431912
Swap:      2104432      59148    2045284

To translate: This system (ganesh) has 768 MB total memory.  It is
"using" nearly all of it.  It has a relatively small chunk it is holding
"free" to allocate >>quickly<< to running processes that ask for it --
this number floats around a lot as processes start and stop and whack on
memory, but is generally at least a few tens of MB on a system with a
decent amount of memory relative to the actual memory being used. 

It has a big chunk (140 MB) allocated to various buffers -- it can get
this back if it ever needs it for a malloc, at the cost of course of
flushing the buffers and potentially slowing the kernel somewhat.  It
has 240 MB or so allocated to various cached entities -- files, dynamic
libraries, memory pages -- anything and everything it ever uses that it
doesn't need right now but MIGHT need in the future is cached if
possible.  All of this tends to be pretty damn well tuned, so that linux
is very efficient and usable interactively even when fairly heavily
loaded and doesn't waste memory by leaving it idle when it could be put
to work as what amounts to a dynamic and fully automatic ramdisk that
you don't ever have to worry about or set up.

If all these numbers annoy you, the "-/+ buffers/cache" line tells you
the real "summary" story.  The system is REALLY using 340 MB.  It REALLY
has as much as 430 MB available to allocate (without swapping).

All of the raw numbers, BTW, are available in /proc/meminfo as well
(along with even more "uncooked" information that might be of use if you
read enough of the kernel source to learn what they mean).

HTH,

   rgb

> 
> Good luck,
> Vann
> 
> On Wed, 2002-12-18 at 05:44, John Hearns wrote:
> > Brian, please forgive me if I am insulting your intelligence.
> > 
> > But are you sure that you are not just noticing the disk
> > buffering behaviour of Linux?
> > The Linux kernel will use up spare memory as disk buffers -
> > leading an (apparently) lack of free memory.
> > This is not really the case - as the memory will be released
> > again when needed.
> > (Ahem. Was caught out by this too the first time I saw it...)
> > 
> > 
> > Anyway, if this isn't the problem, maybe you could send
> > us some of the stats from your system?
> > Maybe use nfsstat?
> > 
> > 
> > _______________________________________________
> > Beowulf mailing list, Beowulf at beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> > 
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> 

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu