Here's how the output from free works (took me a while to refresh my
memory) ..
free returns numbers:
total used free shared buffers cached
Mem: A B C D E F
-/+ buffers/cache: G H
Swap: I J K
A == total memory (less what the kernel uses for itself)
B == all the memory currently used (for whatever purpose)
C == all memory thats actually marked free
D == amount of memory shared between processes (shared libraries, ...)
E == buffers (? network/IO level ?)
F == disk cached
D, E and F are part of B (so B >= D+E+F), the remaining part being the
nonshared program code&data: what people normally think of as used memory.
G and H show what could be available if all the cache and buffers were
used as free memory; so G = B - (E+F) and H = C + (E+F)
I, J and K do their own thang independant of the other numbers (use free
-t to bring them into play).
So, a useful number to keep an eye on is H, which is the available free
memory if all memory currently involved with buffering and caching were
utilised.
In your example, the total `missing' memory is 51,556 kB (228944-177388)
H starts off at 244,456 kB and ends at 224,076 kB: a descrepency of
20,380 kB. The rest of the missing memory is in the cached files
(29,592 kB). As more memory is needed the kernel will automatically
reclaim the cache memory and use that.
So where's the 20Mb gone? I guess if you looked at the size of X at the
start and at the end you'd find the missing memory. X has a habbit of
using memory and not freeing it. I don't know if this is deliberate
(internal caching) or a bug (a memory leak), but its annoying. Netscape is
particularly bad at triggering this bug/feature. AFAIK, there isn't a way
of flushing X, but restarting it should solve the missing memory problem.
If your colleague is having problems with swap, try fiddling with the
values in /proc/sys/vm/freepages. Do (as root)
cat /proc/sys/vm/freepages
to see the current settings (should be three numbers), and do
echo "256 512 768" > /proc/sys/vm/freepages
to set the numbers to a different values. Those numbers came from a
machine with 256Mb of memory, btw.
From what I can remember:
The first number is the smallest memory (in _pages_, == 512 bytes) that
must be present. Atomic allocation will fail if less that this amount of
available free memory is present. If the amount of available free memory
falls below the second number the system starts swapping and if the amount
of free memory raises above the third number, swapping stops. So for the
above example:
allocation will fail if there's less than 128 kB of free memory; if
there's less than 256 kB swapping starts, until 384 kB is free.
(oops, that was a slightly longer reply that I was planing on writing.
Hope it makes some sense :^)
Paul.
On Thu, 8 Mar 2001, Brian Smith wrote:
> OK - I'm recognizing all my (256Mb) memory without the option & I'm not
> knowingly doing anything thready. However, it appears I was fibbing
about
> the memory beeing hogged from the start - before I do anything I get
>
> total used free shared buffers cached
> Mem: 257536 28592 228944 13976 1988 13524
> -/+ buffers/cache: 13080 244456
> Swap: 272136 0 272136
>
> 28Mb for a fantastic operating system - no problem. Even with X + gnome
> on top I'm not too concerned (though I might go back to fvwm or something
> littler than gnome/sawfish)
>
> total used free shared buffers cached
> Mem: 257536 63896 193640 46632 3204 30312
> -/+ buffers/cache: 30380 227156
> Swap: 272136 0 272136
>
> So what it looks like to me is that there is a problem freeing up memory
> after a program has closed - for example open netscape and then close it
>
> before
> total used free shared buffers
> cached
> Mem: 257536 65816 191720 47980 3268 30648
> -/+ buffers/cache: 31900 225636
> Swap: 272136 0 272136
>
> during
> total used free shared buffers
> cached
> Mem: 257536 86244 171292 59508 3456 43056
> -/+ buffers/cache: 39732 217804
> Swap: 272136 0 272136
>
> after
> total used free shared buffers cached
> Mem: 257536 80148 177388 48200 3572 43116
> -/+ buffers/cache: 33460 224076
> Swap: 272136 0 272136
>
> So quite quickly you can stack up over 100Mb of "used" memory which
never
> seems to come free again. This hasn't been a problem so far on this
> machine, but a colleague who only has 128Mb in her machine quickly
> gets into ugly swapping situations.
>
> Yours,
> Brian
>
> On Thu, 8 Mar 2001, Paul Millar wrote:
>
> >
> > One off the top of my head: have you included a mem=xxxM boot option? Two
> > machines booted RH7.0 with 128Mb installed (and detected by the BIOS), but
> > the kernel ignored this and assumed 64Mb. Easy to check and fix, but
> > something like it might be the problem.
> >
> > Failing that, what _is_ the output from free and top?
> >
> > HTH
> >
> > Paul.
> >
> > On Thu, 8 Mar 2001, Brian Smith wrote:
> > > Hi,
> > >
> > > I've noticed that on the machines I've set up with RH7.0 a huge
> > > chunk of the memory is blown (like 100Mb as reported by free or top)
> > > before I start doing anything - even before I start X. Is this 'cos the
> > > stock kernel has too much extra compiled in or should I be looking
> > > elsewhere? No processes reported by ps seems to be all that huge - are
> > > there any prettier tools I can use analyse memory usage (� la IRIX
> > > gmemusage)? Any pointers appreciated.
> > >
> > > Brian
> > >
> > > Dr. Brian O. Smith ----------------------- [EMAIL PROTECTED]
> > > Institute of Cell and Molecular Biology, University of Edinburgh,
> > > King's Buildings, Edinburgh EH9 3JR, UK.
> > > Tel: 0131 650 7051/7045/4704 Fax: 0131 650 7055
> > >
> > > --------------------------------------------------------------------
> > > http://www.lug.org.uk http://www.linuxportal.co.uk
> > > http://www.linuxjob.co.uk http://www.linuxshop.co.uk
> > > --------------------------------------------------------------------
> > >
> >
> > ------------------------------------------------------------------------------
> > Paul Millar yo-yo, n. :
> > Particle Physics Theory Group Something that is occasionally
> > Department of Physics and Astronomy up but normally down.
> > University of Glasgow, (see also Computer)
> > Glasgow G12 8QQ, [EMAIL PROTECTED]
> > Scotland +44 (0)141 330 4717
> > ------------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > http://www.lug.org.uk http://www.linuxportal.co.uk
> > http://www.linuxjob.co.uk http://www.linuxshop.co.uk
> > --------------------------------------------------------------------
> >
>
> Dr. Brian O. Smith ----------------------- [EMAIL PROTECTED]
> Institute of Cell and Molecular Biology, University of Edinburgh,
> King's Buildings, Edinburgh EH9 3JR, UK.
> Tel: 0131 650 7051/7045/4704 Fax: 0131 650 7055
>
> --------------------------------------------------------------------
> http://www.lug.org.uk http://www.linuxportal.co.uk
> http://www.linuxjob.co.uk http://www.linuxshop.co.uk
> --------------------------------------------------------------------
>
------------------------------------------------------------------------------
Paul Millar yo-yo, n. :
Particle Physics Theory Group Something that is occasionally
Department of Physics and Astronomy up but normally down.
University of Glasgow, (see also Computer)
Glasgow G12 8QQ, [EMAIL PROTECTED]
Scotland +44 (0)141 330 4717
------------------------------------------------------------------------------
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
