From: Tom Lane <tgl@sss.pgh.pa.us>
To: mischa@ca.sophos.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Solaris shared_buffers anomaly?
Date: Tue, 13 Jun 2006 22:04:32 -0400
Message-ID: <18773.1150250672@sss.pgh.pa.us> (raw)
In-Reply-To: <448F449A.6030900@ca.sophos.com>
References: <1150151282.14661.42.camel@tigger>
<20060613000441.GI8588@kenobi.snowman.net>
<20060613200810.GZ34196@pervasive.com>
<448F3A6E.6080908@ca.sophos.com>
<11046.1150237327@sss.pgh.pa.us>
<448F449A.6030900@ca.sophos.com>
Mischa Sandberg <mischa@ca.sophos.com> writes:
> Tom Lane wrote:
>> Does Solaris have any call that allows locking a shmem segment in RAM?
> Yes, mlock(). But want to understand what's going on before patching.
Sure, but testing it with mlock() might help you understand what's going
on, by eliminating one variable: we don't really know if the shmem is
getting swapped, or something else.
> For a dedicated DB server machine, Solaris has a feature:
> create "intimate" shared memory with shmat(..., SHM_SHARE_MMU).
> All backends share the same TLB entries (!).
We use that already. (Hmm, might be interesting for you to turn it
*off* and see if anything changes. See src/backend/port/sysv_shmem.c.)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, mischa@ca.sophos.com
Subject: Re: Solaris shared_buffers anomaly?
In-Reply-To: <18773.1150250672@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox