Re: Memory reporting on CentOS Linux

From: Jeremy Carroll <jeremy(dot)carroll(at)networkedinsights(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Memory reporting on CentOS Linux
Date: 2009-08-17 17:24:36
Message-ID: C6AEFC84.6007%jeremy.carroll@networkedinsights.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I believe this is exactly what is happening. I see that the TOP output lists a large amount ov VIRT & RES size being used, but the kernel does not report this memory as being reserved and instead lists it as free memory or cached.

If this is indeed the case, how does one determine if a PostgreSQL instance requires more memory? Or how to determine if the system is using memory efficiently?

Thanks for the responses.

On 8/17/09 6:03 AM, "Matthew Wakeling" <matthew(at)flymine(dot)org> wrote:

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(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Slava Moudry 2009-08-17 20:07:18 number of rows estimation for bit-AND operation
Previous Message Kai Behncke 2009-08-17 16:38:13 Getting time of a postgresql-request