implement IO throttle #31

Open
opened 7 months ago by forest · 0 comments
forest commented 7 months ago
Owner

One capsul is responsible for more than half of our write IOPS, and its a "tiny" $5/mo one. 🤪

This is an issue because its a monetary cost for us. SSDs wear out after a certain number of writes, and they are not pitching in proportionately to help with the cost of replacing the disks periodically.

All other providers do this. Ideally would not have to, but we aren't interested in manually policing what our users do on their capsuls.

So we will have to implement something like "IO credits" for "IO Burst".

Once your capsul runs out of IO credits, it wil be throttled to a much slower storage performance.

We can do better than providers like amazon in this regard; we can give users a large pool of IO credits and warn them when it's half depleted. A "normal" user with a normal use case will never even get close to seeing this warning, but even the most agressive disk-writing-user will be warned days or weeks before they are throttled. This way we can protect our disks from wearout or at least force users to pay more monthly if they need this kind of IO performance, but at the same time they should hopefully not have to experience the misery of trying to fix a problem while being throttled.

j3s mentioned that qemu supports this natively: https://github.com/qemu/qemu/blob/master/docs/throttle.txt

One capsul is responsible for more than half of our write IOPS, and its a "tiny" $5/mo one. 🤪 This is an issue because its a monetary cost for us. SSDs wear out after a certain number of writes, and they are not pitching in proportionately to help with the cost of replacing the disks periodically. All other providers do this. Ideally would not have to, but we aren't interested in manually policing what our users do on their capsuls. So we will have to implement something like "IO credits" for "IO Burst". Once your capsul runs out of IO credits, it wil be throttled to a much slower storage performance. We can do better than providers like amazon in this regard; we can give users a large pool of IO credits and warn them when it's half depleted. A "normal" user with a normal use case will never even get close to seeing this warning, but even the most agressive disk-writing-user will be warned days or weeks before they are throttled. This way we can protect our disks from wearout or at least force users to pay more monthly if they need this kind of IO performance, but at the same time they should hopefully not have to experience the misery of trying to fix a problem while being throttled. j3s mentioned that qemu supports this natively: https://github.com/qemu/qemu/blob/master/docs/throttle.txt
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.