[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
device.
The later two seem not trivial as you mentioned.
Peter