In March I spent a week or two investigating our go service after it ran OOM on a customers test. This gave us some incentive to refresh our knowledge around profiling go code.
Go as a runtime is quite nice here, as it brings a lot of tooling to give your insights into cpu and memory of your application. Julia Evans already has written a nice getting started post.
If you want to know more about the Go internals and details, checkout the go-profiler-notes from DataDog / felixge.
In my case, the heap profile gave us two places to look into, after reproducing the customer’s testcase, dropping our memory footprint by ~10% which in turn also reduces the CPU by 10% as well. I guess, we now had to do less GC runs - I haven’t really checked this though.