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

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-performance by date

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

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