Hi,
I have compiled my Go binary against go version 'go1.7 linux/amd64'.
I added the following code change in the main function to get the memory
profiling of my service
var memprofile = flag.String("memprofile", "", "write memory profile to
`file`")
func main() {
flag.Parse()
if *memprofile != "" {
f, err := os.Create(*memprofile)
if err != nil {
fmt.Println("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
runtime.GC() // get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
fmt.Println("could not write memory profile: ", err)
}
}
..
..
(Rest code to follow)
I ran the binary with the following command:
nsaboo@ubuntu:./main -memprofile=mem.prof
After running the service for couple of minutes, I stopped it and got the
file 'mem.prof'
1)mem.prof contains the following:
nsaboo@ubuntu:~/Desktop/memprof$ vim mem.prof
heap profile: 0: 0 [0: 0] @ heap/1048576
# runtime.MemStats
# Alloc = 761184
# TotalAlloc = 1160960
# Sys = 3149824
# Lookups = 10
# Mallocs = 8358
# Frees = 1981
# HeapAlloc = 761184
# HeapSys = 1802240
# HeapIdle = 499712
# HeapInuse = 1302528
# HeapReleased = 0
# HeapObjects = 6377
# Stack = 294912 / 294912
# MSpan = 22560 / 32768
# MCache = 2400 / 16384
# BuckHashSys = 2727
# NextGC = 4194304
# PauseNs = [752083 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
# NumGC = 1
# DebugGC = false
2)When I tried to open the file using the following command, it just goes
into interactive mode and shows nothing
a)Output from go version go1.7 linux/amd64 for mem.prof
nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
Entering interactive mode (type "help" for commands)
(pprof) top
profile is empty
(pprof)
b)Output from go version go1.12.4 linux/amd64 for mem.prof
nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
Type: space
No samples were found with the default sample value type.
Try "sample_index" command to analyze different sample values.
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) o
call_tree = false
compact_labels = true
cumulative = flat //: [cum | flat]
divide_by = 1
drop_negative = false
edgefraction = 0.001
focus = ""
granularity = functions //: [addresses |
filefunctions | files | functions | lines]
hide = ""
ignore = ""
mean = false
nodecount = -1 //: default
nodefraction = 0.005
noinlines = false
normalize = false
output = ""
prune_from = ""
relative_percentages = false
sample_index = space //: [objects | space]
show = ""
show_from = ""
tagfocus = ""
taghide = ""
tagignore = ""
tagshow = ""
trim = true
trim_path = ""
unit = minimum
(pprof) space
(pprof) sample_index
(pprof) top
Showing nodes accounting for 0, 0% of 0 total
flat flat% sum% cum cum%
3)Please let me know if it is this the correct way of getting the memory
profiling ?
4)Can we deduce something from this memory stats that points us to increase
in memory usage?
5)I am just thinking out loud, since I am using go1.7, can that be the
reason for the issue of increase in memory usage that might get fixed with
latest go versions ?
Thanks,
Nitish
On Tue, Mar 10, 2020 at 6:56 AM Jake Montgomery <jake6...@gmail.com> wrote:
>
> On Monday, March 9, 2020 at 1:37:00 PM UTC-4, Nitish Saboo wrote:
>>
>> Hi Jake,
>>
>> The memory usage remains constant when the rest of the service is
>> running.Only when LoadPatternDB() method is called within the service,
>> Memory Consumption increases which actually should not happen.
>> I am assuming if there is a memory leak while calling this method
>> because the memory usage then becomes constant after getting increased and
>> then further increases on next call.
>>
>
> Its possible that I am not fully understanding, perhaps a language
> problem. But from what you have written above I still don't see that this
> means you definitely have a memory leak. To test for that you would need to
> *continuously
> *call LoadPatternDB() and monitor memory for a *considerable time*. If it
> eventually stabilizes to a constant range then there is no leak, just
> normal Go-GC variation. If it never stops climbing, and eventually consumes
> all the memory, then it would probably be a leak. Just because it goes up
> after one call, or a few calls doe not mean there is a leak.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f897fdb1-8968-4435-9fe9-02e167e09a36%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/f897fdb1-8968-4435-9fe9-02e167e09a36%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALjMrq6DC98p4M4V2QCbQFTcsL1PtOWELvg8MEcMYj9EM9ui_A%40mail.gmail.com.
