Message-ID: <4490420C.1030609@ca.sophos.com>
Date: Wed, 14 Jun 2006 10:06:20 -0700
From: Mischa Sandberg <mischa@ca.sophos.com>
Reply-To: mischa@ca.sophos.com
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-performance@postgresql.org
Subject: Re: Solaris shared_buffers anomaly?
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> <18773.1150250672@sss.pgh.pa.us>
In-Reply-To: <18773.1150250672@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> 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.)

Gah. Always must remember to RTFSource.
And reproduce the problem on a machine I control :-)

-- 
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.