proposal: runtime: support a percentage for GOMEMLIMIT

[dsnet]

Proposal Details

We had a service that had GOMEMLIMIT set. Over the years, due to natural growth of users, we increased the size of the machine that the service ran on. However, it was easy to forget to increase the GOMEMLIMIT since this was populated in a different place than where infrastructure is defined. Thus, we ran into an issue where the service was massively underutilizing its newly available memory.

Instead of specifying an absolute value like 32GiB, allow users to specify a percentage like 80% to indicate that it can use up to 80% of the total system memory (or the cgroup memory limit, see #75164).

\cc @knyar @scottjab

[gabyhelp]

Related Issues

• proposal: runtime: cgroup memory limit aware GOMEMLIMIT default #75164

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[prattmic]

We discussed this proposal briefly in #57175 (comment).

Our general consensus was:

• This is something that users can do manually. e.g., as in https://pkg.go.dev/github.com/KimMachineGun/automemlimit.
• Still, this would clearly be a nice convenience feature.

But there are an annoying number of answered questions:

• On Linux, does this use the cgroup hard or soft limit?
• We need to define the denominator on every GOOS, such as Windows and darwin. What should it be? Total physical memory? Should it take swap or compressed memory into account? Will these OSes remain stable in the way they report available memory over time? OS memory management tends to change over time, which could be a compatibility annoyance.

I suspect that given enough thought we could answer these questions, but the GOOS one in is, in my opinion, particularly annoying because most likely almost everyone would care about this feature only for Linux container use cases, but we still need to spend time to define semantics everywhere.

[xieyuschen]

The proposal is nice, and here is a related but distinct use case, would it make sense to support setting the normal GC heap goal as a percentage of the detected memory limit?

For example, a service may want the GOGC-derived heap goal to be approximately 70% of the cgroup memory limit. The intent is not primarily to enforce a memory limit or avoid OOM, but to keep the normal GC target heap proportional to the available memory, so larger machines automatically allow fewer GC cycles and lower GC CPU cost.

Today, in our company, we approximate this in a common GC tuning library by dynamically recalculating GOGC after each GC cycle using the same formula the runtime uses for the GOGC-derived heap goal, then applying it with runtime/debug.SetGCPercent.

I understand this is more subtle than just setting a fixed heap goal. The heap goal is still only a target, and the runtime may adjust the effective goal for pacing, memory-limit constraints, and other runtime conditions. The feature I am describing would be a way to express the normal GOGC-derived heap target as a percentage of detected memory, not a hard heap limit.

In our current practice this dynamic GOGC approach is only enabled for selected services where the live heap and allocation behavior are stable enough for this policy to be useful. I am mainly raising this to see whether this use case fits the direction of this proposal, or whether it should be considered a separate knob from percentage-based GOMEMLIMIT.