Hello, Xuehan. On Fri, May 31, 2019 at 12:04:57PM +0800, Xuehan Xu wrote: > The resource that we want to control is the ceph cluster's io > processing capability usage. And we are planning to control it in > terms of iops and io bandwidth. We are considering a more > work-conserving control mechanism that involves server side and are > more workload self-adaptive. But, for now, as we mostly concern about I see. > the scenario that a single client use up the whole cluster's io > capability, we think maybe we should implement a simple client-side io > throttling first, like the blkio controller's io throttle policy, > which would be relatively easy. On the other hand, we should provide > users io throttling capability even if their servers don't support the > sophisticated QoS mechanism. Am I right about this? Thanks:-) My experience with blk-throttle has been pretty abysmal and pretty much gave up on using it except for some really limited use cases. The problem is that, on a lot of devices, neither bandwidth or iops captures the cost of the IOs and there's a really wide band where any given configuration is both too low and too high - ie. depending on the particular IO pattern, too low to the point where IO utilization is significantly impacted while at the same time too high to the point where it can easily swamp the IO capacity. It's tempting to go for iops / bps control as they seem obvious and easy but it's highly unlikely to be a viable long term solution. Given that, I'm pretty hesistant about adding more facilities towards this direction. Can you guys please think more about what the actual IO resources are and how their costs can be evaulated? That'll be necessary for work-conserving control and it's highly likely that you'd want to use them for non-work-conserving limits too anyway. Thanks. -- tejun
