[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sheflug] memory usage in linux
On Mon, 2007-11-26 at 10:12 +0000, David Willington wrote:
> I'm not in front of the machine at the moment so I can't cut and paste
> output, but without anyone logged on the output of top shows 2Gb memory
> being used, and that's without a graphical interface. I hope the problem
> is that I don't understand how to interpret the figures I see, which is
> why I'm trying to find a comprehensive explanation of how memory works and
> how I interpret these
In general, Linux will use all your memory - what isn't used for holding
programs is used to cache the disk to speed up file access. So, it's
rare for a machine to be on any serious length of time and not have most
of it's RAM in use.
If you look at the output of free, off my laptop:
$ free
total used free shared buffers cached
Mem: 2061344 1063284 998060 0 46600 386384
-/+ buffers/cache: 630300 1431044
Swap: 2031608 0 2031608
You can see that my system is RAM-plentiful and hasn't been on that
long, because although I have 2Gb of swap, none of it is in use. On a
normal system, you'd expect some of the swap to be in use.
The "true" RAM free amount is the second figure in the "free" column:
it's the amount of memory that is free plus the amount which is being
used as a disk buffer (because that memory can be reclaimed at any time:
if the data is needed again, you just read it off the disk again). So I
have effectively ~1.4Gb RAM free. *However* - just because the RAM can
be reclaimed doesn't really mean it's free: if I'm having to reclaim
cache and read the data back off disc later, the machine is probably
still going to be marginally slower.
If you're looking in ps, there are similar issues. There are two
columns, VSZ (Virtual Size) and RSS (Resident Set Size). The true usage
of any program is somewhere inbetween these two figures.
The virtual size is the complete amount of virtual memory in use by the
program. This isn't a terribly interesting figure, because it includes
kernel data, read-only and shared memory, so it could be quite huge even
for a small program. Things like libc would get counted in that figure,
and every program pretty much needs libc - plus, your system is probably
using two or three copies of libc in the absolute worst case, not one
for each program.
RSS is the amount of 'dirty' RAM in use by the program, and is the stuff
not shared by other programs pretty much. However, this is very much a
low water mark.
If a program is highly threaded, the RSS figure per-thread is pretty
close to being accurate. If it's not threaded, and isn't sharing many
libraries with other programs on the system, the VSZ is closer.
It's virtually impossible to get an absolute value for the RAM use
simply because it depends on how you define "use".
>From what you've said about your situation, it doesn't really sound like
a RAM / tuning thing. If 100 people crash the system, you have a much
more serious problem, and tweaking the config isn't likely to solve
things I don't think. I doubt AD auth is causing issues (that's
basically just LDAP), it sounds to me like you have a pretty fundamental
networking issue/.
Cheers,
Alex.
_______________________________________________
Sheffield Linux User's Group
http://www.sheflug.org.uk/mailfaq.html
GNU - The choice of a complete generation