From: Mischa Sandberg <mischa@ca.sophos.com>
To: pgsql-performance@postgresql.org
Subject: Re: Solaris shared_buffers anomaly?
Date: Tue, 13 Jun 2006 16:04:58 -0700
Message-ID: <448F449A.6030900@ca.sophos.com> (raw)
In-Reply-To: <11046.1150237327@sss.pgh.pa.us>
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>
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.
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: mischa@ca.sophos.com
Subject: Re: Solaris shared_buffers anomaly?
In-Reply-To: <448F449A.6030900@ca.sophos.com>
* 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