Skip site navigation (1) Skip section navigation (2)

Re: Memory reporting on CentOS Linux

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Memory reporting on CentOS Linux
Date: 2009-08-17 11:03:29
Message-ID: alpine.DEB.2.00.0908171157430.19472@aragorn.flymine.org (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2009-08-17 14:38:59
Subject: Re: freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Previous:From: Jeff JanesDate: 2009-08-16 21:55:08
Subject: Re: Scalability in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group