On first read this article made little sense to me.
Ok, go has GOGC env. Ok, you can tune it based on stuff. Do they tune it live as part of process life or is it pre-comoputed at start? Is gogctuner a library?
> As we mentioned above, manual GOGC is not deterministic
What?
More importantly, why the engineering effort is spent on that tool as opposed to just trying to reduce allocations. I've spent countless hours trying to reduce allocations of the hot path. This is a good strategy - Go GC cost becomes negligible if it doesn't have anything to do!
But then it hit me. The missing context is probably other services/tenants interacting with system resources.
Am I wrong in reading it as: In time of the low load, they want to burn less CPU at the cost of more memory. At peak time, they do business as usual. Reducing GC frequency at low load, is generally meaningless. In most systems most operators care about performance/cpu/latency on peak.
Unless....
Unless you have other tenants. They probably run batch jobs at low times, and if that is the case, then indeed, burning CPU for low utilization GO jobs is a waste of CPU.
Ok, go has GOGC env. Ok, you can tune it based on stuff. Do they tune it live as part of process life or is it pre-comoputed at start? Is gogctuner a library?
> As we mentioned above, manual GOGC is not deterministic
What?
More importantly, why the engineering effort is spent on that tool as opposed to just trying to reduce allocations. I've spent countless hours trying to reduce allocations of the hot path. This is a good strategy - Go GC cost becomes negligible if it doesn't have anything to do!
But then it hit me. The missing context is probably other services/tenants interacting with system resources.
Am I wrong in reading it as: In time of the low load, they want to burn less CPU at the cost of more memory. At peak time, they do business as usual. Reducing GC frequency at low load, is generally meaningless. In most systems most operators care about performance/cpu/latency on peak.
Unless....
Unless you have other tenants. They probably run batch jobs at low times, and if that is the case, then indeed, burning CPU for low utilization GO jobs is a waste of CPU.