Date: Thu, 26 Apr 2007 00:04:53 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: What`s wrong with JFS configuration?
In-Reply-To: <462F59EE.2040801@inea.com.pl>
Message-ID: <Pine.GSO.4.64.0704252331040.14007@westnet.com>
References: <462EFA63.1030306@inea.com.pl>
	<88daf38c0704250555v7a696957x18e62a3d1ae351a7@mail.gmail.com>
	<462F59EE.2040801@inea.com.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.GSO.4.64.0704252331531.14007@westnet.com>

On Wed, 25 Apr 2007, Pawe=C5~B Gruszczy=C5~Dski wrote:

> I was just reading some informations on the web (for example:=20
> http://www.nabble.com/a-comparison-of-ext3,-jfs,-and-xfs-on-hardware-raid=
-t144738.html).

You were doing your tests with a database scale of 50.  As Heikki already=
=20
pointed out, that's pretty small (around 800MB) and you're mostly=20
stressing parts of the system that may not change much based on filesystem=
=20
choice.  This is even more true when some of your tests are only using a=20
small amount of transactions in a short period of time, which means just=20
about everything could still be sitting in memory at the end of the test=20
with the database disks barely used.

In the example you reference above, a scaling factor of 1000 was used.=20
This makes for a fairly large database of about 16GB.  When running in=20
that configuration, as stated he's mostly testing seek performance--you=20
can't hold any significant portion of 16GB in memory, so you're always=20
moving around the disks to find the data needed.  It's a completely=20
different type of test than what you did.

If you want to try and replicate the filesystem differences shown on that=
=20
page, start with the bonnie++ tests and see if you get similar results=20
there.  It's hard to predict whether you'll see the same differences given=
=20
how different your RAID setup is from Jeff Baker's tests.

It's not a quick trip from there to check if an improvement there holds up=
=20
in database use that's like a real-world load.  In addition to addressing=
=20
the scaling factor issue, you'll need to so some basic PostgreSQL=20
parameter tuning from the defaults, think about the impact of checkpoints=
=20
on your test, and worry about whether your WAL I/O is being done=20
efficiently before you get to the point where the database I/O is being=20
measured usefully at all via pgbench.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD=