On 05/08/2015 03:02 PM, Fabien COELHO wrote:
>
> Remove pgbench constraint that the number of clients must be a multiple of
> the number of threads, by sharing clients among threads as evenly as
> possible.
>
> Rational: allows to test the database load with any number of client
> without unrelated constraint. The current setting means for instance that
> testing with a prime number of clients always uses one thread, whereas
> other number of clients can use a different number of threads. This
> constraint does not make much sense.
> ..
> Minor v2 update to change a not badly chosen variable name.
+1, it's really annoying that you can't just do -j<high number> and
always run with that.
This doesn't behave correctly if you set -j to greater than -c, and also
use the rate limit option:
---- This works ----
$ ./pgbench -R 100 -j3 -c 3 -T 10 postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 5
query mode: simple
number of clients: 3
number of threads: 3
duration: 10 s
number of transactions actually processed: 1031
latency average: 1.397 ms
latency stddev: 0.276 ms
rate limit schedule lag: avg 0.119 (max 1.949) ms
tps = 102.947257 (including connections establishing)
tps = 102.967251 (excluding connections establishing)
---- This does not; too small TPS ----
$ ./pgbench -R 100 -j100 -c 3 -T 10 postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 5
query mode: simple
number of clients: 3
number of threads: 100
duration: 10 s
number of transactions actually processed: 40
latency average: 3.573 ms
latency stddev: 1.724 ms
rate limit schedule lag: avg 0.813 (max 4.722) ms
tps = 3.246618 (including connections establishing)
tps = 3.246639 (excluding connections establishing)
I think that can be fixed by just setting nthreads internally to
nclients, if nthreads > nclients. But please double-check that the logic
used to calculate throttle_delay makes sense in general, when nthreads
is not a multiple of nclients.
- Heikki
