Strange memory issue(?) with 6850

[Dominique.GARNIER at arval.fr]

So basically, what you saying is that you can't trust the "cached" value
to 
be the size of the disk cached block?  

-----Original Message-----
From: linux-poweredge-bounces at dell.com
[mailto:linux-poweredge-bounces at dell.com] On Behalf Of Kuba Ober
Sent: vendredi 2 mars 2007 23:04
To: linux-poweredge at dell.com
Subject: Re: Strange memory issue(?) with 6850

On Friday 02 March 2007, Dominique.GARNIER at arval.fr wrote:
> Hello,
>
> I'm completely clueless about what's happening there. When i type a 
> free in some of our 6850 (Redhat Enterprise 4 AS U4 smp kernel x86_64 
> fully patched) i have something looking like the following:
>
> free
>              total       used       free     shared    buffers
> cached
> Mem:       8158444    3251208    4907236          0     276884
> 835120
> -/+ buffers/cache:    2139204    6019240
> Swap:      6265340          0    6265340
>
> So it seems that i have like 2Go of memory used BUT this is not the 
> case. Nothing is running on the server right now apart from dell omsa.

> At the same time, we're experiencing the aknowledged memory leak issue

> with OMSA (5.1.0) but i restarted it just before doing this 'free'
> and it released like 900Mo of memory. But i'm still left with another 
> 2Go of memory used.

Here's what I make of it:

Modern OSes generally don't like wasting your precious memory. Free RAM
is RAM for which you've paid and you get nothing in return. On very
lightly loaded system, a modern OS will typically cache most of the disk
blocks that were ever accessed since the boot. So your expensive 2.5ns
RAM is working to make disk accesses quicker, at least! As soon as you
start loading more applications and there's more memory pressure, the
cache allocation will drop significantly.

The free tool does not tell you what you think it does. Used memory
isn't necessarily used by the applications, and isn't necessarily
"taken" by the kernel. In your case most of the "used" memory is highly
liquid and can be allocated for appliations almost instantly.

If you want to try it out, write a small C program to malloc() a
gigabyte of RAM, and then mlockall(). Subsequently go over the
malloc()ed memory it in a loop and write to every page (to make sure the
pages are committed). Or disable overcommit in the kernel.

On your system, you should be able to fire up about 6 such processes, at
which point the "used" memory will grow to 100%. Yet you still have 6GB
for
*exclusive* use of those applications (kernel won't swap those pages!). 
That's in spite of supposedly 3/8 of your memory being previously used.

Cheers, Kuba

_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq


Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, ARVAL (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.



This message and any attachments (the "message") is intended solely for the addressees and is confidential.If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.The Internet can not guarantee the integrity of this message. ARVAL (and its subsidiaries) shall (will) not therefore be liable for the message if modified.