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

From Heikki Linnakangas
Subject Re: pgbench throttling latency limit
Date
Msg-id 540EE0A1.5070704@vmware.com
Whole thread Raw
In response to Re: pgbench throttling latency limit  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: pgbench throttling latency limit
List pgsql-hackers
On 09/09/2014 01:49 PM, Heikki Linnakangas wrote:
> 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.

As per the attached patch. I think we should commit this to 9.4. Any
objections?

The text this patch adds to the documentation needs some rewording,
though. As does this existing paragraph:

> High rate limit schedule lag values, that is lag values that are
> large compared to the actual transaction latency, indicate that
> something is amiss in the throttling process. High schedule lag can
> highlight a subtle problem there even if the target rate limit is met
> in the end. One possible cause of schedule lag is insufficient
> pgbench threads to handle all of the clients. To improve that,
> consider reducing the number of clients, increasing the number of
> threads in pgbench, or running pgbench on a separate host. Another
> possibility is that the database is not keeping up with the load at
> some point. When that happens, you will have to reduce the expected
> transaction rate to lower schedule lag.

It took me ages to parse "high rate limit schedule lag values".

- Heikki


Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: LIMIT for UPDATE and DELETE
Next
From: Heikki Linnakangas
Date:
Subject: Re: BRIN indexes (was Re: Minmax indexes)