Re: SYSV shared memory vs mmap performance

On Fri, Jan 25, 2013 at 9:38 AM, Francois Tigeot <ftigeot(at)wolfpond(dot)org> wrote:
>> On Fri, Jan 25, 2013 at 8:40 AM, Bruce Momjian <bruce(at)momjian(dot)us>
>> wrote:
>>>
>>> Just a reminder we might have *BSD performance issues with our use
>>> of Posix shared memory in Postgres 9.3. I am attaching the PDF the
>>> user posted.
>>
>> This is a good point. The question which I believe I asked before
>> and haven't gotten an answer to is whether there's some way to get
>> the benefit of shm_use_phys with an anonymous mapping.
>
> There is. Postgres 9.3+mmap performance on DragonFly is now much better than
> these old benchmark results show.
>
> After the initial disappointing result, I went on a benchmarking/tuning
> binge with our Dear Leader Matt Dillon. Taking advantage of some previous
> cpu topology work from Mihai Carabas, he heavily improved most performance
> shortcomings we found in the DragonFly kernel.
>
> There were a few mail about this changes on the DragonFly mailing-lists and
> Justin Sherill wrote some interesting articles on his blog.
>
> Some links with more details about improvements and final results:
> http://www.shiningsilence.com/dbsdlog/2012/09/19/10403.html
> http://www.shiningsilence.com/dbsdlog/2012/10/11/10544.html
> http://www.dragonflybsd.org/performance/

Well, that looks pretty cool. Is there anything we can sensibly do to
recover the lost performance on FreeBSD and NetBSD?

>> It seems to me to be slightly insane to impose draconian shared
>> memory limits out of the box and then complain when people switch to
>> some other type of shared memory to get around them. I realize that
>> Dragonfly may not be doing that (because I think they may have
>> raised the default shared-memory limits), but I believe some of the
>> more mainstream BSDs are.
>
> The original SYSV limits looked like something straight from the 1980s;
> we're now autotuning them on DragonFly.

Awesome!

> FreeBSD and NetBSD still needed manual tuning last time I had a look.

Bummer. :-(

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company