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. Matthew -- There once was a limerick .sig that really was not very big It was going quite fine Till it reached the fourth line -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
