>>> 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?
BTW, the system was Linux (kernel 3.0.77). Now I tried on Mac OS X. $ pgbench -S -n -c 10 -T 10 test transaction type: SELECT only scaling factor: 1 query mode: simple number of clients: 10 number of threads: 1 duration: 10 s number of transactions actually processed: 67333 tps = 6730.940132 (including connections establishing) tps = 6751.078966 (excluding connections establishing) $ pgbench -S -n -c 10 -T 10 -R 3000 test transaction type: SELECT only scaling factor: 1 query mode: simple number of clients: 10 number of threads: 1 duration: 10 s number of transactions actually processed: 29840 average rate limit lag: 0.089 ms (max 27.301 ms) tps = 2983.707895 (including connections establishing) tps = 2991.919611 (excluding connections establishing) 0.089 ms * 29840 = 2.66 seconds. Not too bad compared with 10 seconds. On Linux maybe the overhead to calculate the lag is bigger than Mac OS X? Just my wild guess though... -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers