Re: PATCH: remove nclients/nthreads constraint from pgbench

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

In response to

Responses

Browse pgsql-hackers by date

  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