Re: pgbench throttling latency limit

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, 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-15 10:34:14
Message-ID: 5416C0A6.8040407@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/13/2014 11:25 AM, Fabien COELHO wrote:
>
>> [about logging...]
>
> Here is an attempt at updating the log features, including the aggregate
> and sampling stuff, with skipped transactions under throttling.
>
> I moved the logging stuff into a function which is called when a
> transaction is skipped or finished.

Makes sense.

I spent some time on this, and this is what I ended up with. Notable
changes:

* I split this into two patches for easier review. The first patch
contains the refactoring of the logging stuff, and the second patch
contains the new functionality.

* I renamed many of the variables, to be more consistent with existing
similar variables

* progress reporting was broken with !PTHREAD_FORK_EMULATION. Need to
collect the number of skipped xacts from all threads.

* I renamed the long option to --latency-limit. --limit is too generic.

Please have a look. I have not looked at the docs changes yet.

One thing that needs some thinking and changing is the progress
reporting. It currently looks like this:

progress: 1.0 s, 4863.0 tps, lat 3.491 ms stddev 2.487, lag 1.809 ms, 99
skipped
progress: 2.0 s, 5042.8 tps, lat 3.265 ms stddev 2.264, lag 1.584 ms, 16
skipped
progress: 3.0 s, 4926.1 tps, lat 2.731 ms stddev 2.371, lag 1.196 ms, 45
skipped
progress: 4.0 s, 4963.9 tps, lat 1.904 ms stddev 1.212, lag 0.429 ms, 0
skipped
progress: 5.0 s, 4971.2 tps, lat 2.592 ms stddev 1.722, lag 0.975 ms, 0
skipped

The absolute number of skipped transactions doesn't make much sense when
all the other numbers are averages, and tps is a 1/s value. If you don't
know the total number of transactions executed, the absolute number is
meaningless. (Although you can calculate the absolute number of
transactions executed by multiplying the TPS value with the interval). I
think a percentage would be better here.

Should we also print the number of late transactions here? I think that
would be an even more important detail than the number of skipped
transactions. It might be better to print only the percentage of late
transactions, including skipped ones. Or both, but it's difficult to
cram everything on a single line. This needs some further thinking..

- Heikki

Attachment Content-Type Size
pgbench-log-refactor-1.patch text/x-diff 11.2 KB
pgbench-limit-9.patch text/x-diff 26.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Klyukin 2014-09-15 10:44:50 Re: implement subject alternative names support for SSL connections
Previous Message Alexey Klyukin 2014-09-15 08:23:08 Re: implement subject alternative names support for SSL connections