-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/website/_content/doc: add note about how much memory the Go runtime retains to the GC guide #65013
Comments
This is intended to be explained in https://tip.golang.org/doc/gc-guide#GOGC, though that section has a lot more words and could perhaps have a more direct, succinct mention of the total heap size. cc @mknyszek |
To be clear, it does return unused heap memory to the OS, but it's not going to return memory to the OS it thinks it's going to use in the near future. It generally retains enough for the application to allocate up to the next heap goal ( I think (but am not certain) that this is what you're seeing.
This quote is true, but there's a lot of nuance to this. If your application is allocating memory regularly,
FWIW, the total heap size is defined in a single sentence toward the top of that section. Re-reading that section, most of the text appears to be footnotes and examples (that is, "it can be used to turn off the GC," "Go 1.18 did..., "here's an example," "here's how to use the interactive example"). Grouping all that together does tend to make one's eyes glaze over, I admit. We could probably make this a lot better by moving the footnotes into actual footnotes and putting the examples under an "examples" subheading. IMO the definition itself is OK if you stop reading after the first few sentences. This doesn't really help with the "eyes glazing over" problem, but I think maybe what's missing here is a short sentence like "the GC always retains enough memory for the application to allocate up to the target heap size." Perhaps if we restructure the section the extra sentence won't be so bad. |
My application allocates memory on demand, e.g.when it receives a web request. The annoying part was, that it does not return all used memory back to the OS regardless how long we wait. So the memory usage (from OS point of view) did not go back to the level that we had before the web request. The exact amount which gets returned is not so important to me, but the facts that it does not return all free memory. To be honest, I understood the gc-guide only partially. Maybe that's the reason why the final result from OS point of view was not clear to me. Anyway, I ensured already that the memory usage does not constantly increase over time. This works fine. |
Out of curiosity, how long did you wait? There's a forced GC every 2 minutes if it hasn't run sooner. Once that happens, the background scavenger should kick in and return memory back to the OS gradually. |
Hello,
I spent a lot of time to find the reason of a "memory leak" which did not exist. There was a fundamental misunderstanding about memory management. We thought that the garbage collector returns unused heap memory back to the operating system, which was wrong.
The explanation is in #41444 (comment) :
"Since the Go garbage collector is designed to retain about twice as much memory as your live heap size, debug.FreeOSMemory is expected to free about half of your memory"
Would you please add this information to https://tip.golang.org/doc/gc-guide ?
I think is is very important to know.
The text was updated successfully, but these errors were encountered: