Building Burstables: CPU slicing with cgroups

https://www.ubicloud.com/blog/building-burstables-cpu-slicing-with-cgroups

by msarnowicz • 1 year ago

130 23 1 year ago

msarnowicz8• 1 year ago

Hey, author here. Please AMA.

I came into the Linux world via Postgres, and this was an interesting project for me learning more about Linux internals. While cgroups v2 do offer basic support for CPU bursting, the bursts are short-lived, and credits don’t persist beyond sub-second intervals. If you’ve run into scenarios where more adaptive or sustained bursting would help, we’d love to hear about them. Knowing your use cases will help shape what we build next.

parrit• 1 year ago

Thanks! That was a pleasant read. I have been wanting to mess with cgroups for a while, in order to hack together a "docker" like many have done before to understand it better. This will help!

Are there typical use cases where you reach for cgroups directly instead of using the container abstraction?

msarnowicz8• 1 year ago

Thanks for the kind words. Even if you are not building a cloud service, I think it is good to understand how the underlying layer works and what are the knobs and the limits of the platform. I could see a use case where two or more processes need to run on one VM or a container, maybe for cost-saving reasons or specific architecture/security reasons, but need to be guaranteed a certain amount of resources and a certain isolation from each other.

motrm• 1 year ago

Echoing parrit's comment, this was indeed a very nice read and very well written.

I particularly enjoyed the gentle exposition into the world of cgroups and how they work, the levers available, and finally how Ubicloud uses them.

Looking forward to reading how you handle burst credits over longer periods, once you implement that :)

Lovely work, Maciek!

msarnowicz8• 1 year ago

Thank you very much, I appreciate your comment.

nighthawk4542• 1 year ago

Great article, thanks! I’ve been curious if there’s any scheduling optimizations for workloads that are extremely burst-y. Such as super low traffic websites or cron job type work - where you may want your database ‘provisioned’ all the time, but realistically it won’t get anywhere near even the 50% cpu minimum at any kind of sustained rate. Presumably those could be hosted at even a fraction of the burst cost. Is that a use case Ubicloud has considered?

msarnowicz8• 1 year ago

This is a very valid scenario, however, one that is not yet fully baked into this implementation. But, as mentioned, this is a starting point. We want to hear feedback and see customers' workloads on Burstables first.

The main challenge here is that cpu.max.burst can be set no higher than the limit set in cpu.max. This limits our options to some extent. But we can still look at some possible implementation choices here: - Pack more VMs into the same slice/group, and with that lower the minimum CPU guaranteed, and at the same time lower the price point. This would increase the chance of running into a "noisy neighbor", but we expect it would not be used for any critical workload. - Implement calculation of CPU credits outside of the kernel and change the CPU max and burst limits dynamically over an extended period of time (hours and days, instead of sub-second).

phrotoma• 1 year ago

I don't have a question but I really wanted to say thanks for the blog post. Extremely clear and cogent writing on a tricky topic. Well done!

jauntywundrkind• 1 year ago

I'd also strongly recommend this view of how Kubernetes uses cgroups, showing similar drill downs for how everything gets managed. Lovely view of what's really happening! https://martinheinz.dev/blog/91

I've been a bit apoplectic in the past that cgroups seemed not super helpful in Kubernetes, but this really showed me how the different Kubernetes QoS levels are driven by similar juggling of different cgroups.

I'm not sure if this makes use of cpu.max.burst or not. There's a fun article that monkeys with these cgroups directly, which is neat to see. It also links to an ask that Kubernetes get support for the new (5.14) CFS Burst system. Which is a whole nother fun rabbit hole of fair share bursting to go down! https://medium.com/@christian.cadieux/kubernetes-throttling-... https://github.com/kubernetes/kubernetes/issues/104516

msarnowicz8• 1 year ago

Thank you, that is a good perspective, too!

__turbobrew__3• 1 year ago

cpu.max.burst increases the chances of noisy neighbours stealing CPU from other tenants.

I run multi-tenant k8s clusters with hundreds of tenants and it fundamentally is a hard problem to balance workload performance with efficiency. Sharing resources increases efficiency but in most cases increases tail latencies.

jeffbee2• 1 year ago

If you use k8s qos levels "guaranteed" cpu resources will be distinct — via cpu sets — from the ones used by the riff-raff. This is a good way to segregate latency-sensitive apps where you care about latency from throughtput-oriented stuff where you don't.

hinkley• 1 year ago

I suspect you can only really count on neighbors to take care of their own. Anything else they see will be taken as an entitlement.

So for instance if you run three processes for the same customer, can you set them to use the same cpu slices and deal with one of their apps occasionally needing a burst of CPU?

immibis• 1 year ago

Can't find the article where I first read it (something like "Queuing theory for software engineers") but average latency increases as, IIRC, serving time ÷ (1 - utilization). Get half as close to 100% utilization, and you double your average latency. A system with 87.5% utilization has double the latency as at 75%. At 100% it's infinity (averaged over infinite time - on shorter timescales it's an unpredictable scale-free random walk).

This is fundamental - the closer utilization is to 100%, the higher the chance a newly arriving work item has to wait for one that's already running, and several already in the queue. What's astonishing is how steep that curve is. At 95% utilization the average queue length is 20 tasks. At 99% it's 100 tasks. At 99.9% it's 1000 asks. If you find yourself at 98% utilization, you should not think "nice - in fully utilizing the server I paid for" - you should buy another server and lower it to 49%. (Or optimize the code more)

One way to deal with this is to have separate low-latency and high-latency queues. You can then run low latency tasks at say 50% utilization and fill up idle time with high latency tasks. Presuming and you actually want the HL tasks to ever get done, you can't guarantee 100% utilization, but you can get arbitrarily close as long as there's high-latency work to do. I have no idea whether this is something Kubernetes can do. You can of course have more than two priority levels.

This applies everywhere there's a queue, which is basically everywhere there's s contended resource. Hyperscalers know this. It's even been theorized that S3 Glacier is just the super low priority disk access queue on regular AWS servers (but Amazon won't tell us).

msarnowicz8• 1 year ago

Reading through the description of how cgroups are used in Kubernetes, I can see some similarities and some differences as well. It is interesting to compare the approaches.

We chose not to use cpu.weight, and instead divide the host explicitly using cgroups (slice in systemd). We put Standard VMs in dedicated slices to keep them isolated and let several Burstable VMs share a slice. This provides a trade off between the price of the VM and resource guarantees.

We use cpu.max.burst to allow the VMs to "expand" a bit, while we understand that this creates a "noisy neighbor" problem. At the same time there is a minimum guarantee of the CPU. The cgroups allow for all those knobs and give a lot of control. Combining them in various ways is an interesting puzzle.

solarkraft• 1 year ago

My main takeaway from this is that you can control KVM VMs with cgroups just like normal processes. I didn’t expect that.

msarnowicz8• 1 year ago

I am glad you found this useful!

Building Burstables: CPU slicing with cgroups

Related Stories