From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: remove nclients/nthreads constraint from pgbench |
Date: | 2015-07-02 11:36:58 |
Message-ID: | 5595225A.60000@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2015-07-02 11:42:59 | Re: WAL-related tools and .paritial WAL file |
Previous Message | Pavel Stehule | 2015-07-02 11:25:54 | Re: psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx |