Re: pgbench throttling latency limit - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pgbench throttling latency limit
Date
Msg-id 5416C0A6.8040407@vmware.com
Whole thread Raw
In response to Re: pgbench throttling latency limit  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench throttling latency limit
List 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

pgsql-hackers by date:

Previous
From: Alexey Klyukin
Date:
Subject: Re: implement subject alternative names support for SSL connections
Next
From: Alexey Klyukin
Date:
Subject: Re: implement subject alternative names support for SSL connections