From: Greg Smith <gsmith@gregsmith.com>
To: Stephane Bailliez <sbailliez@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)
Date: Mon, 21 Jul 2008 14:43:54 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0807211423070.25912@westnet.com> (raw)
In-Reply-To: <488460ED.8090001@gmail.com>
References: <4881E9EF.5000805@gmail.com>
<Pine.GSO.4.64.0807201820320.479@westnet.com>
<488460ED.8090001@gmail.com>
On Mon, 21 Jul 2008, Stephane Bailliez wrote:
> Isn't it a scheduler problem, I thought CFQ was the default for desktop
> ?
CFQ/Deadline/AS are I/O scheduler choices. What changed completely in
2.6.23 is the kernel process scheduler.
http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt gives
some info about the new one.
While the switch to CFS has shown great improvements in terms of desktop
and many server workloads, what I discovered is that the pgbench test
program itself is really incompatible with it. There's a kernel patch
that seems to fix the problem at http://lkml.org/lkml/2008/5/27/58 but I
don't think it's made it into a release yet.
This is not to say the kernel itself is unsuitable for running PostgreSQL
itself, but if you're using pgbench as the program to confirm that I
expect you'll be dissapointed with results under the Ubuntu 8.04 kernel.
It tops out at around 10,000 TPS running the select-only test for me while
older kernels did 3X that much.
> Yes I'd definitely prefer to go 8.3 as well but there are a couple reasons
> for now I have to suck it up:
> - 8.2 is the one in the 7.10 repository.
> - I need plr as well and 8.3-plr debian package does not exist yet.
> (I know in both cases we could recompile and install it from there, but ...)
Stop and think about this for a minute. You're going into production with
an older version having a set of known, impossible to work around issues
that if you hit them the response will be "upgrade to 8.3 to fix that",
which will require the major disruption to your application of a database
dump and reload at that point if that fix becomes critical. And you can't
just do that now because of some packaging issues? I hope you can impress
upon the other people involved how incredibly short-sighted that is.
Unfortunately, it's harder than everyone would like to upgrade an existing
PostgreSQL installation. That really argues for going out of your way ir
necessary to deploy the latest stable release when you're building
something new, if there's not some legacy bits seriously holding you back.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsmith@gregsmith.com, sbailliez@gmail.com
Subject: Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)
In-Reply-To: <Pine.GSO.4.64.0807211423070.25912@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox