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
swapcache. The kernel will (and can) take any memory away from the swap cache at any time for resident (physical)
memoryfor 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@sss.pgh.pa.us]
> Sent: Saturday, August 15, 2009 10:25 AM
> To: Jeremy Carroll
> Cc: Scott Carey; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Memory reporting on CentOS Linux
>
> Jeremy Carroll<jeremy.carroll@networkedinsights.com> 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@mielke.cc>
