From: Alvaro Herrera <alvherre@commandprompt.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Jim C. Nasby <decibel@decibel.org>
Cc: Zoltan Boszormenyi <zb@cybertec.at>
Cc: PFC <lists@peufeu.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Postgres Benchmark Results
Date: Mon, 21 May 2007 20:47:37 -0400
Message-ID: <20070522004737.GK6111@alvh.no-ip.org> (raw)
In-Reply-To: <46523925.9080901@g2switchworks.com>
References: <op.tsmrv71ecigqcu@apollo13>
<46508CB9.1040404@cybertec.at>
<20070521210125.GM62346@nasby.net>
<46523925.9080901@g2switchworks.com>
Scott Marlowe wrote:
> Jim C. Nasby wrote:
> >On Sun, May 20, 2007 at 08:00:25PM +0200, Zoltan Boszormenyi wrote:
> >
> >>I also went into benchmarking mode last night for my own
> >>amusement when I read on the linux-kernel ML that
> >>NCQ support for nForce5 chips was released.
> >>I tried current PostgreSQL 8.3devel CVS.
> >>pgbench over local TCP connection with
> >>25 clients and 3000 transacts/client gave me
> >>around 445 tps before applying NCQ support.
> >>680 tps after.
> >>
> >>It went over 840 tps after adding HOT v7 patch,
> >>still with 25 clients. It topped at 1062 tps with 3-4 clients.
> >>I used a single Seagate 320GB SATA2 drive
> >>for the test, which only has less than 40GB free.
> >>So it's already at the end of the disk giving smaller
> >>transfer rates then at the beginning. Filesystem is ext3.
> >>Dual core Athlon64 X2 4200 in 64-bit mode.
> >>I have never seen such a performance before
> >>on a desktop machine.
> >>
> >
> >I'd be willing to bet money that the drive is lying about commits/fsync.
> >Each transaction committed essentially requires one revolution of the
> >drive with pg_xlog on it, so a 15kRPM drive limits you to 250TPS.
> >
> >BTW, PostgreSQL sees a big speed boost if you mount ext3 with the option
> >data=writeback. Note that doing that probably has a negative impact on
> >data recovery after a crash for non-database files.
> >
>
> I thought you were limited to 250 or so COMMITS to disk per second, and
> since >1 client can be committed at once, you could do greater than 250
> tps, as long as you had >1 client providing input. Or was I wrong?
My impression is that you are correct in theory -- this is the "commit
delay" feature. But it seems that the feature does not work as well as
one would like; and furthermore, it is disabled by default.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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: alvherre@commandprompt.com, smarlowe@g2switchworks.com, decibel@decibel.org, zb@cybertec.at, lists@peufeu.com
Subject: Re: Postgres Benchmark Results
In-Reply-To: <20070522004737.GK6111@alvh.no-ip.org>
* 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