Re: Linux mis-reporting memory

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Decibel!" <decibel(at)decibel(dot)org>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Linux mis-reporting memory
Date: 2007-09-21 08:03:04
Message-ID: 87r6ksa1jb.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Decibel! <decibel(at)decibel(dot)org> writes:
>> I'm finding this rather interesting report from top on a Debian box...
>
>> Mem: 32945280k total, 32871832k used, 73448k free, 247432k buffers
>> Swap: 1951888k total, 42308k used, 1909580k free, 30294300k cached
>
>> So how is it that linux thinks that 30G is cached?
>
> Why would you think that a number reported by the operating system has
> something to do with Postgres' shared memory?

I think his question is how can the kernel be using 30G for kernel buffers if
it only has 32G total and 8G of that is taken up by Postgres's shared buffers.

It seems to imply Linux is paging out sysV shared memory. In fact some of
Heikki's tests here showed that Linux would do precisely that.

If your working set really is smaller than shared buffers then that's not so
bad. Those buffers really would be completely idle anyways.

But if your working set is larger than shared buffers and you're just not
thrashing it hard enough to keep it in RAM then it's really bad. The buffer
Linux will choose to page out are precisely those that Postgres will likely
choose shortly as victim buffers, forcing Linux to page them back in just so
Postgres can overwrite them.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Csaba Nagy 2007-09-21 08:30:01 Re: Linux mis-reporting memory
Previous Message db 2007-09-21 05:58:27 Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!