From owner-freebsd-current@FreeBSD.ORG Thu Aug 14 18:19:55 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0292CAB1; Thu, 14 Aug 2014 18:19:55 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8A6A2A8A; Thu, 14 Aug 2014 18:19:54 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s7EIIL63031150; Thu, 14 Aug 2014 13:19:53 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1nqt2wgy21-1; Thu, 14 Aug 2014 13:19:53 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id E1A3B5000E5; Thu, 14 Aug 2014 13:19:52 -0500 (CDT) Message-ID: <53ECFDC8.1070200@rice.edu> Date: Thu, 14 Aug 2014 13:19:52 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Baldwin , alc@freebsd.org Subject: Re: PostgreSQL performance on FreeBSD References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> In-Reply-To: <201408141147.45698.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.629899992726084 urlsuspect_oldscore=0.0298999927260837 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=7.54939022407086e-09 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=498 rbsscore=0.629899992726084 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408140213 Cc: Konstantin Belousov , Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 18:19:55 -0000 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 wrote: >> >>> On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote: >>>> Hi! >>>> >>>> >>>> On 16 July 2014 06:29, Konstantin Belousov 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@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.