Re: pgbench throttling latency limit

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, Rukh Meski <rukh(dot)meski(at)gmail(dot)com>, "PostgreSQL Developers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench throttling latency limit
Date: 2014-09-10 14:34:09
Message-ID: 54106161.5080308@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/09/2014 03:35 PM, Fabien COELHO wrote:
>
> Hello Heikki,
>
>>> I think we have to reconsider what we're reporting in 9.4, when --rate
>>> is enabled, even though it's already very late in the release cycle.
>>> It's a bad idea to change the definition of latency between 9.4 and 9.5,
>>> so let's get it right in 9.4.
>
> Indeed.
>
>> As per the attached patch. I think we should commit this to 9.4. Any
>> objections?
>
> Ok for me. Some more propositions about the doc below.

I looked closer at the this, and per Jan's comments, realized that we
don't log the lag time in the per-transaction log file. I think that's a
serious omission; when --rate is used, the schedule lag time is
important information to make sense of the result. I think we have to
apply the attached patch, and backpatch to 9.4. (The documentation on
the log file format needs updating)

Also, this is bizarre:

> /*
> * Use inverse transform sampling to randomly generate a delay, such
> * that the series of delays will approximate a Poisson distribution
> * centered on the throttle_delay time.
> *
> * 10000 implies a 9.2 (-log(1/10000)) to 0.0 (log 1) delay
> * multiplier, and results in a 0.055 % target underestimation bias:
> *
> * SELECT 1.0/AVG(-LN(i/10000.0)) FROM generate_series(1,10000) AS i;
> * = 1.000552717032611116335474
> *
> * If transactions are too slow or a given wait is shorter than a
> * transaction, the next transaction will start right away.
> */
> int64 wait = (int64) (throttle_delay *
> 1.00055271703 * -log(getrand(thread, 1, 10000) / 10000.0));

We're using getrand() to generate a uniformly distributed random value
between 1 and 10000, and then convert it to a double between 0.0 and
1.0. But getrand() is implemented by taking a double between 0.0 and 1.0
and converting it an integer, so we're just truncating the original
floating point number unnecessarily. I think we should add a new
function, getPoissonRand(), that uses pg_erand48() directly. We already
have similiar getGaussianRand() and getExponentialRand() functions.
Barring objections, I'll prepare another patch to do that, and backpatch
to 9.4.
- Heikki

Attachment Content-Type Size
pgbench-latency-calculations-1.patch text/x-diff 13.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitsumasa KONDO 2014-09-10 14:47:06 Re: pgbench throttling latency limit
Previous Message Alvaro Herrera 2014-09-10 13:47:28 Re: SKIP LOCKED DATA (work in progress)