We have developed a server using golang which will receive concurrent request and process the request(creates big object - a tree) and then send back reply. But the objects are not garbage collected. So I decided to analyze the objects that live in the memory. To start with, I wrote a simple program
package main
import (
"fmt"
"io/ioutil"
"os"
"runtime/debug"
)
func main() {
var i_am_a int = 10
_ = i_am_a
func() {
f, err := os.Create("dump")
defer f.Close()
if err != nil {
panic(err)
}
debug.WriteHeapDump(f.Fd())
}()
b, err := ioutil.ReadFile("dump")
if err != nil {
panic(err)
}
fmt.Print(string(b))
}
But I couldn't understand the representaion(https://github.com/golang/go/wiki/heapdump13 - this didn't help). All I wanted is to trace back from the memory(big object) to the place(variable in go app code) which holds the root address of the object. So that I can release the reference and let GC to collect it in it's cycle. Is there a latest tool to visualize heapdump? or Is there a better approach to this problem?
There is, currently, no complete solution to your problem. The newest heap dump format explains that some information previously available is no longer tracked by the runtime.
Go Issue 16410 has lots of details and information on work in progress.
One tool - a work in progress - that may help is goheapdump
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With