Date: Tue, 27 Mar 2012 11:59:59 -0600 From: "Samuel J. Greear" <sjg@evilcode.net> To: Ivan Voras <ivoras@freebsd.org> Cc: "hackers@freebsd.org" <hackers@freebsd.org>, Doug Barton <dougb@freebsd.org> Subject: Re: PostgreSQL benchmarks (now with Linux numbers) Message-ID: <CANY-Wm9PqtjjAqE7D5CtJt5mmaJCJv1=-REtJQNPxkdzNZp38A@mail.gmail.com> In-Reply-To: <CAF-QHFX4JThkm_Xd3Ya4NZw-iHtNAvfebksLF1bPJ%2BDLB6L8-g@mail.gmail.com> References: <b1732c99-eec2-4097-ad9c-f58979addf9f@email.android.com> <4F45AB76.5050201@FreeBSD.org> <CANY-Wm9%2BZzavsJqZ=4_66gZxt7ehh%2BAZTbeAZxAz7Tkg=syabA@mail.gmail.com> <CAF-QHFX4JThkm_Xd3Ya4NZw-iHtNAvfebksLF1bPJ%2BDLB6L8-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 27, 2012 at 8:27 AM, Ivan Voras <ivoras@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANY-Wm9PqtjjAqE7D5CtJt5mmaJCJv1=-REtJQNPxkdzNZp38A>