On Wed, 2009-07-22 at 22:23 -0400, Greg Smith wrote:
> Onto performance. My test system has a 16 cores of Xeon X5550 @
> 2.67GHz.
> I created a little pgbench database (-s 10) and used the default
> postgresql.conf parameters for everything but max_connections for a
> rough
> initial test.
To test on Windows, I set up a similar database on an 8-core 2.0GHz
E5335 (closest match I have.) It's compiled against a fresh CVS pull
from this morning, patched with the "20090724" updated version. I tried
to mirror the tests as much as possible, including the concurrent thread
counts despite having half the number of available cores. Doing that
didn't have much impact on the results, but more on that later.
Comparing the unpatched version to the new version running a single
client thread, there's no significant performance difference:
C:\pgsql85>bin\pgbenchorig.exe -S -c 8 -t 100000 pgbench
...
tps = 19061.234215 (including connections establishing)
C:\pgsql85>bin\pgbench.exe -S -c 8 -t 100000 pgbench
tps = 18852.928562 (including connections establishing)
As a basis of comparison the original pgbench was run with increasing
client counts, which shows the same drop off in throughput past the
16-client sweet spot:
con tps 8 1887116 1916124 1880432 1867064 17598
128 16664
However I was surprised to see these results for the patched version,
running 16 worker threads (apart from the 8 client run of course.)
C:\pgsql85>bin\pgbench.exe -S -j 16 -c 128 -t 100000 pgbench ...
con tps 8 18435 (-j 8)16 1886624 -----32 1793764 17016
128 15930
In all cases the patched version resulted in a lower performing output
than the unpatched version. It's clearly working, at least in that it's
launching the requested number of worker threads when looking at the
process. Adjusting the worker thread count down to match the number of
cores yielded identical results in the couple of test cases I ran.
Maybe pgbench itself is less of a bottleneck in this environment,
relatively speaking?
- Josh Williams