pgbench --latency-limit option

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pgbench --latency-limit option
Date: 2015-12-23 02:28:39
Message-ID: 20151223.112839.1166490276257601376.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While playing with 9.5's pgbench, I faced with a strange behavior.

$ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 10 s
number of transactions actually processed: 16
number of transactions skipped: 0 (0.000 %)
number of transactions above the 1.0 ms latency limit: 16 (100.000 %)
latency average: 5.518 ms
latency stddev: 1.834 ms
rate limit schedule lag: avg 0.694 (max 1.823) ms
tps = 1.599917 (including connections establishing)
tps = 1.600319 (excluding connections establishing)

From the pgbench manual:

<term><option>--latency-limit=</option><replaceable>limit</></term>
<listitem>
<para>
Transaction which last more than <replaceable>limit</> milliseconds
are counted and reported separately, as <firstterm>late</>.
</para>
<para>
When throttling is used (<option>--rate=...</>), transactions that
lag behind schedule by more than <replaceable>limit</> ms, and thus
have no hope of meeting the latency limit, are not sent to the server
at all. They are counted and reported separately as
<firstterm>skipped</>.

In my understanding, this says: any transaction takes longer than the
duration specified by --latency-limit (in this case 1.0 ms) will not
be sent the sever. In the case above all (16) transactions were behind
the latency limit 1.0 ms:

number of transactions above the 1.0 ms latency limit: 16 (100.000 %)

So the number of skipped transactions should be 16 (100%), rather
than:

number of transactions skipped: 0 (0.000 %)

in this case I think.

Am I missing something?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2015-12-23 02:50:23 Re: Support for N synchronous standby servers - take 2
Previous Message Tom Lane 2015-12-23 02:15:03 Re: Some questions about the array.