Recently I ran a set of tests on two systems: a 4-core server with 5
disks (OS + WAL + 3 for DB) on a battery backed disk controller, and a
newer Hyper-threaded design with 4 physical cores turning into 8 virtual
ones--but only a single disk and no RAID controller, so I had to turn
off its write cache to get reliable database operation. (See
When running pgbench with its simple built-in SELECT-only test, on a
tiny data set that fits in RAM, I went from a peak of 28336 TPS on the
4-core system to a peak of 58164 TPS on the 8-core one.
On the default write-heavy test, the 4-core server peaked at 4047 TPS.
The 8-core one peaked at 94 TPS because that's as fast as its single
disk could commit data.
The moral is that a faster processor or more cores only buys you
additional speed if enough of your data fits in RAM that the processor
speed is the bottleneck. If you're waiting on disks, a faster processor
will just spin without any work to do. You can't answer "will I get
more transactions per second?" without specifying what your transaction
is, and knowing what the current limiter is.
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
In response to
pgsql-general by date
|Next:||From: Greg Smith||Date: 2010-03-29 18:41:50|
|Subject: Re: playr (or similar tool)?|
|Previous:||From: John Gage||Date: 2010-03-29 18:12:47|
|Subject: Re: How long will the query take|