Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Дата
Msg-id 20130717.184009.793557422252345656.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
>>> 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: XLogInsert scaling, revisited