-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/cmd/godoc: memory increase even when no files are added to index #32692
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Directly pasting the pruned logs here -
|
@cdang1234 What precisely are you measuring in your graphs? Also, can you try running with go1.12.5 instead of 1.12.0? There's a known issue with 1.12.x where x < 5 that can cause unbounded virtual memory growth, which is precisely what I'm seeing in the log (the "footprint" number is growing, whereas the "bytes" number would be growing if there was a memory leak). See #31616. |
The X axis of my graphs are the number of re-indexing events. The graphs measure the size of memory usage and the rate memory usage changes for each re-indexing event. Thanks for sharing the info on go1.12.5. I'll re-run my experiment with the most recent go version and I'll post the results here |
Sorry, I should've been more specific. When I asked "what precisely are you measuring" I meant what statistic are you looking at to build your graph? For example, are you using the log output (in which case, are you using "bytes", which measures how many objects are actually allocated, or "footprint", which is the amount of memory mapped by the Go runtime?), are you scraping I apologize for being pedantic, I just want to be precise because memory use is measured in many different ways by many different parts of the system, and many don't actually correlate with how much memory you're actually using. Some do correlate but don't give you a direct measure. Few actually give you a direct measure. In this particular case, it's important to me to understand where these numbers are coming from so I can be sure it's really just the regression I think it is and not something else. |
I'm running the godoc process from within a docker so I use three methods to measure the memory usage: The charts above get their data points from godoc's footprint logs. I double check every now and then that footprint's output is accurate by comparing it against top and docker stats. The docker image is golang:1.12.0-alpine3.9 |
I re-ran godoc with go1.12.6 and still observed the issue |
FWIW, VSZ is measuring is virtual address space used and not physical memory used. That is, VSZ doesn't correlate with how much memory an application is actually using. An application running on a 64-bit machine could map 32 GiB of virtual memory (or more, it gets a bit complicated since how much you could do depends on the OS and architecture) even when you only have 8 GiB of physical memory. The OS won't count it against you unless you actually try to use (that is, access) or commit to using (some systems make you commit explicitly) all 32 GiB of memory. What's generally more pertinent, because this is what the OS will actually start killing programs for, is RSS (in Based on the fact that
I'm not sure it's been running long enough for me to agree, I can let it run over the weekend and see what happens. What we're looking for to confirm #31616 is a long trend of On a final note, it's totally possible for |
godoc is frozen. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I ran godoc -index -index_interval=1m -v -maxresults=0 from within a docker image using golang:latest. I ran until 96 re-indexing events had passed.
If you want to recreate this issue, run godoc on your host machine with the following command:
godoc -index -index_interval=1m -maxresults=0 -v
After each re-indexing event the process will consume more memory.
What did you expect to see?
I expected the memory allocated to godoc to stop increasing if no new files were added to the filesystem
What did you see instead?
The memory usage growth is unbounded. The following graphs show the growth of memory over 96 re-indexing events on a 8 GiB machine. This experiment was run on a docker, but I've replicated it on my host machine and seen similar results. Notice that memory usage is nearly 80% by end of the experiment. I've attached a pdf with the log dump from godoc below as well.
godocWebServiceSample.pdf
The text was updated successfully, but these errors were encountered: