[SGVLUG] used memory on a 4 GB system.

Jeff Carlson jeff at ultimateevil.org
Wed Nov 1 13:48:33 PST 2006


James Neff wrote:
> I ran top and here are the results:
> 
> top - 05:37:23 up 8 days,  1:44,  2 users,  load average: 0.00, 0.00, 0.00
> Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.0% us,  0.1% sy,  0.0% ni, 99.9% id,  0.0% wa,  0.0% hi, 
> 0.0% si
> Mem:   4039408k total,  4004660k used,    34748k free,    59444k buffers
> Swap:  2031608k total,      128k used,  2031480k free,  3713780k cached
> 
>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>    1 root      16   0  7196  704  592 S    0  0.0   0:00.99 init
>    2 root      RT   0     0    0    0 S    0  0.0   0:00.11 migration/0
>    3 root      34  19     0    0    0 S    0  0.0   0:00.00 ksoftirqd/0
>    4 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0
>    5 root      RT   0     0    0    0 S    0  0.0   0:00.15 migration/1
>    6 root      34  19     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1
>    7 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1
>    8 root      RT   0     0    0    0 S    0  0.0   0:00.03 migration/2
> 
> 
> This is a dual Opteron system (2 processors) with 2 GB of RAM for each
> processor.

Just say you have 4GB of RAM.  Unless you've got a nice Sun or IBM with
actual hardware partitioning, this idea of 2GB per processor is inaccurate.

> My question is, why does it say almost all of the memory is used?  Is
> this something I should be worried about or am I doing something wrong?

Yeah, I'd say basically you're doing something wrong.  Simply, it's not
knowing what's normal for your machine.

Hopefully without covering too much of what has already been said by Tom
and Claude, here's how Linux memory management works.  The kernel will
just begin to consume all available RAM, allocating it to cache and
buffers.  When memory is needed by applications, it will be allocated
from these pools.  This is based on the principle that free memory is
wasted memory.  Think about that for a second.  The computer is actually
working the least when most of its RAM is consumed.  It makes sense, right?

To really see how much memory is available, use the free command.  In
all reality, top doesn't do a very good job.  It's for quickly finding
things, not really in-depth analysis.  Still, you should watch top for a
few days.  Learn what's normal for your machine.  Add load to it, watch
changes.  Here's free on my 256MB:

           total     used     free   shared  buffers   cached
Mem:      255180   243828    11352        0     2904    65072
-/+ buffers/cache: 175852    79328
Swap:    1052248   108816   943432

Notice the line with -/+ buffers/cache?  You'll see that when I add
buffers back to free -- which technically, it is -- that I have
187,204KB, about 182MB, free.  I'm running X, Gnome, Firefox,
Thunderbird, beep, and gnome-terminal right now.  That sounds fairly
reasonable.  I was playing with Snort earlier, and saving output in
/dev/shm, so the cache and swap usage makes sense right now.

As for swap usage, there is a patch that will force the kernel to cache
everything in swap as soon as it is loaded, I think it's called
swap-ahead or something like that.  The idea is if a process needs to be
swapped out, then it already is, unloading it from memory is faster.  It
makes low-memory situation operations faster.  If you have 4GB,
depending on what you're doing on this machine, probably nothing will
need to go to swap.

Rather than watching top to determine how your machine is performing
(it's better for locating problem sources than performance trends), use
vmstat and iostat.  The vmstat program has changed slightly.  Depending
on which version you have, the red flag is either something showing
under procs w, or cpu wa.  These indicate processes that should run but
can't for some reason (resource starvation).  Low CPU idle isn't
necessarily a bad thing, though.  I mean, you are USING your computer,
right?

Another great tool is sar, which is part of the systat package.


More information about the SGVLUG mailing list