From owner-freebsd-current@freebsd.org Fri Jun 3 15:29:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACB8CB69800; Fri, 3 Jun 2016 15:29:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7228017EE; Fri, 3 Jun 2016 15:29:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x242.google.com with SMTP id x130so17698796oia.3; Fri, 03 Jun 2016 08:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R8j3nmiecM0IH9E9VcTwWXH3zVzgN1N9NL7TEGAnt7w=; b=ixob1NJUyj3njv9m6BAEO+3izmb17p3tN8uAcxkq08KZJ6r+kGHlfUQjIamym28RV+ z0I8BDbD1ynbI0/pkM52fbU6d8Tdo7B+Q2VSjr2+Z7ML1KmJNYQweUbT1wA57DP9VqB/ BM7wD6eEeSzBuj5eAVtNt0CXO7qiLIK7gZFp68VpchTe4Ir79BWucOpqrJE5UEcbNEEQ 8t+wPYwTFd5tgRkV+FyEaPo9Vu7P0N0JB92iq8kGqv8gGGNQPN7x2FKrlyrUdIlUe+FC 1R0qItA3kDgPaaM7EDBCciumdbsnzJBwRiPUVC5fBsZZyrX+860I/1UYH8aXYKFtBUJ/ yqmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R8j3nmiecM0IH9E9VcTwWXH3zVzgN1N9NL7TEGAnt7w=; b=ITZpQMtnjXHVLG9hHTp/0TsarjSCG8vpN5LbyhPwImdOx4fDMRS0sjnx5a/SgCpVZj G29J84irKakymdetSH7NRbyAK9PIcHy2F+u2T6AEyj05o1AuXE+kJFeU+2u3iayI1Aet i3bjAlbLONPlbV3BS0cGxBtkXJ/+H05M6GwaFEL64JSB267J6Y1K54tmVt/KscVekYgc Mp4vDYroppmE/081qAiSK68DYk/jO7QAmr0jvdZaOrTgitQWS9W2KXKDY0oPVXzXWYhC Qn1CCfdQiJLdJseJNaklb/zpBImnRfL4CC69Vo5vee9MYhvj8UhaVuelzXIkFCRkKyss lFQw== X-Gm-Message-State: ALyK8tItL05yk6dpGYA73CVD6Xf2bWfUjj0E6F9nYfXptxldpQWXSwyzk+J/0964DPyIRu2unSGgcg0nznyTuQ== X-Received: by 10.157.29.177 with SMTP id y46mr2129684otd.164.1464967757168; Fri, 03 Jun 2016 08:29:17 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Fri, 3 Jun 2016 08:29:16 -0700 (PDT) In-Reply-To: <53ECFDC8.1070200@rice.edu> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> From: Alan Somers Date: Fri, 3 Jun 2016 09:29:16 -0600 X-Google-Sender-Auth: tL4nuLltg764HZURpLYW5yVGUBo Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Alan Cox Cc: John Baldwin , alc@freebsd.org, Konstantin Belousov , Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 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: Fri, 03 Jun 2016 15:29:18 -0000 On Thu, Aug 14, 2014 at 12:19 PM, Alan Cox wrote: > 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. I notice that, with the exception of the VM_PHYSSEG_MAX change, these patches never made it into head or ports. Are they unsuitable for low core-count machines, or is there some other reason not to commit them? If not, what would it take to get these into 11.0 or 11.1 ? -Alan