From owner-freebsd-current@FreeBSD.ORG Thu Aug 14 16:07:21 2014 Return-Path: Delivered-To: current@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 AA4384A5; Thu, 14 Aug 2014 16:07:21 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7FAF729AC; Thu, 14 Aug 2014 16:07:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 60873B9B9; Thu, 14 Aug 2014 12:07:20 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: PostgreSQL performance on FreeBSD Date: Thu, 14 Aug 2014 11:49:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201408141149.02488.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 14 Aug 2014 12:07:20 -0400 (EDT) Cc: Konstantin Belousov , 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 16:07:21 -0000 On Tuesday, August 12, 2014 5:36:26 pm Adrian Chadd wrote: > On 12 August 2014 11:09, 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.) > > Hm. this isn't a jemalloc config option? No, jemalloc does have a 'zero fill' option, but that runs on every malloc so it is just as expensive as junking. What my hack does is only zero the pages when they are first mmap'd, so subsequent free() / malloc() cycles that reuse the pages do not do any zeroing. -- John Baldwin