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
