On Mon, 26 Nov 2007, Damon Hart wrote:
> Fedora 8:
> Linux 184.108.40.206-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 i686 i386
> Linux 2.6.18-8.1.15.el5.028stab049.1 #1 SMP Thu Nov 8 16:23:12 MSK 2007
> i686 i686 i386 GNU/Linux
2.6.23 introduced a whole new scheduler:
so it's rather different from earlier 2.6 releases, and so new that there
could easily be performance bugs.
> Does your 10K RPM drive 166 TPS ceiling apply in this arrangement with
> multiple disks
Number of disks has nothing to do with it; it depends only on the rate the
disk with the WAL volume is spinning at. But that's for a single client.
> scale: 50
> clients: 50
> transactions per client: 100
With this many clients, you can get far more transactions per second
committed than the max for a single client (166(at)10K rpm). What you're
seeing, somewhere around 500 per second, is reasonable.
Note that you're doing two things that make pgbench less useful than it
1) The number of transactions you're committing is trivial, which is one
reason why your test runs have such a huge variation. Try 10000
transactions/client if you want something that doesn't vary quite so much.
If it doesn't run for a couple of minutes, you're not going to get good
2) The way pgbench works, it takes a considerable amount of resources to
simulate this many clients. You might get higher (and more realistic)
numbers if you run the pgbench client on another system than the server.
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
In response to
pgsql-performance by date
|Next:||From: Gianluca Alberici||Date: 2007-11-27 07:24:20|
|Subject: 8.1 planner problem ?|
|Previous:||From: Damon Hart||Date: 2007-11-26 23:41:39|
|Subject: Re: PostgreSQL performance on various distribution stockkernels|