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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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