Re: Solaris shared_buffers anomaly? - Mailing list pgsql-performance

From Mischa Sandberg
Subject Re: Solaris shared_buffers anomaly?
Date
Msg-id 448F449A.6030900@ca.sophos.com
Whole thread Raw
In response to Re: Solaris shared_buffers anomaly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Solaris shared_buffers anomaly?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
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.


pgsql-performance by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Solaris shared_buffers anomaly?
Next
From: Mischa Sandberg
Date:
Subject: Re: Solaris shared_buffers anomaly?