Re: Linux max on shared buffers?

From: GB Clark <postgres(at)vsservices(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: cjs(at)cynic(dot)net, glenebob(at)nwlink(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Linux max on shared buffers?
Date: 2002-07-17 16:37:53
Message-ID: 20020717113753.79617820.postgres@vsservices.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 11 Jul 2002 18:43:08 +1000
Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:

> On Thu, Jul 11, 2002 at 05:07:29PM +0900, Curt Sampson wrote:
> > Let's walk through an example. I have four pages total for caching.
> > Let's look at a read scenario based on two for postgres and two for the
> > OS, and one for postgres and three for the OS. Pn is a postgres buffer
> > and OSn is an OS buffer; the numbers below those show which disk blocks
> > are in which caches. We'll use an LRU algorithm for both caches and read
> > the blocks in this order: 1 2 3 2 1 2 3.
>
> Hmm, what about OS's that swap shared memory to disk. Wouldn't that change
> things somewhat? Probably more in favour of giving more memory to the OS.

I don't know about Linux, but under FreeBSD you can tell the OS to lock shared
mem in core. This DOES help out.

> The other possibility would be to use mmap instead. That way you avoid the
> double buffering altogether. Do you have any ideas about that?

Not all platforms have mmap. This has been discussed before I belive.

> --
> Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> > There are 10 kinds of people in the world, those that can do binary
> > arithmetic and those that can't.

--
GB Clark II | Roaming FreeBSD Admin
gclarkii(at)VSServices(dot)COM | General Geek
CTHULU for President - Why choose the lesser of two evils?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2002-07-17 17:01:21 Re: table size growing out of control
Previous Message Tom Lane 2002-07-17 16:37:14 Re: timestamped archive data index searches