There are also GC techniques to make the pause shorter, for example, doing the work for the pause concurrently and then repeating it in the safepoint. The hope is that the concurrent work will turn the safepoint work into a simpler check that no work is necessary. Doubling the work may hurt GC throughput.
Go, Containers, and the Linux Scheduler
91–100 of 143 posts
Re: Go, Containers, and the Linux Scheduler
#92Earlier quoted context omitted.
Are you suggesting to setup a separate VM for each process that may only require like 0.25 cpu? Another thing you can’t do with VMs is oversubscribe (at least not with cloud ones)
You can't have both oversubscription and isolation, almost by definition. If you want isolation, VMs are great. If you want oversubscription, OSes are still better than container runtimes at managing competing processes on the same host.
OK but I can tho - oversub cpu, isolate memory, systems resources (like ports) etc.
> OSes are still better than container runtimes at managing competing processes on the same host.
OSes and container runtimes are the same thing
Re: Go, Containers, and the Linux Scheduler
#93This sort of tuning isn't necessary if you use CPU reservations instead of limits, as you should: https://home.robusta.dev/blog/stop-using-cpu-limits CPU reservations are limits, just implicit ones and declared as guarantees. So let the Go runtime use all the CPUs available, and let the Linux scheduler throttle according to your declared reservations if the CPU is contended for.
Interesting. This is not true for Memory, correct? The OOMKiller might get you.
You also cannot achieve a QoS class of Guaranteed without both CPU and Memory limits, so the pod might be evicted at some point.
Re: Go, Containers, and the Linux Scheduler
#94This sort of tuning isn't necessary if you use CPU reservations instead of limits, as you should: https://home.robusta.dev/blog/stop-using-cpu-limits CPU reservations are limits, just implicit ones and declared as guarantees. So let the Go runtime use all the CPUs available, and let the Linux scheduler throttle according to your declared reservations if the CPU is contended for.
Interesting. This is not true for Memory, correct? The OOMKiller might get you. You also cannot achieve a QoS class of Guaranteed without both CPU and Memory limits, so the pod might be evicted at some point.
Correct regarding memory - not true for memory because it's non-fungible unlike CPU shares
> You also cannot achieve a QoS class of Guaranteed without both CPU and Memory limits, so the pod might be evicted at some point.
Evicted due to node pressure - yes (but if all other pods also don't have limits it doesn't matter). For preemption QoS is not factored in the decision [0]
[0] - https://kubernetes.io/docs/concepts/scheduling-eviction/pod-...
Re: Go, Containers, and the Linux Scheduler
#95Earlier quoted context omitted.
All you did is kneecapped your app to have lower performance so it fits under your arbitrary limit. Hardly what most people describe as “best” - only useful in small percentage of usecases (like reselling compute)
I've seen significant performance gains from this in production. Other people have encountered it too hence libraries like Automaxprocs existing and issues being open with Go for it.
Gains by what metric? Are you sure you didn't trade in better latency for worse overall throughput? Also, sure you didn't hit one of many CFS overaccounting bugs which we've seen a few? Have you compared performance without the limit at all?
Re: Go, Containers, and the Linux Scheduler
#96This sort of tuning isn't necessary if you use CPU reservations instead of limits, as you should: https://home.robusta.dev/blog/stop-using-cpu-limits CPU reservations are limits, just implicit ones and declared as guarantees. So let the Go runtime use all the CPUs available, and let the Linux scheduler throttle according to your declared reservations if the CPU is contended for.
Interesting. This is not true for Memory, correct? The OOMKiller might get you. You also cannot achieve a QoS class of Guaranteed without both CPU and Memory limits, so the pod might be evicted at some point.
> Memory is different because it is non-compressible - once you give memory you can't take it away without killing the process
Re: Go, Containers, and the Linux Scheduler
#97This sort of tuning isn't necessary if you use CPU reservations instead of limits, as you should: https://home.robusta.dev/blog/stop-using-cpu-limits CPU reservations are limits, just implicit ones and declared as guarantees. So let the Go runtime use all the CPUs available, and let the Linux scheduler throttle according to your declared reservations if the CPU is contended for.
I run a few things on 128 core setups and I set CPU limits to much higher than request but still set them to make sure nothing runs ammok.
I would be curious to see this discussed but your article only states that people think you need limit to ensure CPU for all pods.
Re: Go, Containers, and the Linux Scheduler
#98Earlier quoted context omitted.
A VM provides the first 4 anyway - if you're deploying to a cloud instance then having these in the container is redundant. If you're deploying to bare metal then it's possibly useful, but only if you're deploying multiple containers to the same machine. Go doesn't need a format for packaging - it's one file. It's becoming common practice to embed everything else into the binary. (side note: I haven't done this with…
Are you suggesting to setup a separate VM for each process that may only require like 0.25 cpu? Another thing you can’t do with VMs is oversubscribe (at least not with cloud ones)
Go binaries tend not to be that lightweight, because we have goroutines for that.
And yes, setting up a separate VM for each instance of a process is perfectly feasible. That's what all this cloud business was about in the first place.
Re: Go, Containers, and the Linux Scheduler
#99[flagged]
Re: Go, Containers, and the Linux Scheduler
#100Earlier quoted context omitted.
You can't have both oversubscription and isolation, almost by definition. If you want isolation, VMs are great. If you want oversubscription, OSes are still better than container runtimes at managing competing processes on the same host.
OK but I can tho - oversub cpu, isolate memory, systems resources (like ports) etc. > OSes are still better than container runtimes at managing competing processes on the same host. OSes and container runtimes are the same thing
> OSes and container runtimes are the same thing
For a subset of OSes