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?
|
Список | 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 по дате отправления: