From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | coelho(at)cri(dot)ensmp(dot)fr |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Doubt in pgbench TPS number |
Date: | 2015-09-28 06:01:48 |
Message-ID: | 20150928.150148.1220989393041110168.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I think that the degree of parallelism to consider is nclients, not
> nthreads: while connection time is accumulated in conn_time, other
> clients are possibly doing their transactions, in parallel,
I'm not sure about this. I think pgbench will not start transactions
until all clients establish connections to PostgreSQL.
I found this while playing with pgpool-II. pgpool-II pre-forks child
process, whose number is defined by "num_init_children"
directive. What I observed was, pgbench starts connecting to pgpool-II
until "-c" connections are established. So, if "-c" is larger than
"num_init_children", no transaction starts.
> even if it
> is in the same thread, so it is not "stopped time" for all clients. It
> starts to matter with "-j 1 -c 30" and slow transactions, the
> cumulated conn_time in each thread may be arbitrary close to the whole
> time if there are many clients.
>
> Now, I do not think that this tps computation makes that much
> sense. If you want to know the tps without reconnect, run without
> reconnecting... It is clear that I do not get this figure when running
> without -C, so maybe
> the tps with/without reconnection should be dropped?
>
> Anyway, here is a patch, which:
> - fixes the "exclude" computation (s/nthreads/nclients/)
> - fixes the count total for skipped (s/threads/thread/)
> - removes a useless parameter to doCustom
> (the conn_time is available through the thread parameter).
I have tested your patch. It seems the tolerance is much better than
before with your patch.
With the patch:
./pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 30 s
number of transactions actually processed: 2887
latency average: 103.914 ms
tps = 95.896850 (including connections establishing)
tps = 98.101662 (excluding connections establishing)
Without the patch:
./pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 30 s
number of transactions actually processed: 2887
latency average: 103.914 ms
tps = 95.919415 (including connections establishing)
tps = 124.732475 (excluding connections establishing)
I'm going to commit your patch if there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2015-09-28 06:05:47 | Re: optimizing vacuum truncation scans |
Previous Message | David Rowley | 2015-09-28 04:31:03 | Partial Aggregation / GROUP BY before JOIN |