Message-ID: <448F449A.6030900@ca.sophos.com>
Date: Tue, 13 Jun 2006 16:04:58 -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: 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>
In-Reply-To: <11046.1150237327@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:
>> vmstat showed that it was swapping like crazy.
>> Dropped shared_buffers back down again. 
>> Swapping stopped.
> 
> 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.
No reason to believe that the multiply-attached shm seg was being swapped out
(which is frankly insane). Swapping out (and in) just the true resident set of
every backend would be enough to explain the vmstat io we saw.

http://www.carumba.com/talk/random/swol-09-insidesolaris.html

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 (!). 

Context switch rates on our in-house solaris boxes running PG
have been insane (4000/sec). Reloading the TLB map on every process
context switch might be one reason Solaris runs our db apps at less
than half the speed of our perftesters' Xeon beige-boxes.

That's guesswork. Sun is making PG part of their distro ... 
perhaps they've some knowledgeable input.

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