Re: PostgreSQL performance on FreeBSD

On 08/14/2014 10:47, John Baldwin wrote:
> On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
>> On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin <jhb_at_freebsd.org> wrote:
>>
>>> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
>>>> Hi!
>>>>
>>>>
>>>> On 16 July 2014 06:29, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
>>>>> On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
>>>>>> Hi,
>>>>>> I did some measurements and hacks to see about the performance and
>>>>>> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD
>>>>>> Foundation.
>>>>>>
>>>>>> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf.
>>>>>> The uncommitted patches, referenced in the article, are available as
>>>>>> https://kib.kiev.ua/kib/pig1.patch.txt
>>>>>> https://kib.kiev.ua/kib/patch-2
>>>>> A followup to the original paper.
>>>>>
>>>>> Most importantly, I identified the cause for the drop on the graph
>>>>> after the 30 clients, which appeared to be the debugging version
>>>>> of malloc(3) in libc.
>>>>>
>>>>> Also there are some updates on the patches.
>>>>>
>>>>> New version of the paper is available at
>>>>> https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf
>>>>> The changes are marked as 'update for version 2.0'.
>>>> Would you mind trying a default (non-PRODUCTION) build, but with junk
>>>> filling turned off?
>>>>
>>>> adrian_at_adrian-hackbox:~ % ls -l /etc/malloc.conf
>>>>
>>>> lrwxr-xr-x  1 root  wheel  10 Jun 24 04:37 /etc/malloc.conf -> junk:false
>>>>
>>>> That fixes almost all of the malloc debug performance issues that I
>>>> see without having to recompile.
>>>>
>>>> I'd like to know if you see any after that.
>>> OTOH, I have actually seen junk profiling _improve_ performance in certain
>>> cases as it forces promotion of allocated pages to superpages since all
>>> pages
>>> are dirtied.  (I have a local hack that adds a new malloc option to
>>> explicitly
>>> memset() new pages allocated via mmap() that gives the same benefit without
>>> the junking overheadon each malloc() / free(), but it does increase
>>> physical
>>> RAM usage.)
>>>
>>>
>> John,
>>
>> A couple small steps have been taken toward eliminating the need for this
>> hack: the addition of the "page size index" field to struct vm_page and the
>> addition of a similarly named parameter to pmap_enter().  However, at the
>> moment, the only tangible effect is in the automatic prefaulting by
>> mmap(2).  Instead of establishing 96 4KB page mappings, the automatic
>> prefaulting establishes 96 page mappings whose size is determined by the
>> size of the physical pages that it finds in the vm object.  So, the
>> prefaulting overhead remains constant, but the coverage provided by the
>> automatic prefaulting will vary with the underlying page size.
> Yes, I think what we might actually want is what I mentioned in person at
> BSDCan: some sort of flag to mmap() that malloc() could use to assume that any
> reservations are fully used when they are reserved.  This would avoid the need
> to wait for all pages to be dirtied before promotion provides a superpage
> mapping and would avoid demotions while still allowing the kernel to gracefully
> fall back to regular pages if a reservation can't be made.
>

I agree.