The man page does not say much, but does this mean I have only 396668 used by programs (used-cached)?
Or shoul I be reading the 2nd line?
[root@ten-212 ~]# free total used free shared buffers cached Mem: 7918844 5478820 2440024 0 111684 5082152 -/+ buffers/cache: 284984 7633860 Swap: 9961464 204 9961260
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On Mon, Jul 12, 2010 at 10:15:06AM -0400, Jason Pyeron wrote:
The man page does not say much, but does this mean I have only 396668 used by programs (used-cached)?
Or shoul I be reading the 2nd line?
Yes, you should be reading the second line.
[root@ten-212 ~]# free total used free shared buffers cached Mem: 7918844 5478820 2440024 0 111684 5082152 -/+ buffers/cache: 284984 7633860 Swap: 9961464 204 9961260
This first line includes all files that are being cached in memory (for faster reading if needed later, for example). That memory will be freed up if needed. The second line doesn't include that cache, so is a better indicator of actual memory use.
(And on that first line, "cached" is already part of "used", so your free memory counting the cache is 2440024; it's just provided for informational purposes.)
--keith
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Keith Keller Sent: Monday, July 12, 2010 10:41 AM To: CentOS mailing list Subject: Re: [CentOS] free
On Mon, Jul 12, 2010 at 10:15:06AM -0400, Jason Pyeron wrote:
The man page does not say much, but does this mean I have only
396668
used by programs (used-cached)?
Or shoul I be reading the 2nd line?
Yes, you should be reading the second line.
[root@ten-212 ~]# free total used free shared buffers
cached
Mem: 7918844 5478820 2440024 0 111684
5082152
-/+ buffers/cache: 284984 7633860 Swap: 9961464 204 9961260
This first line includes all files that are being cached in memory
(for
faster reading if needed later, for example). That memory will be freed up if needed. The second line doesn't include that cache, so is a better indicator of actual memory use.
(And on that first line, "cached" is already part of "used", so your free memory counting the cache is 2440024; it's just provided for informational purposes.)
I did some testing a while back, and my results showed that the -/+ buffers line seemed to be the *Minimum* amount of ram available if the kernel purged it's buffers/cache. Sometimes more is available.
(Roughly) The test was: * Turn swap off * Run free * Run 20 instances of a test program that malloc'd 100 megs of ram * Run free, see 2 gigs of ram + orginal amount of ram used. * Kill N number of those programs, which should free up N*100megs * Run free, output of -/+ did not reflect 2gigs - (N*100 megs).
I followed up by running enough instances of the test program that I should have run out of memory free said I had, but the programs all started, none were killed. I ran free again got a number pretty close to what I thought should be free. It's a fun test to play with, I assume results vary from kernel to kernel (how aggressive the kernel is cleaning up returned ram).
Patrick
On 07/14/2010 12:49 PM, Flaherty, Patrick wrote:
I did some testing a while back, and my results showed that the -/+ buffers line seemed to be the *Minimum* amount of ram available if the kernel purged it's buffers/cache. Sometimes more is available.
That can be the case if your kernel is configured to overcommit (it normally is), and the applications haven't actually written data to all of the pages that they've allocated.
(Roughly) The test was:
- Turn swap off
- Run free
- Run 20 instances of a test program that malloc'd 100 megs of ram
- Run free, see 2 gigs of ram + orginal amount of ram used.
- Kill N number of those programs, which should free up N*100megs
- Run free, output of -/+ did not reflect 2gigs - (N*100 megs).
You'd see different results if you malloc() 100MB of memory and write 0s to each page.
I followed up by running enough instances of the test program that I should have run out of memory free said I had, but the programs all started, none were killed. I ran free again got a number pretty close to what I thought should be free. It's a fun test to play with, I assume results vary from kernel to kernel (how aggressive the kernel is cleaning up returned ram).
IIRC, Linux doesn't do any cleaning up of memory that's returned. Some OSs do. Might also be worth mentioning that depending on which malloc you use, free() usually returns memory only to the process' own memory allocator, not to the kernel. Most of the time, the kernel only gets memory back when the application exits.
Flaherty, Patrick wrote, On 07/14/2010 03:49 PM:
I did some testing a while back, and my results showed that the -/+ buffers line seemed to be the *Minimum* amount of ram available if the kernel purged it's buffers/cache. Sometimes more is available.
(Roughly) The test was:
- Turn swap off
- Run free
- Run 20 instances of a test program that malloc'd 100 megs of ram
- Run free, see 2 gigs of ram + orginal amount of ram used.
- Kill N number of those programs, which should free up N*100megs
- Run free, output of -/+ did not reflect 2gigs - (N*100 megs).
I followed up by running enough instances of the test program that I should have run out of memory free said I had, but the programs all started, none were killed. I ran free again got a number pretty close to what I thought should be free. It's a fun test to play with, I assume results vary from kernel to kernel (how aggressive the kernel is cleaning up returned ram).
Patrick
Did your test program actually USE the 100 megs of ram? Because of "lazy allocation" or "optimistic memory allocation"*** as done by the kernel, the memory is not actually consumed until used. When I did something similar, I simply wrote a char to each byte of memory(there are faster ways, but I wanted simple not fast) after each allocation. You might have done this but I did not interpret your message to indicate that.
***I don't remember which is the correct term to search. but this link has two sets of source to show the difference: http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html
On 07/14/2010 01:34 PM, Todd Denniston wrote:
Did your test program actually USE the 100 megs of ram? Because of "lazy allocation" or "optimistic memory allocation"*** as done by the kernel,
"over-commit" is the term you were looking for.
the memory is not actually consumed until used. When I did something similar, I simply wrote a char to each byte of memory(there are faster ways, but I wanted simple not fast)
I'm pretty sure you just need to write one byte to each page. (write one byte, move the counter by getpagesize()).
-
Flaherty, Patrick -
Gordon Messmer -
Jason Pyeron -
Keith Keller -
Todd Denniston