>> The whole concept of "lag" with the rate limit is complicated.
>
> I must agree on that point, their interpretation is subtle.
>
>> At one point I thought this should be a debugging detail, rather than
>> exposing the user to it. The problem is that if you do that, you might
>> not notice that your limit failed to work as expected. Maybe it's
>> good enough in a case like this that the user will see they tried to
>> limit at 10000, but they only got 7135, so something must not have
>> worked as expected.
>
> Yep. As I suggested in answering to Tatsuo, the process can catch up
> later, so you could have 10000 in the end even with something amiss.
Fabian,
I did another case. First, I run pgbench without -R.
$ ./pgbench -p 5433 -S -n -c 10 -T 300 test
./pgbench -p 5433 -S -n -c 10 -T 300 test
transaction type: SELECT only
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 300 s
number of transactions actually processed: 2945652
tps = 9818.741060 (including connections establishing)
tps = 9819.389689 (excluding connections establishing)
So I thought I could squeeze 10000 TPS from my box.
Then I tried with -R 5000 tps.
$ ./pgbench -p 5433 -S -n -c 10 -T 300 -R 5000 test
./pgbench -p 5433 -S -n -c 10 -T 300 -R 5000 test
transaction type: SELECT only
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 300 s
number of transactions actually processed: 1510640
average rate limit lag: 0.304 ms (max 19.101 ms)
tps = 5035.409397 (including connections establishing)
tps = 5035.731093 (excluding connections establishing)
As you can see, I got about 5000 tps as expected. But I'm confused by
the lag:
0.304 ms * 1510640 = 459.2 seconds, which is longer than 300 seconds
(specified by -T). Am I missing something?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
