[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: block/throttle and burst bucket

From: Peter Lieven
Subject: Re: block/throttle and burst bucket
Date: Fri, 26 Feb 2021 13:33:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 26.02.21 um 10:27 schrieb Alberto Garcia:
> On Thu 25 Feb 2021 06:34:48 PM CET, Peter Lieven <pl@kamp.de> wrote:
>> I was wondering if there is a way to check from outside (qmp etc.) if
>> a throttled block device has exceeded the iops_max_length seconds of
>> time bursting up to iops_max and is now hard limited to the iops limit
>> that is supplied?
>> Would it be also a good idea to exetend the accounting to account for
>> requests that must have waited before being sent out to the backend
>> device?
> No, there's no such interface as far as I'm aware. I think one problem
> is that throttling is now done using a filter, that can be inserted
> anywhere in the node graph, and accounting is done at the BlockBackend
> level.
> We don't even have a query-block-throttle function. I actually started
> to write one six years ago but it was never finished.

A quick idea that came to my mind was to add an option to emit a QMP event if 
the burst_bucket is exhausted

and hard limits are enforced.

There seems to be something wrong in the throttling code anyway. Throttling 
causes addtional i/o latency always even if

the actual iops rate is far away from the limits and ever more far away from 
the burst limits. I will dig into this.

My wishlist:

 - have a possibility to query the throttling state.

 - have counters for no of delayed ops and for how long they were delayed.

 - have counters for untrottled <= 4k request performance for a backend storage 

The later two seem not trivial as you mentioned.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]