[lug] server memory woes (3rd attempt!)

Nate Duehr nate at natetech.com
Thu Aug 26 18:52:01 MDT 2004


Michael Belanger wrote:

> Thanks for the responses!
>
> John Hernandez wrote:
>
>> Depending what tools you're using to monitor available memory, this 
>> is probably just normal behavior.  The kernel will generally suck up 
>> physical memory for things like file caching, etc.
>
>
> [mrb at porbeagle ~]$ free
>              total       used       free     shared    buffers     cached
> Mem:       3058568    2152228     906340          0     159476    1732016
> -/+ buffers/cache:     260736    2797832
> Swap:      6289320          0    6289320

One comment here... common mistake on large RAM boxes...

6GB of swap will pretty much be useless to you and is wasted space.  If 
you calculate how long it would take to swap 6GB of data in and out 
under the kind of load that would require that level of swapping, you'll 
see that the box will likely die or become completely unresponsive long 
before you can ever "get there".

This looks like a case of where the RedHat installer "did the wrong 
thing".  It doubled your physical RAM size for your swap space, which is 
a good rule of thumb on smaller RAM machines, but a machine that has 3G 
of RAM is a different story. You may want to discuss this with RedHat if 
you're opening a ticket with them anyway, and have them walk you through 
lowering the amount of swap on this machine. 

You can see there where 1.7 G of that RAM in use in the 3GB you have is 
"cached" data, which is *usually* able to be dumped by the kernel at any 
time when applications need physical RAM, so the box is definitely not 
hurting for physical RAM.  (Want to loan me some?  GRIN... I have a 
512MB Athlon 2500 "do everything" box that is eating into about 100M of 
swap at all times... performance on it has gone straight into the 
toilet.  Heh.)

What kind of box is it?  Most "fell off the network and console won't 
respond locally" types of lockups I've seen over the years are the 
result of either a piece of hardware acting flakey (usually a bad RAM 
SIMM/DIMM) or a bug in the kernel drivers for a particular piece of 
on-board hardware, usually NIC's that don't play nicely.  Have also seen 
a few broken DMA implementations that would manifest themselves in 
wicked lockups with nasty data corruption, but that's super-rare and 
many years ago.

When the machine stops responding on the network, is the local console 
still alive?

--
Nate Duehr, nate at natetech.com



More information about the LUG mailing list