From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 18:00:01 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236CB1065670 for ; Tue, 27 Mar 2012 18:00:01 +0000 (UTC) (envelope-from sjg@evilcode.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C25D68FC16 for ; Tue, 27 Mar 2012 18:00:00 +0000 (UTC) Received: by ggnk4 with SMTP id k4so220863ggn.13 for ; Tue, 27 Mar 2012 11:00:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=X1RcO2F6uMwd0q1ugWDCGUhgrzbbvdzw8Ux5iczi9/4=; b=MKuVAJLsms/pEmyyqBHuCCAHRJ1tt3UYz6Lb6dedoZX3eusxUWN1F+nUnDYKgYCZ22 lA3lHxtaH8Tj3U5oZE70GesrY5yaEQF11NWq4Pj1fj53jiPIcPKhNMzu/NLGfw+bvRcD mU8iWbt6zTRIG5mkqY05KsDSATIdERtQUg4KzMbLIVleQZ9S4PKngODivqTP/ygiT39b 3HRXZ50xvLjPEMtT2SiKwMenqihEvHobGoqNOSQ/2SEIL6oOOY4HmSfUXcJsJ1zS/uu5 ic/ZQ7Y4eu9ApQNh3lDMfj1Fe/CWOHb/+XfbfzWbO6XquDoRKvIdc96kWJFvNIZTPTWE gV7Q== MIME-Version: 1.0 Received: by 10.50.85.130 with SMTP id h2mr9451804igz.47.1332871199784; Tue, 27 Mar 2012 10:59:59 -0700 (PDT) Received: by 10.50.73.38 with HTTP; Tue, 27 Mar 2012 10:59:59 -0700 (PDT) In-Reply-To: References: <4F45AB76.5050201@FreeBSD.org> Date: Tue, 27 Mar 2012 11:59:59 -0600 Message-ID: From: "Samuel J. Greear" To: Ivan Voras X-Gm-Message-State: ALoCoQn15Dn8RrYrzKQmAGvCBMiJsrB7Swh3rX4dnxe+ttcL3w50QbrLrD+ztNwjdLsWHZefAhcO X-Mailman-Approved-At: Tue, 27 Mar 2012 18:08:40 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "hackers@freebsd.org" , Doug Barton Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:00:01 -0000 On Tue, Mar 27, 2012 at 8:27 AM, Ivan Voras wrote: > >> On 02/22/2012 01:42, Ivan Voras wrote: > >> > The Dragonfly team has recently liberated their VM from the giant lock > >> > and there are some interesting benchmarks comparing it to FreeBSD 9 > and a > >> > derivative of RedHat Enterprise Linux: > > > I just saw this, so I thought I would mention -- DragonFly was not doing > a > > great job allocating pv entries rapidly, which is needed during > PostgreSQL > > warm up -- This made shm_use_phys appear very effective. It only makes > 1-2% > > difference now on DragonFly, and only 1-2% difference on FreeBSD. > > Great! > > Do you have a link to the updated results? > I looked back at this and I guess I mis-spoke a little. This is the best I have, http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/pdf00000.pdf -- the second page is I think the same as what was posted here before, but the first page is intermediate results. You can see there that we had a significant fall-off without shm_use_phy's after a certain point (yellow line). What I mis-remembered was that FreeBSD had a fall-off after a certain point as well -- it just isn't nearly as bad as ours was. https://github.com/DragonFlyBSD/DragonFlyBSD/commit/5669360730c92e705c92afd02210e7859b0dc722 -- Here is the relevant commit that enabled bursting of pv_entry's to our per-cpu cache, iirc this commit alone made up all of that difference (between the yellow line and the light green line on the first page of the pdf). I think that probably we are a little generous with the bursting now and that real-world this won't have much of an impact, real-world FreeBSD is probably already fine in this regard, caching things like this mostly just makes stuff look good on benchmarks. Another thing of note, the performance of PostgreSQL benchmarks is heavily limited by the concurrent fault rate of the kernel. (again, this is iirc) Pg opens files that are tens to hundreds of megabytes and these get faulted in 4096 bytes at a time, during these benchmarks it will be doing this from potentially several dozen processes on the same file. If these faults can be taken concurrently performance improves rather dramatically. Again, this is probably one of those things that does not have a dramatic effect on most real-life workloads but makes things look really good in benchmarks. Sam