On Sat, 15 Aug 2009, Mark Mielke wrote:
> 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.
The only thing I would have thought that would allow this would be mmap.
> 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.
More details please. What did you do, and what happened? I would have
thought that a large read-only mmapped file that has been read (and
therefore is in RAM) would be counted as VIRT and RES of the process in
top, but can clearly be evicted from the cache at any time, and therefore
would show up as buffer or cache rather than process memory in the totals.
+1 on the idea that Linux memory reporting is incomprehensible nowadays.
There once was a limerick .sig
that really was not very big
It was going quite fine
Till it reached the fourth line
In response to
pgsql-performance by date
|Next:||From: Kevin Grittner||Date: 2009-08-17 14:38:59|
|Subject: Re: freezing tuples ( was: Why is vacuum_freeze_min_age100m? )|
|Previous:||From: Jeff Janes||Date: 2009-08-16 21:55:08|
|Subject: Re: Scalability in postgres|