It seems that token_refill is the same on different Linodes. Why is this? I would think io_refill would be inversly proportional to the number of virtual hosts. In other words I would think a Linode 128 would have twice the io_refill rate of a Linode 64. The way it is now, if everybody is IO-limited, a linode 64 host would be doing twice as much IO as a linode 128 in the same situation. Am I wrong?

I was sorta intrigued by that as well when I had heard that some time ago. Obviously io_refill is already really high for Linode 64's as with as many as just 4 Linodes swapping, it can take down the host.

I just assumed that if anyone, whether it be Linode 256 or Linode 64, hit that limiter, there were some apparent problems, and it wouldn't matter to have much higher refill rates even on 256 plans.

If you swap excessively, both token_refill (default = 512 on L64) and token_max (default = 400000 on L64) will be reduced. My L64 more or less stopped and when I checked, token_refill was down to 20% of default and token_max down to 10%. This happened during linking glibc, and stopped the linker in its tracks. caker reset the values in response to a ticket but I don't know whether they would have gone back up automatically or not.

_________________
/ Peter

I believe caker manually "mods down" excessive linodes, but it might be automatic.

I was modded down to token_refill=200 for a few days after a process started eating all of my memory over night & caused major performance issues.

Once I got the out of control process under control, my Linode 128 ran fine with only 200 for token_refill. I just had to be careful only to install 2 or 3 packages at a time (in Debian). More than that & my token bucket would get dangerously low.

After a few days of normal operations my refill rate jumped back to 512, so it seems like caker just decided I was no longer a threat.