Add a wrapper to the built image to determine the GOMEMLIMIT at runtime

[chenbh]

Add a wrapper into the run layer that tries to figure out environment memory limits and use that to set the go runtime memory limit.

Describe the Enhancement

Add a script/binary to the run image and use it to wrap the built binary. The script/binary will attempt to scan cgroups and use the memory limits to calculate GOMEMLIMIT before running the app.

Possible Solution

• Create a wrapper (script/binary) to be packaged with the go buildpack that will:
  Attempt to read either /sys/fs/cgroup/memory.high cgroup v2 or /sys/fs/cgroup/mermoy/memory.limits_in_bytes (cgroup v1) and use that to calculate the actual limit (go docs suggest 5-10% overhead). Then run whatever is passed in as arguments
• Introduce a BP_GO_AUTOMATIC_MEMLIMIT="false" that when set to "true", will copy this wrapper from into the run layer and use it as the entrypoint instead of the built app

Motivation

Go 1.19 introduced a way to hint to the go runtime what the real world memory limits are. With this env var set, the go garbage collector will get more aggressive as the actual memory used approaches the limit.

Some container orchestrators (big one being kubernetes) allow users to configure the maximum compute resources a container is allowed to use. If GOMEMLIMIT isn't set while a go app is running, it can get OOMKilled even though it had plenty of memory to GC..

https://paketobuildpacks.slack.com/archives/CUEGB5FD1/p1672862212513359

[ryanmoran]

We have a very similar mechanism already in place for Node apps: https://github.com/paketo-buildpacks/node-engine/blob/main/cmd/optimize-memory/internal/run.go.

[matthewmcnew]

Is the java memory calculator also prior art: https://github.com/paketo-buildpacks/libjvm/blob/61327124bca2b19ec46f2566b60b7ba56be4486a/helper/memory_calculator.go?