io - limiter
I have a few questions on IO limiters.
1. When iotokens gets negative, is the only way to replenish the stock is to disable io-consuming tasks, and wait for the stock to refill at the token refillrate?
2. Is there a way to have a quicker token_refill?
suggests that some configuration is available but I am not sure this is available to linode customers. To some extent, that would defy the purpose of the IO limiter.
3. I read that bigger linodes to not have high tokenmax or quicker tokenrefill because "is only there as an "emergency brake" for runaway Linodes"; Can you confirm this is still the case? Intuitively, I would have sais that the bigger the more tokens.
4. Does a linode with more RAM help avoid emptying that reserve of tokens?
Thanks!
3 Replies
@jcr:
1. When iotokens gets negative, is the only way to replenish the stock is to disable io-consuming tasks, and wait for the stock to refill at the token refillrate? Yes. Once you're out, you need to use less IO.
> 2. Is there a way to have a quicker token_refill?http://www.theshore.net/~caker/uml/patc … ter.README">http://www.theshore.net/~caker/uml/patches/token-limiter.README suggests that some configuration is available but I am not sure this is available to linode customers. To some extent, that would defy the purpose of the IO limiter. No. Linode sets the refill rate.
> 3. I read that bigger linodes to not have high tokenmax or quicker tokenrefill because "is only there as an "emergency brake" for runaway Linodes"; Can you confirm this is still the case? Intuitively, I would have sais that the bigger the more tokens.As far as I know, everyone gets the same refill rate. A standard web/email/dns server won't have a problem. If you've got a process that's eating IO and you need it, consider switching to the Xen beta. Xen is supposed to handle IO better then UML.
> 4. Does a linode with more RAM help avoid emptying that reserve of tokens?Only if swap thrashing is using up your IO tokens.
–James
For the remaining case, when your application simply needs all that I/O, you probably simply need dedicated hardware.
@Xan:
There's plenty of I/O to go around, but nobody is allowed to run away with it. There's no need to have varying refill rates because if you're hitting the I/O limits, then 99 times out of 100 you're either swap-thrashing or your app is doing something unnecessarily inefficiently. You'd want to fix either of those even if you had dedicated hardware.
For the remaining case, when your application simply needs all that I/O, you probably simply need dedicated hardware.
A few cases where I have run into the IO limiter are (1) transferring an existing system's to a new linode and (2) pre-processing/resizing large sets of digital photos from vacations. There's nothing wrong with these tasks, but they fundamentally require a single pass sequential read or write.