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

[Xen-devel] Re: Capping i/o ops



I would like to also see this, when we used UML a patch created by Chris at linode allowed for a guest to be throttled. The system worked on tokens, where each vps had a bucket full of tokens and each IO operation used 1 token and the bucked was refilled with a specified amount of tokens per second. If the bucket ran dry the user was throttled and had to wait until the bucket had more tokens added to it.

http://theshore.net/~caker/patches/token-limiter-v5.patch here's the patch might give you some type of idea of what to do...

~Shaun


"Pim van Riezen" <pi+lists@xxxxxxxxxxxx> wrote in message news:DAC7D946-A93F-47AC-B033-699933363075@xxxxxxxxxxxxxxx
Hi All,

I've been trying to get a bit of a grip on disk i/o for our Xen set- up. We're dealing with server workloads that can, at unexpected times, become seriously io-bound, up to the point that a single guest can cannibalize the available throughput of the fibrechannel array. Since we're dealing with a shared medium and multiple Xen hosts, I'm looking for a way in to put an upper cap on the number of i/o operations individual guests can perform.

Although this is not entirely scientific, it would allow an informed administrator to limit the amount of operations guest A on host X can perform to e.g., 50% of an observed maximum, so that guest B on host Y is still guaranteed access at a minimum performance level. The case could also be made for giving quality of service assurances on the single host level, but the multiple host scenario is the more interesting viewpoint: It precludes solutions that entail automatic optimizations - there are no trivial automatic solutions to be had in this scenario.

I'm not afraid to get my hands dirty and come up with a proof of concept or even completer patch, but before I dive in, would this approach stand a decent chance at making sense? The current approach seems to be "throw the requests at the block layer and let the kernel, the hardware, or God sort it out". Has any previous thought been given to this problem area that I can/should read up about?

Cheers,
Pim van Riezen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.