Re: PATCH: remove nclients/nthreads constraint from pgbench
От | Heikki Linnakangas |
---|---|
Тема | Re: PATCH: remove nclients/nthreads constraint from pgbench |
Дата | |
Msg-id | 5595225A.60000@iki.fi обсуждение исходный текст |
Ответ на | Re: PATCH: remove nclients/nthreads constraint from pgbench (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: PATCH: remove nclients/nthreads constraint from
pgbench
Re: PATCH: remove nclients/nthreads constraint from pgbench |
Список | 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
В списке pgsql-hackers по дате отправления: