Closed parkr closed 6 years ago
Why guess? Move go-issue-mirror
outside your GOPATH for a second, retry, and see whether there's a difference.
Removing $GOPATH/src/github.com/bradfitz/go-issue-mirror
seems to have made a difference. It was 5.61 GB before, 4.46GB now.
Back up to 8.63 GB.
Removed $GOPATH/src/github.com/camlistore/camlistore
and killed the process. Down to 3.54GB.
Could symlinks cause issues here?
I've added some profiling on godoc with go-issue-mirror installed in $GOPATH and using the command line provided in reproduction. A fair amount of time is spent in GC on the cpu profile. There's a good amount of object creation in the indexer paths which started leading me towards GC or memory allocation issues, but I don't have enough expertise in those parts of Go.
If there's a tool that can do like cpu profile for memory allocation that would be great. I tried passing it through valgrind but can't seem to get debugging info from the go files in question to give me caller info to track down more on.
@cwgem Thanks for doing this! I'm not familiar with this process – can you also run a memory profile? It was using significant memory.
With the following $GOPATH usage, I was seeing 1.2GB of memory being used by godoc.
~$ du --max-depth=1 -h -L $GOPATH/
216K /usr2/ps/ISP/go/pkg
2.7M /usr2/ps/ISP/go/src
6.9M /usr2/ps/ISP/go/bin
9.8M /usr2/ps/ISP/go/
What's the status here? Has anybody investigated this further?
I see a CPU profile above. Has anybody done a memory profile?
@bradfitz This is still happening for me. I pulled some info from /debug/pprof/
and some sampler data from the "macOS" and added it here: https://gist.github.com/parkr/916bc0e15fa47a6aaed02facb62df63a
@parkr, older versions of Go's memory samples weren't self-contained. Can you either include the binary or ideally use Go 1.8?
@bradfitz My apologies! I just updated the gist above with the new data after re-compiling godoc via go get -u golang.org/x/tools/cmd/godoc
with go 1.8. My $GOPATH is about 675 MB, and resident uncompressed memory is ~4.5GB.
@bradfitz Is what @parkr provided enough for someone to look at this issue?
/cc @adg @bradfitz
Here is some more info.
Current $GOPATH usage.
~$ du --max-depth=1 -h -L $GOPATH/
8.0K /usr2/ps/ISP/go/pkg
77M /usr2/ps/ISP/go/src
6.9M /usr2/ps/ISP/go/bin
84M /usr2/ps/ISP/go/
Pprof Output:
~$ go tool pprof -alloc_space http://godocurl/debug/pprof/heap
Entering interactive mode (type "help" for commands)
(pprof) top5
18595.70MB of 22973.02MB total (80.95%)
Dropped 243 nodes (cum <= 114.87MB)
Showing top 5 nodes out of 112 (cum >= 504.66MB)
flat flat% sum% cum cum%
15804.81MB 68.80% 68.80% 15804.81MB 68.80% regexp.(*bitState).reset
1135.79MB 4.94% 73.74% 1135.79MB 4.94% bytes.makeSlice
645.79MB 2.81% 76.55% 659.87MB 2.87% go/printer.(*printer).writeString
504.66MB 2.20% 78.75% 504.66MB 2.20% index/suffixarray.initGroups
504.66MB 2.20% 80.95% 504.66MB 2.20% index/suffixarray.sortedByFirstByte
Here is the svg output.
@parkr was this fixed by https://github.com/golang/go/issues/21061? Your comment (https://github.com/golang/go/issues/17344#issuecomment-252688142) suggested you may have been affected by the symlink bug.
This can probably be closed regardless? I don't think there's enough information here for anyone else to reproduce.
That looks likely! I stopped using godoc as much because of this. I’ll give it a whirl in the latest go tip. Thanks, all!
@bradfitz I still have the problem of godoc using more memory than it seems like it should use. Should I open a new issue?
The memory usage is proportional to the size of your GOPATH. If you think it is using more memory than it should, then yes please open a new issue with all relevant details possible that can help us debug the issue.
Thanks.
@agnivade When you say,
The memory usage is proportional to the size of your GOPATH
Is there a way to calculate what a sane value would be?
My current GOPATH usage is 134M, but godoc
is using ~3GB before it crashes because it can't allocate any more memory.
Most possibly, you have the search index enabled. In that case, memory usage can be significantly high. I can't deduce anything more without further info. I suggest that you open a new issue with all the details if you believe there is a bug somewhere.
I tweeted about this yesterday and it was suggested by @adg that I file this bug here.
What version of Go are you using (
go version
)?go version go1.7.1 darwin/amd64
What operating system and processor architecture are you using (
go env
)?What did you do?
If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best.
Command run:
/usr/local/opt/go/libexec/bin/godoc -http=localhost:6060 -index -index_throttle=0.25 -index_interval=1h
GOPATH is fairly large:
Size of various folders & files in GOPATH
github.com/bradfitz/go-issue-mirror
is 57 MB of Git data, and 414 MB of.json
files inissues/
. I forked that togithub.com/parkr/jekyll-issue-mirror
which is 46 MB of Git data and 6.9 MB of.json
files.What did you expect to see?
I expected to see the process take less memory. I expected to see the process's memory stay stable over time if I make no modifications to the contents of my GOPATH.
What did you see instead?
It is using well over 4 times as much memory as it takes on disk. It continues to grow over time.
My hunch is that it's indexing these
.json
files, or the.git
data.