From owner-freebsd-performance@FreeBSD.ORG Wed Aug 13 17:00:23 2014 Return-Path: Delivered-To: performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17BF144F; Wed, 13 Aug 2014 17:00:23 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B16C2218B; Wed, 13 Aug 2014 17:00:22 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id uq10so2360817igb.11 for ; Wed, 13 Aug 2014 10:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9yTd9xmdHRCwOCj9Kajn99AcXNp1hjx1kt3gpWeA27Q=; b=VbDiFa6Nh6+yz6mMJ0qWKqKFYVqohM0KGNDav54JehEkFkKmP4bly/X//J0/69r682 FoqDv9P1n55KmX29HaMqpUX+1T/Fl2KyfV5zETgU4TIYNjKVxcfRHrzrV/5CAGrGUjmT s80OX9pi4DXDnGHUbCbQFOT+OeTOw1QGCDRLtTbA9Zw3+CD7s8s8K3aR7YI6R5T3Vcjt MEJlzGEzUI5RzA15LhTdmCWFODhQk/z5bdiGDHB2Unh8cKQ5whnkU8j3fN0a2LIUuyWf jIL8o+C8efarT3MRmjMHuKVkHhBzc3iwG+6E5k3eSwN0O8BpHQE7KaR4ish4ksT6+tKA 2tww== MIME-Version: 1.0 X-Received: by 10.42.212.146 with SMTP id gs18mr4622270icb.96.1407949222191; Wed, 13 Aug 2014 10:00:22 -0700 (PDT) Received: by 10.43.17.196 with HTTP; Wed, 13 Aug 2014 10:00:22 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: <201408121409.40653.jhb@freebsd.org> References: <20140627125613.GT93733@kib.kiev.ua> <20140716132938.GB93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> Date: Wed, 13 Aug 2014 12:00:22 -0500 Message-ID: Subject: Re: PostgreSQL performance on FreeBSD From: Alan Cox To: John Baldwin X-Mailman-Approved-At: Wed, 13 Aug 2014 19:15:35 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Konstantin Belousov , Adrian Chadd , freebsd-current , performance@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 17:00:23 -0000 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.