For reference: How can I make garbage collection steal less of my resources during spikes in allocations?
My question is very specific: how can I prevent Go's garbage collection from breaking down in applications that allocate a lot of memory in short bursts?
I'm having trouble understanding what about this is unfocused.
To chime in:
When this refresh occurs, I'm experiencing that the GC almost completely stops my service from doing any meaningful work for the duration of the GC, around 600-700 ms.
This may be true, but how do you know? I assume you have profiled your application, but where is this data?
The GC isn't stopping the world, but it's stealing so much of my processing time via gcAssistAlloc that there's little difference. My understanding is that it's doing this because the sharp increase in memory pressure causes it to think memory is being allocated faster than it can collect, so it aggressively steals CPU.
This is from https://go.dev/doc/gc-guide#Identiying_costs: “A large amount of cumulative time spent here (>5%) indicates that the application is likely out-pacing the GC with respect to how fast it's allocating.”
Did you mean that with “My understanding is ...” or where did you get that from?
I'm unable to change the implementation of this refresh, e.g. to implement pooling or throttle it; the data is fetched by a third party package.
Is there any way to make the GC stop stealing my CPU, or hint to it that it doesn't need to be so aggressive? In reality, there's virtually no memory pressure outside of the refresh.
Now we can only guess. Give it more RAM? How much RAM does it have, because “no memory pressure outside of the refresh” is obviously not very relevant.
Perhaps “change the implementation” you're “unable to change”, because it being Go and affecting the Go garbage collector, there is a good chance you have the source...
I would agree that “needs detail or clarity” would be better than “needs to be more focused”, but generally it would be helpful to
and probably
If you present a system that allocates too much memory at one point, and you can't change that, and also you won't give it more memory because it's mostly not needed, and that has to be fast - you're in a tight spot there, with any language.
Again, I can't really vote for “unfocused”. But I'm also at loss at what kind of answer you expect, because you seem to imply that the obvious answers won't help, but some Go wizard might have some magical pixie dust or something...
Posting this as an “answer” because it's really unwieldy in comment format. I don't feel more competent to answer that than most of the people who commented, with them having obviously far more experience than I have.
