Re: Solaris shared_buffers anomaly?

Поиск
Список
Период
Сортировка
От Mischa Sandberg
Тема Re: Solaris shared_buffers anomaly?
Дата
Msg-id 448F449A.6030900@ca.sophos.com
обсуждение исходный текст
Ответ на Re: Solaris shared_buffers anomaly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Solaris shared_buffers anomaly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Solaris shared_buffers anomaly?
Следующее
От: Mischa Sandberg
Дата:
Сообщение: Re: Solaris shared_buffers anomaly?