On 08/15/2009 11:39 AM, Jeremy Carroll wrote:
Linux strives to always use 100% of memory at any given time. Therefore the system will always throw free memory into swap cache. The kernel will (and can) take any memory away from the swap cache at any time for resident (physical) memory for processes.
That's why they have the column "-/+ buffers/cache:". That shows 46Gb Free RAM.
I cannot be the only person that has asked this question.
I vote for screwed up reporting over some PostgreSQL-specific
explanation. My understanding of RSS is the same as you suggested
earlier - if 50% RAM is listed as resident, then there should not be
90%+ RAM free. I cannot think of anything PostgreSQL might be doing into
influencing this to be false.
Do you get the same results after reboot? :-) I'm serious. Memory can be
corrupted, and Linux can have bugs.
I would not think that cache memory shows up as RSS for a particular
process. Cache memory is shared by the entire system, and is not
allocated towards any specific process. Or, at least, this is my
understanding.
Just for kicks, I tried an mmap() scenario (I do not think PostgreSQL
uses mmap()), and it showed a large RSS, but it did NOT show free memory.
Cheers,
mark
-----Original Message-----
From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx]
Sent: Saturday, August 15, 2009 10:25 AM
To: Jeremy Carroll
Cc: Scott Carey; pgsql-performance@xxxxxxxxxxxxxx
Subject: Re: Memory reporting on CentOS Linux
Jeremy Carroll<jeremy.carroll@xxxxxxxxxxxxxxxxxxxxx> writes:
I am thoroughly confused that TOP is reporting that I have 99% of my
physical RAM free, while the process list suggests that some are
taking ~8Gb of Resident (Physical) Memory. Any explanation as to why
TOP is reporting this? I have a PostgreSQL 8.3 server with 48Gb of RAM
on a Dell R610 server that is reporting that 46.5GB of RAM is free.
Exactly where do you draw that conclusion from? I see "free 138M".
It does look like there's something funny about top's accounting for
shared memory --- maybe it's counting it as "cached"? It's hardly
unusual for top to give bogus numbers in the presence of shared memory,
of course, but this seems odd :-(. With such large amounts of RAM
involved I wonder if there could be an overflow problem. You might file
a bug against top in whatever distro you are using.
regards, tom lane
--
Mark Mielke<mark@xxxxxxxxx>
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
