From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Tue, 12 Dec 2006 16:08:51 -0500 (EST)
Message-ID: <Pine.GSO.4.64.0612121547280.15464@westnet.com> (raw)
In-Reply-To: <8a0c7af10612120858g1b1b4454x518a3ed609324627@mail.gmail.com>
References: <60psaq5t94.fsf@dba2.int.libertyrms.com>
<20061211173105.GH16692@mathom.us>
<E1Gtplp-0004Ka-GM@elasmtp-junco.atl.sa.earthlink.net>
<20061211184726.GI16692@mathom.us>
<E1GtrB8-0005rw-Iu@elasmtp-kukur.atl.sa.earthlink.net>
<457DA782.3060506@modgraph-usa.com>
<8a0c7af10612111422x6bdcc0c2p7cbfeb5a7b0e0374@mail.gmail.com>
<20061212013706.GM16692@mathom.us>
<8a0c7af10612120110v34f7d3c3p6d872efabf97b922@mail.gmail.com>
<20061212123131.GQ16692@mathom.us>
<8a0c7af10612120858g1b1b4454x518a3ed609324627@mail.gmail.com>
On Tue, 12 Dec 2006, Daniel van Ham Colchete wrote:
> I'm making some other tests here at another hardware (also Gentoo). I
> found out that PostgreSQL stops for a while if I change the -t
> parameter on bgbench from 600 to 1000 and I have ~150 tps instead of
> ~950tps.
Sure sounds like a checkpoint to me; the ones pgbench generates really
aren't fun to watch when running against IDE drives. I've seen my test
system with 2 IDE drives pause for 15 seconds straight to process one when
fsync is on, caching was disabled on the WAL disk, and the shared_buffer
cache is large.
If you were processing 600 transactions/client without hitting a
checkpoint but 1000 is, try editing your configuration file, double
checkpoint_segments, restart the server, and then try again. This is
cheating but will prove the source of the problem.
This kind of behavior is what other list members were trying to suggest to
you before: once you get disk I/O involved, that drives the performance
characteristics of so many database operations that small improvements in
CPU optimization are lost. Running the regular pgbench code is so wrapped
in disk writes that it's practically a worst-case for what you're trying
to show.
I would suggest that you run all your optimization tests with the -S
parameter to pgbench that limits it to select statements. That will let
you benchmark whether the core code is benefitting from the CPU
improvements without having disk I/O as the main driver of performance.
--
* 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
Subject: Re: New to PostgreSQL, performance considerations
In-Reply-To: <Pine.GSO.4.64.0612121547280.15464@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