Greg Smith wrote:
On Tue, 28 Jul 2009, Scott Marlowe wrote:
Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
really be greater than -s
That's only true if you're running the TPC-B-like or other write tests,
where access to the small branches table becomes a serious hotspot for
contention. The select-only test has no such specific restriction as it
only operations on the big accounts table. Often peak throughput is
closer to a very small multiple on the number of cores though, and
possibly even clients=cores, presumably because it's more efficient to
approximately peg one backend per core rather than switch among more
than one on each--reduced L1 cache contention etc. That's the behavior
you measured when your test showed better results with c=10 than c=16 on
a 8 core system, rather than suffering less from the "c must be < s"
contention limitation.
Well the real problem is that pgbench itself does not scale too well to
lots of concurrent connections and/or to high transaction rates so it
seriously skews the result. If you look
http://www.kaltenbrunner.cc/blog/index.php?/archives/26-Benchmarking-8.4-Chapter-1Read-Only-workloads.html.
It is pretty clear that 90k(or the 83k I got due to the slower E5530)
tps is actually a pgench limit and that the backend really can do almost
twice as fast (I only demonstrated ~140k tps using sysbench there but I
later managed to do ~160k tps with queries that are closer to what
pgbench does in the lab)
Stefan
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
