Skip site navigation (1) Skip section navigation (2)

Re: Fork-based version of pgbench

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Fork-based version of pgbench
Date: 2005-12-02 00:23:30
Message-ID: 18325.1133483010@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Now that I've fixed the silly mistake in the fork-based version of
pgbench,
http://archives.postgresql.org/pgsql-patches/2005-12/msg00017.php
I'm seeing it consistently outperform the CVS-tip version by about 5%.
I get about 700 tps versus 670 tps; meanwhile "top" reports that idle
CPU percentage drops from around 15% to around 5%.  So I'm thinking
it may be worthwhile to fix the portability issues (ie, provide a
thread-based variant for Windows) and make it the standard version.
It's not so much that I want to inflate the measurements, as that
leaving 10% of the CPU on the table reduces pgbench's usefulness as
a way of stress-testing the backend.

The test case I'm looking at is on a dual Xeon, EM64T, hyperthreading
enabled (hence, 4 logical CPUs), running Fedora Core 4.  Database
parameters are stock except these changes to minimize I/O:
	fsync = off
	shared_buffers = 50000
	checkpoint_segments = 30
Database is initialized with "pgbench -i -s 10 bench" and then tested
with "pgbench -c 10 -t 3000 bench"; I usually do three runs and take
the median to have a trustworthy number.

It'd be interesting to find out if other people can get similar results
on other platforms.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-02 00:37:04
Subject: Re: [COMMITTERS] pgsql: Add comments about why errno is
Previous:From: Bruce MomjianDate: 2005-12-01 22:33:32
Subject: Re: Improving count(*)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group