Re: Changing the default configuration (was Re:

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Copeland <greg(at)CopelandConsulting(dot)Net>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing the default configuration (was Re:
Date: 2003-02-13 04:32:15
Message-ID: Pine.NEB.4.51.0302131325430.1487@angelic.cynic.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

On Wed, 12 Feb 2003, Bruce Momjian wrote:

> Christopher Kings-Lynne wrote:
>
> > You cannot change SHMMAX on the fly on FreeBSD.
>
> And part of the reason is because some/most BSD's map the page tables
> into physical RAM (kernel space) rather than use some shared page table
> mechanism. This is good because it prevents the shared memory from
> being swapped out (performance disaster).

Not at all! In all the BSDs, as far as I'm aware, SysV shared memory is
just normal mmap'd memory.

FreeBSD offers a sysctl that lets you mlock() that memory, and that is
helpful only because postgres insists on taking data blocks that are
already in memory, fully sharable amongst all back ends and ready to be
used, and making a copy of that data to be shared amongst all back ends.

> It doesn't actually allocate RAM unless someone needs it, but it does
> lock the shared memory into a specific fixed location for all processes.

I don't believe that the shared memory is not locked to a specific VM
address for every process. There's certainly no reason it needs to be.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Tom Lane 2003-02-13 05:15:02 Re: Changing the default configuration (was Re:
Previous Message Curt Sampson 2003-02-13 04:18:44 Re: [HACKERS] PostgreSQL Tuning Results

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-13 04:38:11 Re: psql source suggestions
Previous Message Greg Stark 2003-02-13 04:29:39 Re: loading libraries on Postmaster startup

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-02-13 05:15:02 Re: Changing the default configuration (was Re:
Previous Message Tom Lane 2003-02-13 03:18:35 Re: Changing the default configuration (was Re: